Re: [RFC] systemd the userspace object manager

[Joshua Brindle <brindle@quarksecurity.com>]

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'.