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

[Lennart Poettering]

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.

> 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

-- 
Lennart Poettering, Red Hat