Re: [RFC] systemd the userspace object manager

["Christopher J. PeBenito" <cpebenito@tresys.com>]

On 11/18/2014 11:38 AM, Christopher J. PeBenito wrote:
> 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
> }

With some sleuthing help from a few people in the IRC channel, we found
that reload permission is used in the system class to mediate at least
the "systemctl daemon-reload", which reloads all unit files.  I'll amend
my suggestions to add a more specific permission, "reload_all_units", to
the init_system class above and below for daemon-reload, under the
assumption that a change to check the reload permission on all units
would be rejected by systemd maintainers.



> (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