From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sA4BbYoN011431 for ; Tue, 4 Nov 2014 06:37:34 -0500 Received: from [192.168.0.11] (ppp118-209-31-33.lns20.mel4.internode.on.net [118.209.31.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: russell@coker.com.au) by smtp.sws.net.au (Postfix) with ESMTPSA id 36F612085D for ; Tue, 4 Nov 2014 22:37:28 +1100 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Subject: user_r/sysadm_r/staff_r/unconfined_r From: Russell Coker Date: Tue, 04 Nov 2014 22:37:18 +1100 To: selinux@tycho.nsa.gov Message-ID: <0AFA7D5E-B2E1-43BA-875B-AC941EB36E50@coker.com.au> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sA4DVpxT018645 for ; Tue, 4 Nov 2014 08:31:51 -0500 Received: by mail-oi0-f41.google.com with SMTP id e131so10478491oig.0 for ; Tue, 04 Nov 2014 05:31:48 -0800 (PST) MIME-Version: 1.0 Sender: sven.j.vermeulen@gmail.com In-Reply-To: <0AFA7D5E-B2E1-43BA-875B-AC941EB36E50@coker.com.au> References: <0AFA7D5E-B2E1-43BA-875B-AC941EB36E50@coker.com.au> Date: Tue, 4 Nov 2014 14:31:48 +0100 Message-ID: Subject: Re: user_r/sysadm_r/staff_r/unconfined_r From: Sven Vermeulen To: SELinux Content-Type: multipart/alternative; boundary=001a1137dd48375b8e0507087c63 List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --001a1137dd48375b8e0507087c63 Content-Type: text/plain; charset=UTF-8 On Nov 4, 2014 12:46 PM, "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. 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 --001a1137dd48375b8e0507087c63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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/uncon= fined_r given that we have seuser based constraints and MCS labels to separ= ate users and that they all use the same types.

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

Wkr,
=C2=A0 Sven Vermeulen

--001a1137dd48375b8e0507087c63-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sA4EC6Vs022096 for ; Tue, 4 Nov 2014 09:12:07 -0500 In-Reply-To: References: <0AFA7D5E-B2E1-43BA-875B-AC941EB36E50@coker.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Subject: Re: user_r/sysadm_r/staff_r/unconfined_r From: Russell Coker Date: Wed, 05 Nov 2014 01:11:57 +1100 To: Sven Vermeulen , SELinux Message-ID: <9B0301A1-299E-40E8-814E-F69E84D3D861@coker.com.au> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: 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 wrote: >On Nov 4, 2014 12:46 PM, "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. > >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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sA4Ectw7024316 for ; Tue, 4 Nov 2014 09:38:55 -0500 Received: by mail-wi0-f182.google.com with SMTP id d1so9454968wiv.9 for ; Tue, 04 Nov 2014 06:38:53 -0800 (PST) Message-ID: <1415111931.22097.11.camel@joe.localdomain> Subject: Re: user_r/sysadm_r/staff_r/unconfined_r From: Dominick Grift To: Russell Coker Date: Tue, 04 Nov 2014 15:38:51 +0100 In-Reply-To: <0AFA7D5E-B2E1-43BA-875B-AC941EB36E50@coker.com.au> References: <0AFA7D5E-B2E1-43BA-875B-AC941EB36E50@coker.com.au> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Cc: selinux@tycho.nsa.gov List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sA5ANaoA026388 for ; Wed, 5 Nov 2014 05:23:36 -0500 Message-ID: <5459FA97.2080000@redhat.com> Date: Wed, 05 Nov 2014 11:23:19 +0100 From: Miroslav Grepl MIME-Version: 1.0 To: Dominick Grift , Russell Coker Subject: Re: user_r/sysadm_r/staff_r/unconfined_r References: <0AFA7D5E-B2E1-43BA-875B-AC941EB36E50@coker.com.au> <1415111931.22097.11.camel@joe.localdomain> In-Reply-To: <1415111931.22097.11.camel@joe.localdomain> Content-Type: text/plain; charset=windows-1252; format=flowed Cc: selinux@tycho.nsa.gov List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id sA5G1Os3016188 for ; Wed, 5 Nov 2014 11:01:25 -0500 Received: by mail-wi0-f180.google.com with SMTP id hi2so2475807wib.1 for ; Wed, 05 Nov 2014 08:00:57 -0800 (PST) Received: from e145.network2 ([84.245.1.4]) by mx.google.com with ESMTPSA id 10sm4538813wjs.21.2014.11.05.08.00.55 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Nov 2014 08:00:56 -0800 (PST) Date: Wed, 5 Nov 2014 17:00:54 +0100 From: Dominick Grift To: selinux@tycho.nsa.gov Subject: Re: user_r/sysadm_r/staff_r/unconfined_r Message-ID: <20141105160051.GA25500@e145.network2> References: <0AFA7D5E-B2E1-43BA-875B-AC941EB36E50@coker.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" In-Reply-To: <0AFA7D5E-B2E1-43BA-875B-AC941EB36E50@coker.com.au> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 04, 2014 at 10:37:18PM +1100, Russell Coker wrote: >=20 > I think that sysadm_r/unconfined_r should not transition for programs lik= e gpg. I do not agree, To me the only thing that sets sysadm_t apart from unconfin= ed_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. Unfortun= ately 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 d= omain 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 >=20 > 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.=20 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 constr= aints. 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 li= ke how i envision the perfect refpolicy. (although it abuses CIL name space= s 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 syste= ms. Sure by itself it provides almost no protection but that is not the poi= nt of the policy. It is a common base.=20 I am kind of hoping for a refcilpolicy 2.0 with all this applied. Also some= thing that does not strictly rely on policycoreutils-semanage (e.g. somethi= ng that is just as suitable for embedded systems) >=20 > _______________________________________________ > 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= =2Egov. --=20 Dominick Grift --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCgAGBQJUWkmuAAoJENAR6kfG5xmcYDcL+wSmODA79P3LYS1EwEQ6d+Ue irdGuursvVAfR/z+uURpXQJNK2QjQRN5aOPwx24XjC7S2IzPsdaSctkvZU6bz1zf jKdDxxpilGWC7+s2W02qt6IFp1KFn0QfK6KYfB9P0oXfUWk+6Y8s5+sNpDZ0/B0u yBEYog+9nLvo3MLH8dHi3k4rNTDJlbGndMGQtasTFDUWmNPDb1s8NjHg3iCe6KMu sUfn03XjRBUxKNzuGp7p+15ZczloeQZ9N8lZ7BoE/WkgbNtjn1iV2roF68nnFFAb 0YV8NDiFlfK5ueg4Sj2tFzViBVynBR5z/fJ8suJfimXWcGysqWCwFIPAMIY+kShj LBB3NDqcAReMkvfVLlkYRY6ciEPyeuw1dWm9wblaPNK4V5x+NkUkKKJRMmAwqyna GRJGqJtc7z1dXqnh3IjDy4YF0q/b9EbRTfUG9j6LCLkH4DW72q8HJrmFI4twPUEd L8sdfroXw95YWSKxp0mLr7lNehrLO26n0UFhL1YLZw== =/Le1 -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP--