Systemd currently mixes userspace permissions into a kernel class
(system). This came up on the refpolicy list a few months ago[1], but
there has been no decision or progress[2][3] that I'm aware of, so I'd
like to reach a decision on the direction here.
Based on what was proposed for upstreaming into refpolicy, it looks like
all of the service class permissions were duplicated into system, in
addition to "halt" and "reboot". This conflates kernel functions with
systemd functions. With the current systemd implementation, I think a
minimum change should be:
class init_system
{
halt
reboot
}
class init_service
{
start
stop
status
reload
enable
disable
}
(init_ prefix added for naming convention consistency with other
userspace classes in refpolicy)
Since we are discussing the enforcement, I'd like to review all of
systemd's enforcement. Right now there are checks against unit files
and processes, both for the service object class. I think this has
problems as it conflates units (as service configurations) with services
(the daemon processes). In an ideal world (I don't know if the systemd
code could easily support this), I think the classes should be:
class init_system
{
halt
reboot
}
class init_unit
{
enable
disable
reload
}
class init_service
{
start
stop
status
}
Then init_system checks would always be against systemd's type (i.e.
init_t), init_unit would always check against the unit file type, and
init_service would always check against the daemon process type (which
systemd should be able to calculate since it does that for socket
activation).
[1] http://oss.tresys.com/pipermail/refpolicy/2014-July/007229.html
[2] https://bugs.freedesktop.org/show_bug.cgi?id=81105
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1132933
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
