From: dac.override@gmail.com (Dominick Grift) Date: Fri, 31 Oct 2014 17:00:01 +0100 Subject: [refpolicy] systemd In-Reply-To: <54539DFD.6000408@tresys.com> References: <54539DFD.6000408@tresys.com> Message-ID: <20141031160000.GA4928@e145.network2> To: refpolicy@oss.tresys.com List-Id: refpolicy.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