[systemd-devel] PrivateDevices with more than basic set of devices?

[Topi Miettinen]

On 01/27/15 20:52, Lennart Poettering wrote:
> On Tue, 27.01.15 18:51, Topi Miettinen (toiwoton at gmail.com) wrote:
> 
>> On 01/26/15 21:04, Lennart Poettering wrote:
>>> On Mon, 26.01.15 17:07, Topi Miettinen (toiwoton at gmail.com) wrote:
>>>
>>>> On 01/26/15 12:41, Simon McVittie wrote:
>>>>> On 24/01/15 10:09, Topi Miettinen wrote:
>>>>>> For example, smartd only needs access to /dev/sd*.
>>>>>
>>>>> Let me spell that differently: smartd "only" needs the ability to make
>>>>> arbitrary filesystem changes, defeating any possible configurable
>>>>> security mechanism.
>>>>
>>>> Not exactly: it only needs read access. Depending on the system, that
>>>> could be very different from being able to make arbitrary filesystem
>>>> changes.
>>>
>>> Sending SMART requests requires the same priviliges as issue direct
>>> low-level write requests to my knowledge, hence I'd say simon is right.
>>
>> CAP_SYS_RAWIO, yes. Only read access is needed otherwise:
>> DevicePolicy=closed
>> DeviceAllow=block-sd r
>> DeviceAllow=/dev/sda r
>> DeviceAllow=/dev/sdb r
>> works fine here.
> 
> You should be able to reduce this to simply:
> 
>     DeviceAllow=block-sd r
> 
> This should suffic since DevicePolicy=closed is implied if there's at
> least one DeviceAllow= specified. And "DeviceAllow=block-sd r" enables
> access to all /dev/sd* access, which includes /dev/sda and /dev/sdb,
> of course.

In general yes, but I didn't want to allow SMART requests to /dev/sdc,
it's a DVD-ROM drive and there are useless errors if accessed with SMART.

> 
>> Probably CAP_SYS_RAWIO can be used to circumvent the lack of write
>> access, though.
> 
> Yes, it can.
> 
> I think in general though that sandboxing should be done even if there
> are ways to circumvent it. It might still protects from accidental
> mishaps even if it doesn't prevent attackers to exploit things.
> 
> That said, as mentioned in my earlier mail smartd will probably not be
> happy with accessing only /dev/sd*, it wants access to all kinds of
> other devices. For example it has special support for certain SCSI
> RAID drivers and such, which are not accessed via /dev/sd*...
> 
> Lennart
>