user_r/sysadm_r/staff_r/unconfined_r

user_r/sysadm_r/staff_r/unconfined_r

[Russell Coker]

The role separation seems to give no benefit apart from sysadm_r/unconfined_r given that we have seuser based constraints and MCS labels to separate users and that they all use the same types.

The current policy doesn't support even logging in with a user other than unconfined_r on Debian/Unstable without significant changes.

Is there any reason for not ripping out all but 2 roles, one for root (and other sysadmin accounts but not GNOME/KDE sessions) and the other for regukar users?

Doing that will make the policy smaller and simpler (for us and users) while not losing any functionality for most users. Where most users probably means everyone who doesn't develop their own policy. The people who do develop their own policy which depends on multiple roles probably have to do plenty of work on systems with the current policy anyway.

I think that sysadm_r/unconfined_r should not transition for programs like gpg.

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. 
-- 
Sent from my Samsung Galaxy Note 3 with K-9 Mail.

Re: user_r/sysadm_r/staff_r/unconfined_r

[Sven Vermeulen]

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

On Nov 4, 2014 12:46 PM, "Russell Coker" <russell@coker.com.au> wrote:
>
> The role separation seems to give no benefit apart from
sysadm_r/unconfined_r given that we have seuser based constraints and MCS
labels to separate users and that they all use the same types.

I disagree. Roles allow for restricting the domains that users can
transition into. I use them often for granting users "limited root". For
instance dbadm_r for DBAs versus webadm_r for web app server admins.

Wkr,
  Sven Vermeulen

[-- Attachment #2: Type: text/html, Size: 649 bytes --]

Re: user_r/sysadm_r/staff_r/unconfined_r

[Russell Coker]

We could use the seuser and/or MCS fields to restrict running the programs that enter the domains in question. 

Also now it's an issue of systemd access which changes things a bit, I haven't looked into this yet.

On November 5, 2014 12:31:48 AM GMT+11:00, Sven Vermeulen <sven.vermeulen@siphos.be> wrote:
>On Nov 4, 2014 12:46 PM, "Russell Coker" <russell@coker.com.au> wrote:
>>
>> The role separation seems to give no benefit apart from
>sysadm_r/unconfined_r given that we have seuser based constraints and
>MCS
>labels to separate users and that they all use the same types.
>
>I disagree. Roles allow for restricting the domains that users can
>transition into. I use them often for granting users "limited root".
>For
>instance dbadm_r for DBAs versus webadm_r for web app server admins.
>
>Wkr,
>  Sven Vermeulen
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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.

-- 
Sent from my Samsung Galaxy Note 3 with K-9 Mail.

Re: user_r/sysadm_r/staff_r/unconfined_r

[Dominick Grift]

On Tue, 2014-11-04 at 22:37 +1100, Russell Coker wrote:
> The role separation seems to give no benefit apart from sysadm_r/unconfined_r given that we have seuser based constraints and MCS labels to separate users and that they all use the same types.
> 
> The current policy doesn't support even logging in with a user other than unconfined_r on Debian/Unstable without significant changes.
> 
> Is there any reason for not ripping out all but 2 roles, one for root (and other sysadmin accounts but not GNOME/KDE sessions) and the other for regukar users?
> 
> Doing that will make the policy smaller and simpler (for us and users) while not losing any functionality for most users. Where most users probably means everyone who doesn't develop their own policy. The people who do develop their own policy which depends on multiple roles probably have to do plenty of work on systems with the current policy anyway.
> 
> I think that sysadm_r/unconfined_r should not transition for programs like gpg.
> 
> 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. 

Wrong list.

Should refpolicy have user domains at all? Should it have more than a
single domain? As soon as one starts defining a domain one starts
assuming.

In my view plain refpolicy should be nothing more that what is currently
in the kernel layer plus unconfined module and maybe the libraries
module. Maybe constraints.

For sure not an init, authlogin modules etc.

the sole domain kernel_t should in my view ship unconfined, and if for
some reason one really want a user domain then add a unconfined user

Ref policies job would be to maintain core objects like devices, top
level file partitioning, network objects. That is it.

It would be very small and it would be base for all, because there are
almost no decisions made for who ever builds on it

Then on the side there could be a repository with individual add-on
scenario's

It kind of like base and contrib now, but taken further

Re: user_r/sysadm_r/staff_r/unconfined_r

[Miroslav Grepl]

On 11/04/2014 03:38 PM, Dominick Grift wrote:
> On Tue, 2014-11-04 at 22:37 +1100, Russell Coker wrote:
>> The role separation seems to give no benefit apart from sysadm_r/unconfined_r given that we have seuser based constraints and MCS labels to separate users and that they all use the same types.
>>
>> The current policy doesn't support even logging in with a user other than unconfined_r on Debian/Unstable without significant changes.
>>
>> Is there any reason for not ripping out all but 2 roles, one for root (and other sysadmin accounts but not GNOME/KDE sessions) and the other for regukar users?
>>
>> Doing that will make the policy smaller and simpler (for us and users) while not losing any functionality for most users. Where most users probably means everyone who doesn't develop their own policy. The people who do develop their own policy which depends on multiple roles probably have to do plenty of work on systems with the current policy anyway.
>>
>> I think that sysadm_r/unconfined_r should not transition for programs like gpg.
>>
>> 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.
> Wrong list.
>
> Should refpolicy have user domains at all? Should it have more than a
> single domain? As soon as one starts defining a domain one starts
> assuming.
>
> In my view plain refpolicy should be nothing more that what is currently
> in the kernel layer plus unconfined module and maybe the libraries
> module. Maybe constraints.
>
> For sure not an init, authlogin modules etc.
>
> the sole domain kernel_t should in my view ship unconfined, and if for
> some reason one really want a user domain then add a unconfined user
>
> Ref policies job would be to maintain core objects like devices, top
> level file partitioning, network objects. That is it.
>
> It would be very small and it would be base for all, because there are
> almost no decisions made for who ever builds on it
>
> Then on the side there could be a repository with individual add-on
> scenario's
>
> It kind of like base and contrib now, but taken further
Yes. I believe this is good for a discussion. Let's move it on the 
proper list.
>
>
>
> _______________________________________________
> 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.

Re: user_r/sysadm_r/staff_r/unconfined_r

[Dominick Grift]

[-- 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 --]