On 01/27/15 20:52, Lennart Poettering wrote: > On Tue, 27.01.15 18:51, Topi Miettinen (toiwo...@gmail.com) wrote: > >> On 01/26/15 21:04, Lennart Poettering wrote: >>> On Mon, 26.01.15 17:07, Topi Miettinen (toiwo...@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 > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel