From: dac.override@gmail.com (Dominick Grift) Date: Sun, 7 Aug 2016 13:58:10 +0200 Subject: [refpolicy] are we going to have unit file types? In-Reply-To: <6eacd8b9-4e09-a400-1373-e7d581c8aaec@ieee.org> References: <20160731124041.fxzedsuloxfbgnz2@athena.coker.com.au> <20160731143556.GC8181@meriadoc> <201608022216.06786.russell@coker.com.au> <2ca303f1-3a52-a41f-4684-2de641f9db55@ieee.org> <20160803030828.GC29738@meriadoc.perfinion.com> <6eacd8b9-4e09-a400-1373-e7d581c8aaec@ieee.org> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/06/2016 10:05 PM, Chris PeBenito wrote: > On 08/02/16 23:08, Jason Zaman wrote: >> On Tue, Aug 02, 2016 at 07:26:23PM -0400, Chris PeBenito wrote: >>> On 08/02/16 08:16, Russell Coker wrote: >>>> On Mon, 1 Aug 2016 12:35:56 AM Jason Zaman wrote: >>>>> On Sun, Jul 31, 2016 at 10:40:41PM +1000, Russell Coker wrote: >>>>>> Below is a patch that's been in my Debian tree for some time, I didn't >>>>>> write it I took it from rawhide some years ago. >>>>>> >>>>>> >>>>>> >>>>>> Is this the way we are going to do things? If so I can tidy it up and >>>>>> submit it. If not I'll delete it and make the Debian policy work without >>>>>> it. >>>>>> >>>>>> >>>>>> >>>>>> Note that I am not suggesting this patch for inclusion at the >>>>>> moment. I'm just offering it for discussion. >>>>> >>>>> We have unit files in refpol yeah, they are different from the stuff in >>>>> redhat tho i think. >>>>> >>>>> A whole bunch like this for example: >>>>> mandb.te:type mandb_unit_t; >>>>> mandb.te:init_unit_file(mandb_unit_t) >>>>> mandb.fc:/usr/lib/systemd/system/[^/]*man-db.* -- gen_context(system_ >>>>> u:object_r:mandb_unit_t,s0) >>>> >>>> Thanks for the pointer. >>>> >>>> Is the plan that every daemon domain will get a _unit_t type? I've revised >>> >>> There weren't any specific plans to ensure all daemons have a unit, but >>> I'm open to that. >> >> There somewhat were. At least cases where there was a foo_initrc_exec_t >> should probably also have a _unit_t. I added init_startstop_service() to >> a ton of things a while back. The intention was that it takes pretty >> much everything needed for all the different types of init daemons >> (sysvinit, openrc, upstart, systemd) and gives the perms for it in >> tunables/booleans. The unit param is optional still tho cuz not all >> domains have it yet I think. >> >> I also just realized that all the fcontexts in the policy are only for >> /usr/lib/systemd/system/ but units can also be in /etc/ or /run. Do we >> need to add a subs_dist for this? > > I don't think so. The /etc ones are considered local configuration, so > that probably needs something like local_unit_t. The /run ones don't > either as those are runtime units. There is a github issue I opened for > it forever ago: > > [1] https://github.com/TresysTechnology/refpolicy/issues/12 > I am still hoping that systemctl will add setfscreatecon functionality so that systemd edit (--force) $UNIT will create units and unit drop-ins with the specified context. That would be nice for confined administration. So in DSSP i currently have a equivalence for /usr/lib/systemd/{system,user} /etc/systemd/{system,user} Runtime units have random names and are managed on runtime so you can't associate private labels with individual runtime units. I basically only differentiate between system and user runtime units -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160807/206a3253/attachment.bin