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