[refpolicy] are we going to have unit file types?

[dac.override@gmail.com (Dominick Grift)]

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