* [RFC] systemd the userspace object manager
@ 2014-11-18 16:38 Christopher J. PeBenito
2014-11-18 18:48 ` Christopher J. PeBenito
2014-11-18 19:20 ` Dominick Grift
0 siblings, 2 replies; 8+ messages in thread
From: Christopher J. PeBenito @ 2014-11-18 16:38 UTC (permalink / raw
To: mgrepl, Daniel J Walsh; +Cc: SELinux List
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] systemd the userspace object manager
2014-11-18 16:38 [RFC] systemd the userspace object manager Christopher J. PeBenito
@ 2014-11-18 18:48 ` Christopher J. PeBenito
2014-11-18 19:20 ` Dominick Grift
1 sibling, 0 replies; 8+ messages in thread
From: Christopher J. PeBenito @ 2014-11-18 18:48 UTC (permalink / raw
To: mgrepl, Daniel J Walsh; +Cc: SELinux List
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] systemd the userspace object manager
2014-11-18 16:38 [RFC] systemd the userspace object manager Christopher J. PeBenito
2014-11-18 18:48 ` Christopher J. PeBenito
@ 2014-11-18 19:20 ` Dominick Grift
2014-11-20 13:52 ` Christopher J. PeBenito
1 sibling, 1 reply; 8+ messages in thread
From: Dominick Grift @ 2014-11-18 19:20 UTC (permalink / raw
To: selinux
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] systemd the userspace object manager
2014-11-18 19:20 ` Dominick Grift
@ 2014-11-20 13:52 ` Christopher J. PeBenito
2014-11-20 15:59 ` Dominick Grift
2014-11-20 20:44 ` Joshua Brindle
0 siblings, 2 replies; 8+ messages in thread
From: Christopher J. PeBenito @ 2014-11-20 13:52 UTC (permalink / raw
To: selinux
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] systemd the userspace object manager
2014-11-20 13:52 ` Christopher J. PeBenito
@ 2014-11-20 15:59 ` Dominick Grift
2014-11-20 20:44 ` Joshua Brindle
1 sibling, 0 replies; 8+ messages in thread
From: Dominick Grift @ 2014-11-20 15:59 UTC (permalink / raw
To: selinux
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] systemd the userspace object manager
2014-11-20 13:52 ` Christopher J. PeBenito
2014-11-20 15:59 ` Dominick Grift
@ 2014-11-20 20:44 ` Joshua Brindle
2014-11-21 11:31 ` Dominick Grift
1 sibling, 1 reply; 8+ messages in thread
From: Joshua Brindle @ 2014-11-20 20:44 UTC (permalink / raw
To: Christopher J. PeBenito; +Cc: selinux
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] systemd the userspace object manager
2014-11-20 20:44 ` Joshua Brindle
@ 2014-11-21 11:31 ` Dominick Grift
2014-11-21 12:43 ` Joshua Brindle
0 siblings, 1 reply; 8+ messages in thread
From: Dominick Grift @ 2014-11-21 11:31 UTC (permalink / raw
To: selinux
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] systemd the userspace object manager
2014-11-21 11:31 ` Dominick Grift
@ 2014-11-21 12:43 ` Joshua Brindle
0 siblings, 0 replies; 8+ messages in thread
From: Joshua Brindle @ 2014-11-21 12:43 UTC (permalink / raw
To: selinux
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'.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-11-21 12:44 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-11-18 16:38 [RFC] systemd the userspace object manager Christopher J. PeBenito
2014-11-18 18:48 ` Christopher J. PeBenito
2014-11-18 19:20 ` Dominick Grift
2014-11-20 13:52 ` Christopher J. PeBenito
2014-11-20 15:59 ` Dominick Grift
2014-11-20 20:44 ` Joshua Brindle
2014-11-21 11:31 ` Dominick Grift
2014-11-21 12:43 ` Joshua Brindle
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.