One big shortcoming that refpolicy has had lately is missing a complete
systemd policy. Since no one has upstreamed the policy, I've decided to
start writing one, as the Fedora version cannot be upstreamed with out
significant refactoring.
I am developing/staging this change in my personal fork of the repository:
https://github.com/pebenito/refpolicy
If you would like to contribute to this work, please use pull requests.
When the policy is complete, there will be a period for comments on-list
before it is merged to the main refpolicy tree.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Fri, Oct 31, 2014 at 10:34:37AM -0400, Christopher J. PeBenito wrote:
> One big shortcoming that refpolicy has had lately is missing a complete
> systemd policy. Since no one has upstreamed the policy, I've decided to
> start writing one, as the Fedora version cannot be upstreamed with out
> significant refactoring.
>
> I am developing/staging this change in my personal fork of the repository:
>
> https://github.com/pebenito/refpolicy
>
> If you would like to contribute to this work, please use pull requests.
>
> When the policy is complete, there will be a period for comments on-list
> before it is merged to the main refpolicy tree.
>
Here are some bullet points of some things one may or may not want to consider ( i am currently also in the process of rewriting my systemd policy and for some of these point i already made decisions while for others i am still considering my options.
- i started my first version by confining each component just to see what fits where and does what. Here are some conclusions:
There are atleast three components that can be started directly by processes with the kernel process identity:
systemd-cgagent
systemd-coredump
systemd-bootchart
It may or may not be worth it to transition out of kernel_t and into either one of more domains for these processes
- One component that stands out is the systemd-sysctl component. This component writes to sysctl proc files. Some of which almost no one else should ever touch. Therefore it might be worth it to run that in a seperate domain.
In my personal policy i decided to, and it is by no means an optimal solution, /usr/sbin/sysctl and systemd-sysctl since boths programs write sysctl objects
The issue is that one is a application and the other is a "systemd oneshot daemon"
in my policy basically "sysctl_t" is the only type that can write some "sensitive" sysctl files that are commonly referred to as sysctl_security and sysctl_usermodehelper
- Basically the remainder of, atleast the "short running" components could probbably be lumped together into a single helper domain ( there may be exceptions but none come to mind right now)
- The long running system components should probably run outside of the systemd domain and inside their own respective domains
- One thing i noticed was that although systemd eventually ends up with enough permissions to do serious damage to the system, it is possible to shave off a considerable amount by running the shutdown component in its own domain. This domain does a lot of things that need a lot of scary permissions. However it is a short running process, and so from that perspective it may be worth pursuing seperating that.
- As for systemd daemons there are, in my view, globally three different kinds (not counting systemd daemon with and without units, or long and short running daemons)
- systemd daemons
- systemd daemons that are socket activated
- systemd daemons that maintain a pid file
systemd needs to be able to rw, i believe, unix stream socket of target daemon (and probably use fd), maybe more
systemd needs to be able to maintain the sockets of socket activated daemons and needs to be able to create sockets with the target daemon domain to accept connections (generally unix stream sockets and fifo files but i suppose also tcp for network socket activated (i haven't encountered those yet thankfully))
systemd needs to be able to read and delete pid files of systemd daemons that maintain a pid files
- finally, how to deal with daemons that are not covered by policy:
it is possible to eventually make systemd run everything with generic bin or shell types in a daemon domain designed for daemons not covered by policy. unfortunately it is, just like with legacy init scripts possible to enclose shell code with units or to execute generic commands, which does happen
for example the kill command is run regularely for within units, and this is sub-optimal because you will end up giving the domain meant for daemon not covered permissions to kill many other domains.
ofcourse in practice this domain will be pretty much unconfined anyways just like the existing initrc (by the way you might just run these daemons that arent covered in the initrc_t domain to save policy)
There is probably more, that i have overlooked.
my, currently operational (but abandoned) systemd policy (the one that has each and every component used at the time of development confined) is available on github.com/doverride/e145 (in the systemd sub directory)
I use this policy on my daily laptop, and it pretty much works flawlessly (in my particular setup and with my particular requirements at least)
The new rewrite (work in progress) is available here: github.com/doverride/example
These may or may not provide information that can be used to create something better
I am currently focussing on my own (example) policy model written in cil but hopefully some of the things i encountered can help others anticipate.
--
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20141031/d75372e4/attachment.bin
Le Fri, 31 Oct 2014 10:34:37 -0400,
"Christopher J. PeBenito" <[email protected]> a ?crit :
> One big shortcoming that refpolicy has had lately is missing a
> complete systemd policy. Since no one has upstreamed the policy,
> I've decided to start writing one, as the Fedora version cannot be
> upstreamed with out significant refactoring.
Thanks for working on this!
Russel already made some patched for the refpolicy using the fedora one
as base for a systemd policy, see:
http://anonscm.debian.org/cgit/selinux/refpolicy.git/tree/debian/patches
The policy is not 100% complete, some new tools have been added in the
latest releases.
But it could be maybe interesting to keep the same types name to
minimize the delta with the fedora policy?
> I am developing/staging this change in my personal fork of the
> repository:
>
> https://github.com/pebenito/refpolicy
>
> If you would like to contribute to this work, please use pull
> requests.
>
> When the policy is complete, there will be a period for comments
> on-list before it is merged to the main refpolicy tree.
>
As Dominick already commented on github, the service security class
seems to have 2 AV that are not used (anymore?).
The bus_unit_method_kill() function seem to use the "stop" AV instead
of a "kill" one. And the for the "load" one I'm not even sure to what
it is/was referring to.
As said in one of my previous mail, by greping the source for the
"mac_selinux_unit_access_check()" function in git HEAD, I'm arriving
to the following list:
+class service
+{
+ start
+ stop
+ status
+ reload
+ enable
+ disable
+}
On Sun, Nov 02, 2014 at 01:44:35PM +0100, Laurent Bigonville wrote:
>
> The bus_unit_method_kill() function seem to use the "stop" AV instead
> of a "kill" one. And the for the "load" one I'm not even sure to what
> it is/was referring to.
>
Unfortunate though that kill does not have its own av permission, as the kill option with systemctl can be used to send signals to the running daemon.
Some daemons take custom signals (SIGUSR etc) to do special things ( like for example auditd, and rotating logs )
I suppose for some reason it was not practical to implement a kill av permission for this
--
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20141102/222f7f36/attachment.bin
On 11/2/2014 7:44 AM, Laurent Bigonville wrote:
> Le Fri, 31 Oct 2014 10:34:37 -0400,
> "Christopher J. PeBenito" <[email protected]> a ?crit :
>
>> One big shortcoming that refpolicy has had lately is missing a
>> complete systemd policy. Since no one has upstreamed the policy,
>> I've decided to start writing one, as the Fedora version cannot be
>> upstreamed with out significant refactoring.
>
> Thanks for working on this!
>
> Russel already made some patched for the refpolicy using the fedora one
> as base for a systemd policy, see:
> http://anonscm.debian.org/cgit/selinux/refpolicy.git/tree/debian/patches
>
> The policy is not 100% complete, some new tools have been added in the
> latest releases.
>
> But it could be maybe interesting to keep the same types name to
> minimize the delta with the fedora policy?
I'll try to keep as compatible of possible, but I can't guarantee it.
> As Dominick already commented on github, the service security class
> seems to have 2 AV that are not used (anymore?).
>
> The bus_unit_method_kill() function seem to use the "stop" AV instead
> of a "kill" one. And the for the "load" one I'm not even sure to what
> it is/was referring to.
>
> As said in one of my previous mail, by greping the source for the
> "mac_selinux_unit_access_check()" function in git HEAD, I'm arriving
> to the following list:
>
> +class service
> +{
> + start
> + stop
> + status
> + reload
> + enable
> + disable
> +}
Thanks for looking at the source to doublecheck the permissions. Are
the extra (incorrect) permissions in the system object class still there?
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On 10/31/2014 12:00 PM, Dominick Grift wrote:
> On Fri, Oct 31, 2014 at 10:34:37AM -0400, Christopher J. PeBenito
> wrote:
>> One big shortcoming that refpolicy has had lately is missing a
>> complete systemd policy. Since no one has upstreamed the policy,
>> I've decided to start writing one, as the Fedora version cannot
>> be upstreamed with out significant refactoring.
>>
>> I am developing/staging this change in my personal fork of the
>> repository:
>>
>> https://github.com/pebenito/refpolicy
>>
>> If you would like to contribute to this work, please use pull
>> requests.
>>
>> When the policy is complete, there will be a period for comments
>> on-list before it is merged to the main refpolicy tree.
>>
>
> Here are some bullet points of some things one may or may not want
> to consider ( i am currently also in the process of rewriting my
> systemd policy and for some of these point i already made decisions
> while for others i am still considering my options.
>
> - i started my first version by confining each component just to
> see what fits where and does what. Here are some conclusions:
>
> There are atleast three components that can be started directly by
> processes with the kernel process identity:
>
> systemd-cgagent systemd-coredump systemd-bootchart
>
> It may or may not be worth it to transition out of kernel_t and
> into either one of more domains for these processes
Generally we never want userspace programs running as kernel_t. I'll
look at those components further, but I doubt we'll make an exception
here.
> - One component that stands out is the systemd-sysctl component.
> This component writes to sysctl proc files. Some of which almost no
> one else should ever touch. Therefore it might be worth it to run
> that in a seperate domain. In my personal policy i decided to, and
> it is by no means an optimal solution, /usr/sbin/sysctl and
> systemd-sysctl since boths programs write sysctl objects The issue
> is that one is a application and the other is a "systemd oneshot
> daemon"
>
> in my policy basically "sysctl_t" is the only type that can write
> some "sensitive" sysctl files that are commonly referred to as
> sysctl_security and sysctl_usermodehelper
>
> - Basically the remainder of, atleast the "short running"
> components could probbably be lumped together into a single helper
> domain ( there may be exceptions but none come to mind right now)
>
> - The long running system components should probably run outside of
> the systemd domain and inside their own respective domains
>
> - One thing i noticed was that although systemd eventually ends up
> with enough permissions to do serious damage to the system, it is
> possible to shave off a considerable amount by running the shutdown
> component in its own domain. This domain does a lot of things that
> need a lot of scary permissions. However it is a short running
> process, and so from that perspective it may be worth pursuing
> seperating that.
>
> - As for systemd daemons there are, in my view, globally three
> different kinds (not counting systemd daemon with and without
> units, or long and short running daemons) - systemd daemons -
> systemd daemons that are socket activated - systemd daemons that
> maintain a pid file
The first and third seem to be the same from the policy perspective,
other than the third has an extra type and some rules in it's local
policy. The second is the new one to the policy.
> systemd needs to be able to rw, i believe, unix stream socket of
> target daemon (and probably use fd), maybe more
For all daemons or just the socket-activated ones? What is the socket
for if it's not for socket activation?
> systemd needs to be able to maintain the sockets of socket
> activated daemons and needs to be able to create sockets with the
> target daemon domain to accept connections (generally unix stream
> sockets and fifo files but i suppose also tcp for network socket
> activated (i haven't encountered those yet thankfully))
I'd guess that network sockets are also possible, since that would
replace inetd functionality.
> systemd needs to be able to read and delete pid files of systemd
> daemons that maintain a pid files
>
> - finally, how to deal with daemons that are not covered by
> policy: it is possible to eventually make systemd run everything
> with generic bin or shell types in a daemon domain designed for
> daemons not covered by policy. unfortunately it is, just like with
> legacy init scripts possible to enclose shell code with units or to
> execute generic commands, which does happen for example the kill
> command is run regularely for within units, and this is sub-optimal
> because you will end up giving the domain meant for daemon not
> covered permissions to kill many other domains. ofcourse in
> practice this domain will be pretty much unconfined anyways just
> like the existing initrc (by the way you might just run these
> daemons that arent covered in the initrc_t domain to save policy)
>
> There is probably more, that i have overlooked.
That wouldn't be surprising since the entirety of systemd and it's
helper tools is massive.
> my, currently operational (but abandoned) systemd policy (the one
> that has each and every component used at the time of development
> confined) is available on github.com/doverride/e145 (in the systemd
> sub directory) I use this policy on my daily laptop, and it pretty
> much works flawlessly (in my particular setup and with my
> particular requirements at least)
I'll take a look. I'd prefer to leverage others work rather than
completely reinventing the wheel.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Mon, Nov 03, 2014 at 09:48:07AM -0500, Christopher J. PeBenito wrote:
> >
> > - As for systemd daemons there are, in my view, globally three
> > different kinds (not counting systemd daemon with and without
> > units, or long and short running daemons) - systemd daemons -
> > systemd daemons that are socket activated - systemd daemons that
> > maintain a pid file
>
> The first and third seem to be the same from the policy perspective,
> other than the third has an extra type and some rules in it's local
> policy. The second is the new one to the policy.
The difference between regular systemd daemons and systemd daemons that
maintain "systemd pid files" is that systemd needs to be able to read and delete the latters' pid files
So the daemons themselves do not delete them, but systemd does it for them
>
>
> > systemd needs to be able to rw, i believe, unix stream socket of
> > target daemon (and probably use fd), maybe more
>
> For all daemons or just the socket-activated ones? What is the socket
> for if it's not for socket activation?
>
I was not accurate:
(allow common_subject systemd_daemon_subject_type (process (signull)))
(call systemd_rw_unix_stream_sockets (systemd_daemon_subject_type))
(call systemd_read_state (systemd_daemon_subject_type))
1. systemd needs to send null signal to all daemons
2. all daemon need to rw (getattr read write ioctl) systemd unix_stream_socket
3. all daemon need to read system state
addiitonally if one decides to split shutdown out of systemd domain then all daemons also need to be able send child terminated signal to shutdown (because shutdown becomes pid 1 on shutdown
> >
> > There is probably more, that i have overlooked.
>
> That wouldn't be surprising since the entirety of systemd and it's
> helper tools is massive.
I would probably move systemd utmp out into its own domain since in maintains /run/utmp but probably not feasible for your configuration since init_t is probably already allow to maintain utmp anyways
--
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20141103/87ac2915/attachment.bin
On Mon, Nov 03, 2014 at 04:16:44PM +0100, Dominick Grift wrote:
>
> I was not accurate:
>
> (allow common_subject systemd_daemon_subject_type (process (signull)))
> (call systemd_rw_unix_stream_sockets (systemd_daemon_subject_type))
> (call systemd_read_state (systemd_daemon_subject_type))
>
> 1. systemd needs to send null signal to all daemons
Looks like systemd needs to send null signals to all processes period, but you can ignore that probably anyways since i suppose init_t is already allowed to send all signals to all processes
So yes its actually only all daemon reading/writing systemd unix stream sockets and reading systemd state
That applies to all daemons
then for socket activated daemons systemd needs to be able to create the sockets (its using setsockcreate() for that i think)
if the daemon maintains a pid file then systemd needs to read and delete that pid file
i basically created type attribute for the objects
(common_subject == init_t)
This for socket activation:
(allow common_subject systemd_socket_activated_subject_type
create_unix_dgram_stream_socket_perms)
(allow common_subject systemd_socket_activated_subject_type
create_unix_stream_stream_socket_perms)
(allow common_subject systemd_socket_activated_object_type
manage_dir_perms)
(allow common_subject systemd_socket_activated_object_type
relabel_dir_perms)
(allow common_subject systemd_socket_activated_object_type
manage_fifo_file_perms)
(allow common_subject systemd_socket_activated_object_type
relabel_fifo_file_perms)
(allow common_subject systemd_socket_activated_object_type
manage_sock_file_perms)
(allow common_subject systemd_socket_activated_object_type
relabel_sock_file_perms)
This for pid files
(call file_del_entry_generic_run (common_subject))
(call read_files_pattern
(common_subject systemd_pid_object_type systemd_pid_object_type))
(call delete_files_pattern
(common_subject systemd_pid_object_type systemd_pid_object_type))
--
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20141103/b1e27191/attachment.bin
Le Mon, 3 Nov 2014 09:32:35 -0500,
"Christopher J. PeBenito" <[email protected]> a ?crit :
> On 11/2/2014 7:44 AM, Laurent Bigonville wrote:
[...]
>
> > As Dominick already commented on github, the service security class
> > seems to have 2 AV that are not used (anymore?).
> >
> > The bus_unit_method_kill() function seem to use the "stop" AV
> > instead of a "kill" one. And the for the "load" one I'm not even
> > sure to what it is/was referring to.
> >
> > As said in one of my previous mail, by greping the source for the
> > "mac_selinux_unit_access_check()" function in git HEAD, I'm arriving
> > to the following list:
> >
> > +class service
> > +{
> > + start
> > + stop
> > + status
> > + reload
> > + enable
> > + disable
> > +}
>
> Thanks for looking at the source to doublecheck the permissions. Are
> the extra (incorrect) permissions in the system object class still
> there?
>
The "system" class is still used by systemd to add some of its own AV's
if that's what you mean.
https://bugzilla.redhat.com/show_bug.cgi?id=1132933
https://bugs.freedesktop.org/show_bug.cgi?id=81105
On 11/3/2014 4:50 PM, Laurent Bigonville wrote:
> Le Mon, 3 Nov 2014 09:32:35 -0500,
> "Christopher J. PeBenito" <[email protected]> a ?crit :
>
>> On 11/2/2014 7:44 AM, Laurent Bigonville wrote:
> [...]
>>
>>> As Dominick already commented on github, the service security class
>>> seems to have 2 AV that are not used (anymore?).
>>>
>>> The bus_unit_method_kill() function seem to use the "stop" AV
>>> instead of a "kill" one. And the for the "load" one I'm not even
>>> sure to what it is/was referring to.
>>>
>>> As said in one of my previous mail, by greping the source for the
>>> "mac_selinux_unit_access_check()" function in git HEAD, I'm arriving
>>> to the following list:
>>>
>>> +class service
>>> +{
>>> + start
>>> + stop
>>> + status
>>> + reload
>>> + enable
>>> + disable
>>> +}
>>
>> Thanks for looking at the source to doublecheck the permissions. Are
>> the extra (incorrect) permissions in the system object class still
>> there?
>>
>
> The "system" class is still used by systemd to add some of its own AV's
> if that's what you mean.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1132933
> https://bugs.freedesktop.org/show_bug.cgi?id=81105
Yes, that's what I meant, thanks.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
Le Fri, 31 Oct 2014 10:34:37 -0400,
"Christopher J. PeBenito" <[email protected]> a ?crit :
> One big shortcoming that refpolicy has had lately is missing a
> complete systemd policy. Since no one has upstreamed the policy,
> I've decided to start writing one, as the Fedora version cannot be
> upstreamed with out significant refactoring.
With systemd as PID1, the system dbus services are not started by the
udev daemon anymore but by systemd (PID1) itself. That means that ATM,
the dbus services are not properly transitioned to their own domain and
run under init_t. What should be done according to you? Modify
dbus_system_domain() to also allow transition from init_t? Modify all
the modules to that are using dbus_system_domain() and add
init_daemon_domain()?
On 11/15/2014 6:06 PM, Laurent Bigonville wrote:
> Le Fri, 31 Oct 2014 10:34:37 -0400,
> "Christopher J. PeBenito" <[email protected]> a ?crit :
>
>> One big shortcoming that refpolicy has had lately is missing a
>> complete systemd policy. Since no one has upstreamed the policy,
>> I've decided to start writing one, as the Fedora version cannot be
>> upstreamed with out significant refactoring.
>
> With systemd as PID1, the system dbus services are not started by the
> udev daemon anymore but by systemd (PID1) itself. That means that ATM,
> the dbus services are not properly transitioned to their own domain and
> run under init_t. What should be done according to you? Modify
> dbus_system_domain() to also allow transition from init_t? Modify all
> the modules to that are using dbus_system_domain() and add
> init_daemon_domain()?
I've been aware of this, but have not come to a conclusion on what the
right way forward is.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com