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

Topi Miettinen toiwoton at gmail.com
Tue Jan 27 13:38:27 PST 2015

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

More information about the systemd-devel mailing list