Re: user_r/sysadm_r/staff_r/unconfined_r

[Dominick Grift <dac.override@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2194 bytes --]

On Tue, Nov 04, 2014 at 10:37:18PM +1100, Russell Coker wrote:
> 
> I think that sysadm_r/unconfined_r should not transition for programs like gpg.

I do not agree, To me the only thing that sets sysadm_t apart from unconfined_t is that sysadm_t is a strict domain.

Meaning where unconfined_t would run some program in the calling unconfined_t domain, sysadm_t would transition to the domain of the program. Unfortunately this currenlty often is not the case.

Walsh once said, and i quote: "sysadm_t is a drunken unconfined_t". He has a point there and it should not be like that. sysadm_t should be a strict domain whereas unconfined_t is just some semi-exemption domain

unconfined_t runs for example gpg in the unconfined_t domain , and sysadm_t runs it in the gpg_t domain

> 
> NB staff_r is my invention. Before that we only had sysadm_r and user_r. I invented staff_r before MCS and the seuser constraints were developed. 

As for using optional security attributes/models to achieve something that is often not optional:

It think that is a bad idea. MCS/MLS is optional and so are the UBAC constraints. In my view they should remain optional

My stance is that this should all be up to individuals to decide instead of part of refpolicy.

I recently created a policy model called splash and this, kind of, looks like how i envision the perfect refpolicy. (although it abuses CIL name spaces and it only deals with objects that are present in my system)

https://github.com/doverride/splash

This policy (provided it is fixed/finished and bug free) works on all systems. Sure by itself it provides almost no protection but that is not the point of the policy. It is a common base. 

I am kind of hoping for a refcilpolicy 2.0 with all this applied. Also something that does not strictly rely on policycoreutils-semanage (e.g. something that is just as suitable for embedded systems)

> 
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

-- 
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]