[RFC] systemd the userspace object manager

[RFC] systemd the userspace object manager

[Christopher J. PeBenito]

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

Re: [RFC] systemd the userspace object manager

[Christopher J. PeBenito]

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

Re: [RFC] systemd the userspace object manager

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

> 
> class init_service
> {
>     start
>     stop
>     status
> }
> 

I cannot really substantiate but it look like these are also used to start/stop/get status of systemd (session) daemons, so i suppose start_init, stop_init, get_status_init

I suspect this is mainly for starting the systemd session daemons. Logind uses these i believe.

so to start a systemd session daemon: allow ARG init_t:init start_init;  or something maybe?

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: [RFC] systemd the userspace object manager

[Christopher J. PeBenito]

On 11/18/2014 2:20 PM, Dominick Grift wrote:
>>
>> class init_service
>> {
>>     start
>>     stop
>>     status
>> }
>>
> 
> I cannot really substantiate but it look like these are also used to start/stop/get status of systemd (session) daemons, so i suppose start_init, stop_init, get_status_init
> 
> I suspect this is mainly for starting the systemd session daemons. Logind uses these i believe.
> 
> so to start a systemd session daemon: allow ARG init_t:init start_init;  or something maybe?

Why would those daemons need to be treated specially?  In the end
they're still services; they may have special system features, but in
that case you don't allow just anyone to stop/start them.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Re: [RFC] systemd the userspace object manager

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 415 bytes --]

On Thu, Nov 20, 2014 at 08:52:58AM -0500, Christopher J. PeBenito wrote:
> 
> Why would those daemons need to be treated specially?  In the end
> they're still services; they may have special system features, but in
> that case you don't allow just anyone to stop/start them.
> 

You're probably right. It looks that way, but i suppose the only way to be determine is to view the code.
-- 
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: [RFC] systemd the userspace object manager

[Joshua Brindle]

Christopher J. PeBenito wrote:
> On 11/18/2014 2:20 PM, Dominick Grift wrote:
>>> class init_service
>>> {
>>>      start
>>>      stop
>>>      status
>>> }
>>>
>> I cannot really substantiate but it look like these are also used to start/stop/get status of systemd (session) daemons, so i suppose start_init, stop_init, get_status_init
>>
>> I suspect this is mainly for starting the systemd session daemons. Logind uses these i believe.
>>
>> so to start a systemd session daemon: allow ARG init_t:init start_init;  or something maybe?
>
> Why would those daemons need to be treated specially?  In the end
> they're still services; they may have special system features, but in
> that case you don't allow just anyone to stop/start them.
>

I can see why you'd want someone to be able to restart apache but not 
everything. Certainly having specific permissions is not the way to 
accomplish that.

The rule above is kind of strange, permissions should not be equivalence 
classes, types should be, so it should be more like:

allow <domain requesting restart> <derived service label> : init {start 
stop}

right?

Re: [RFC] systemd the userspace object manager

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]

On Thu, Nov 20, 2014 at 03:44:19PM -0500, Joshua Brindle wrote:
> 
> I can see why you'd want someone to be able to restart apache but not
> everything. Certainly having specific permissions is not the way to
> accomplish that.
> 
> The rule above is kind of strange, permissions should not be equivalence
> classes, types should be, so it should be more like:
> 
> allow <domain requesting restart> <derived service label> : init {start
> stop}
> 
> right?

If only it were that simple. Here is my take on the whole thing:

Generally services are managed by "service" access checks on unit file types

allow webadmin webserverunitfile:service {start stop};

However these is also a concept of transient (in-memory) unit files, managing a service through a transient unit would work like:

allow user self:service {start stop};

or in the case of transient systemd units:

allow user systemd:service {stop start};

Then there is the system(d) class which also has the start, stop permissions associated with it (it is yet to be determined for what exactly)

In my policy systemd-logind does the following:

allow logind_t systemd:system(d) { start stop };

I suspect that this is required to spawn the systemd session daemon (at least)
It may or may not also be required for kexec (not sure as i havent tested that yet)

This is pretty much just all speculation though, in the sense that this is broadly what i see happening in the system, and it might not be the same as what *should* be happening
Instead its probably better to just read the systemd object manager code

-- 
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: [RFC] systemd the userspace object manager

[Joshua Brindle]

Dominick Grift wrote:
> On Thu, Nov 20, 2014 at 03:44:19PM -0500, Joshua Brindle wrote:
>> I can see why you'd want someone to be able to restart apache but not
>> everything. Certainly having specific permissions is not the way to
>> accomplish that.
>>
>> The rule above is kind of strange, permissions should not be equivalence
>> classes, types should be, so it should be more like:
>>
>> allow<domain requesting restart>  <derived service label>  : init {start
>> stop}
>>
>> right?
>
> If only it were that simple. Here is my take on the whole thing:
>
> Generally services are managed by "service" access checks on unit file types
>
> allow webadmin webserverunitfile:service {start stop};
>
> However these is also a concept of transient (in-memory) unit files, managing a service through a transient unit would work like:
>
> allow user self:service {start stop};
>
> or in the case of transient systemd units:
>
> allow user systemd:service {stop start};
>
> Then there is the system(d) class which also has the start, stop permissions associated with it (it is yet to be determined for what exactly)
>
> In my policy systemd-logind does the following:
>
> allow logind_t systemd:system(d) { start stop };
>
> I suspect that this is required to spawn the systemd session daemon (at least)
> It may or may not also be required for kexec (not sure as i havent tested that yet)
>
> This is pretty much just all speculation though, in the sense that this is broadly what i see happening in the system, and it might not be the same as what *should* be happening
> Instead its probably better to just read the systemd object manager code
>

I don't think we are saying different things. Note my rule above 
specifically says the object label is derived. I never speculated about 
how it would be derived, though it could be based on label mapping or 
type_trans calculations. In the cases above it would seem like there are 
some transient labels that need to be derived without the luxury of an 
object on-disk so you could either using a labeling file:

user_u:user_r:user_t:s0		user_u:user_r:user_service_t:s0

or a type_transition using the systemd or service object class:

type_transition user_t systemd_t service:user_service_t

Both of these has been done for various other userspace object classes, 
I haven't yet seen anything that makes systemd 'special'.