From casper@sac.sfbay.sun.com Fri Feb 26 01:35:59 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1Q9Zx3x007948 for ; Fri, 26 Feb 2010 01:35:59 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1Q9ZwKG006579; Fri, 26 Feb 2010 03:35:59 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KYF00J05ZZYIY00@nwk-avmta-2.sfbay.sun.com>; Fri, 26 Feb 2010 01:35:58 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KYF009QTZZYGI80@nwk-avmta-2.sfbay.sun.com>; Fri, 26 Feb 2010 01:35:58 -0800 (PST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1Q9Zw1U006505; Fri, 26 Feb 2010 01:35:58 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1Q9ZvAK007943; Fri, 26 Feb 2010 01:35:57 -0800 (PST) Received: (from casper@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o1Q9ZveC007939; Fri, 26 Feb 2010 01:35:57 -0800 (PST) Date: Fri, 26 Feb 2010 01:35:57 -0800 (PST) From: Casper Dik Subject: RBAC update: user attrs from profiles [PSARC/2010/072 FastTrack timeout 03/03/2010] To: PSARC-ext@sun.com Message-id: <201002260935.o1Q9ZveC007939@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 6379 Template Version: @(#)sac_nextcase 1.69 02/15/10 SMI This information is Copyright 2010 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: RBAC update: user attrs from profiles 1.2. Name of Document Author/Supplier: Author: Casper Dik 1.3 Date of This Document: 26 February, 2010 4. Technical Description I'm sponsoring this fasttrack for myself. This project proposes updates to the rbac implementation. Release binding: minor. The current rbac implementation has several shortcomings: - it's not easy to override the default privileges defined in /etc/security/policy.conf - every user *always* inherits whatever is specified in /etc/security/policy.conf: AUTHS_GRANTED, PROFS_GRANTED To fix these problems, this fasttrack defines the following new features: The prof_attr(4) database supports two new keywords: defaultpriv, limitpriv; they have the same semantics as they have in user_attr(4). On establishing a user credential, the profiles database is searched and the first match for each keyword is returned. The new system defined profile "Stop"; when this profile is encountered it excludes all the later profiles which would normally be encountered. Specifically, if a user has a profile in its list which includes "Stop", then the PROFS_GRANTED profiles are never considered for this user and the AUTHS_GRANTED are ignored. --- getauthattr.3 Mon Feb 15 17:16:50 2010 +++ getauthattr.3.new Thu Feb 25 16:26:08 2010 @@ -52,24 +52,27 @@ open auth_attr file, deallocate storage, and so forth. The chkauthattr() function verifies whether or not a user has a - given authorization. It first reads the AUTHS_GRANTED key in the - /etc/security/policy.conf file and returns 1 if it finds a match - for the given authorization. If chkauthattr() does not find a - match and the username is the name of the "console user", defined - as the owner of /dev/console, it first reads the CONSOLE_USER key - in /etc/security/policy.conf and returns 1 if the given authori- - zation is in any of the profiles specified in the CONSOLE_USER - keyword, then reads the PROFS_GRANTED key in - /etc/security/policy.conf and returns 1 if the given authoriza- - tion is in any profiles specified with the PROFS_GRANTED keyword. - If a match is not found from the default authorizations and - default profiles, chkauthattr() reads the user_attr(4) database. + given authorization. It first reads the user_attr(4) database + and returns 1 if it finds a match for the given authorization. If it does not find a match in user_attr, it reads the prof_attr(4) database, using the list of profiles assigned to the - user, and checks if any of the profiles assigned to the user has - the given authorization. The chkauthattr() function returns 0 if - it does not find a match in any of the three sources or if the - user does not exist. + user, and checks if any of the profiles assigned to the user + has the given authorization. When chkauthattr() finds a + profile called "Stop", further profiles are ignored and the + authorizations and profiles mentioned in /etc/security/policy.conf + are ignored and it returns 0. If it does not find a match in + the user's profiles, chkauthattr() reads the AUTHS_GRANTED key in + the /etc/security/policy.conf file and returns 1 if it finds + a match for the given authorization. If chkauthattr() does not + find a match and the username is the name of the "console user", + defined as the owner of /dev/console, it first reads the + CONSOLE_USER key in /etc/security/policy.conf and returns 1 if the + given authorization is in any of the profiles specified in the + CONSOLE_USER keyword, then reads the PROFS_GRANTED key in + /etc/security/policy.conf and returns 1 if the given authorization + is in any profiles specified with the PROFS_GRANTED keyword. + The chkauthattr() function returns 0 if it does not find a match in + any of the three sources or if the user does not exist. A user is considered to have been assigned an authorization if either of the following are true: --- prof_attr.4 Mon Feb 15 17:05:17 2010 +++ prof_attr.4.new Tue Feb 23 09:33:19 2010 @@ -43,8 +43,8 @@ attr An optional list of semicolon-separated (;) key-value pairs that describe the security attributes to apply to the object upon execution. Zero or more keys can - be specified. There are four valid keys: help, pro- - files, auths, and privs. + be specified. There are six valid keys: help, pro- + files, auths, privs, defaultpriv and limitpriv. help is assigned the name of a file ending in .htm or .html. @@ -65,6 +65,11 @@ priv_names(4) database. These privileges can then be used for executing commands with pfexec(1). + defaultpriv, limitpriv have the same semantics as in + user_attr(4). If they are not specified in the + user_attr(4) database, the assigned profiles are searched + until a match is found. + EXAMPLES Example 1 Allowing Execution of All Commands --- profiles.1 Mon Feb 15 17:06:10 2010 +++ profiles.1.new Thu Feb 25 16:28:00 2010 @@ -26,6 +26,13 @@ For convenience, a wild card can be specified to match all com- mands. + The special profile "Stop" short-cuts the evaluations of further + profiles; profiles seen after the "Stop" profile are not + evaluated nor are they used to find additional commands. + This profile can be used to side-step profiles listed in + /etc/security/policy.conf with the PROF_GRANTED key and the + authorizations listed with AUTH_GRANTED in that file. + When profiles are interpreted, the profile list is loaded from user_attr(4). If any default profile is defined in /etc/security/policy.conf (see policy.conf(4)), the list of 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: os-net 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Moffat@sun.com Fri Feb 26 02:00:44 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1QA0iJV008547 for ; Fri, 26 Feb 2010 02:00:44 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1QA0dBV023581 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 26 Feb 2010 04:00:44 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KYG00L1F1570I00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 26 Feb 2010 02:00:43 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KYG009YI156GD80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 26 Feb 2010 02:00:43 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1QA0eYu009989 for ; Fri, 26 Feb 2010 10:00:41 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KYF00J00YN2VH00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 26 Feb 2010 10:00:24 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KYG00H2D14CG560@fe-emea-10.sun.com>; Fri, 26 Feb 2010 10:00:13 +0000 (GMT) Date: Fri, 26 Feb 2010 10:00:11 +0000 From: Darren J Moffat Subject: Re: RBAC update: user attrs from profiles [PSARC/2010/072 FastTrack timeout 03/03/2010] In-reply-to: <201002260935.o1Q9ZveC007939@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Casper Dik Cc: PSARC-ext@sun.com Message-id: <4B879BAB.2010901@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201002260935.o1Q9ZveC007939@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 2224 On 26/02/2010 09:35, Casper Dik wrote: > > Template Version: @(#)sac_nextcase 1.69 02/15/10 SMI > This information is Copyright 2010 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > RBAC update: user attrs from profiles > 1.2. Name of Document Author/Supplier: > Author: Casper Dik > 1.3 Date of This Document: > 26 February, 2010 > 4. Technical Description > I'm sponsoring this fasttrack for myself. > > This project proposes updates to the rbac implementation. > > Release binding: minor. > > The current rbac implementation has several shortcomings: > > - it's not easy to override the default privileges > defined in /etc/security/policy.conf > > - every user *always* inherits whatever is specified in > /etc/security/policy.conf: AUTHS_GRANTED, PROFS_GRANTED > > > To fix these problems, this fasttrack defines the following new > features: > > > The prof_attr(4) database supports two new keywords: > defaultpriv, limitpriv; they have the same semantics as they > have in user_attr(4). On establishing a user credential, > the profiles database is searched and the first match for > each keyword is returned. Why just those two ? In general other than "type" I think all of the user_attr(4) keywords should be applicable in prof_attr (I wouldn't object to type being able to be specified in prof_attr though). In particular: roles, project, lock_after_retries but all the others too. For me project would be the most useful of those but I can see an need for the others too. Similarly the TX specific ones would be useful in prof_attr(4) for defining collections of users all with the same operating label range (min_label and clearance keywords). > The new system defined profile "Stop"; when this profile > is encountered it excludes all the later profiles which would > normally be encountered. Specifically, if a user has a profile > in its list which includes "Stop", then the PROFS_GRANTED > profiles are never considered for this user and the > AUTHS_GRANTED are ignored. This is a very useful feature and I know of several customer deployments where this would have been very valuable. Glad to see it. -- Darren J Moffat From casper@holland.sun.com Fri Feb 26 02:29:13 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1QATD8M008871 for ; Fri, 26 Feb 2010 02:29:13 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1QATCS6029978 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Fri, 26 Feb 2010 02:29:13 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KYG00K292GPLJ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 26 Feb 2010 02:29:13 -0800 (PST) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KYG00FEB2GJTIB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 26 Feb 2010 02:29:08 -0800 (PST) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1QAT6mb011469; Fri, 26 Feb 2010 10:29:06 +0000 (GMT) Date: Fri, 26 Feb 2010 11:29:06 +0100 From: Casper.Dik@sun.com Subject: Re: RBAC update: user attrs from profiles [PSARC/2010/072 FastTrack timeout 03/03/2010] In-reply-to: <4B879BAB.2010901@Sun.COM> Sender: casper@holland.sun.com To: Darren J Moffat Cc: Casper Dik , PSARC-ext@sun.com Message-id: <201002261029.o1QAT6mb011469@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201002260935.o1Q9ZveC007939@sac.sfbay.sun.com> <4B879BAB.2010901@Sun.COM> Status: RO Content-Length: 876 >Why just those two ? In general other than "type" I think all of the >user_attr(4) keywords should be applicable in prof_attr (I wouldn't >object to type being able to be specified in prof_attr though). >In particular: roles, project, lock_after_retries but all the others >too. For me project would be the most useful of those but I can see an >need for the others too. > >Similarly the TX specific ones would be useful in prof_attr(4) for >defining collections of users all with the same operating label range >(min_label and clearance keywords). While I agree with assessment in principle, each and every additional keyword requires the same amount of additional code, so it's not "free" to add additional keywords. I want to implement these keywords first and then we'll have a discussion about the additional keywords and the market requirements. Casper From Darren.Moffat@sun.com Fri Feb 26 02:56:53 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1QAurAa009272 for ; Fri, 26 Feb 2010 02:56:53 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o1QAumF5049192 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 26 Feb 2010 03:56:53 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KYG004233QSQ700@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 26 Feb 2010 02:56:52 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KYG00FWG3QQT3B0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 26 Feb 2010 02:56:51 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1QAuonU007733 for ; Fri, 26 Feb 2010 10:56:50 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KYG00I001B45P00@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 26 Feb 2010 10:56:31 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KYG00D793Q2EIB0@fe-emea-09.sun.com>; Fri, 26 Feb 2010 10:56:26 +0000 (GMT) Date: Fri, 26 Feb 2010 10:56:26 +0000 From: Darren J Moffat Subject: Re: RBAC update: user attrs from profiles [PSARC/2010/072 FastTrack timeout 03/03/2010] In-reply-to: <201002261029.o1QAT6mb011469@dm-holland-02.uk.sun.com> Sender: Darren.Moffat@sun.com To: Casper.Dik@sun.com Cc: Casper Dik , PSARC-ext@sun.com Message-id: <4B87A8DA.1080509@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201002260935.o1Q9ZveC007939@sac.sfbay.sun.com> <4B879BAB.2010901@Sun.COM> <201002261029.o1QAT6mb011469@dm-holland-02.uk.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 1165 On 26/02/2010 10:29, Casper.Dik@Sun.COM wrote: > >> Why just those two ? In general other than "type" I think all of the >> user_attr(4) keywords should be applicable in prof_attr (I wouldn't >> object to type being able to be specified in prof_attr though). > >> In particular: roles, project, lock_after_retries but all the others >> too. For me project would be the most useful of those but I can see an >> need for the others too. >> >> Similarly the TX specific ones would be useful in prof_attr(4) for >> defining collections of users all with the same operating label range >> (min_label and clearance keywords). > > While I agree with assessment in principle, each and every additional > keyword requires the same amount of additional code, so it's not "free" > to add additional keywords. > > I want to implement these keywords first and then we'll have a discussion > about the additional keywords and the market requirements. I'm happy with that, particularly since there are a couple of existing user_attr(4) keywords (idlecmd, idletime) that are probably EOF given CDE is no longer shipped. The case gets my +1 as specified. -- Darren J Moffat From gww@sac.sfbay.sun.com Mon Mar 1 17:28:24 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o221SOGX009458 for ; Mon, 1 Mar 2010 17:28:24 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o221SObt019789 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 1 Mar 2010 17:28:24 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KYM0020RS3B6H00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Mar 2010 17:28:23 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KYM003GZS3B2OD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Mar 2010 17:28:23 -0800 (PST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o221SMmP003860; Mon, 01 Mar 2010 17:28:22 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o221SMVw009455; Mon, 01 Mar 2010 17:28:22 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o221SMe9009454; Mon, 01 Mar 2010 17:28:22 -0800 (PST) Date: Mon, 01 Mar 2010 17:28:22 -0800 (PST) From: Gary Winiger Subject: Re: RBAC update: user attrs from profiles [PSARC/2010/072 FastTrack timeout 03/03/2010] To: PSARC-ext@sun.com, casper.dik@sun.com Message-id: <201003020128.o221SMe9009454@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2085 > This project proposes updates to the rbac implementation. > > Release binding: minor. > > The current rbac implementation has several shortcomings: The project team doesn't say why these are shortcomings. I was having a hard time getting the motivation. Fortunately in an offline discussion today, it was pointed out that the particular use model was for a "kiosk user" model and that the intent was to explicitly define specific user accounts that would be restricted as an exception to the architecture introduced when RBAC was introduced. Given that I too am happy with the case (+1), but have a few nits with the specification that I'd like acknowledged. > - it's not easy to override the default privileges > defined in /etc/security/policy.conf > > - every user *always* inherits whatever is specified in > /etc/security/policy.conf: AUTHS_GRANTED, PROFS_GRANTED And the "console owner" gets the CONSOLE_USER. > To fix these problems, this fasttrack defines the following new > features: > > > The prof_attr(4) database supports two new keywords: > defaultpriv, limitpriv; they have the same semantics as they > have in user_attr(4). On establishing a user credential, > the profiles database is searched and the first match for > each keyword is returned. There is nothing inherent in this proposal that will stop getting other keywords. In particular audit_flags as specified in PSARC/2010/003, EOL and removal of audit_user(4) and getausernam(3bsm). > The new system defined profile "Stop"; when this profile > is encountered it excludes all the later profiles which would > normally be encountered. Specifically, if a user has a profile > in its list which includes "Stop", then the PROFS_GRANTED > profiles are never considered for this user and the > AUTHS_GRANTED are ignored. Additionally if the user is the "console owner", the CONSOLE_USER profiles are never considered for this user. Only authorizations seem to be explicitly addressed here. How are executables addressed? That is the use of pfexec? Gary.. From casper@holland.sun.com Tue Mar 2 00:33:44 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o228Xi4A001727 for ; Tue, 2 Mar 2010 00:33:44 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o228Xhaf009381 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 2 Mar 2010 02:33:44 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KYN00D0BBS7ZX00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Mar 2010 00:33:43 -0800 (PST) Received: from dm-holland-01.uk.sun.com ([129.156.101.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KYN00CPDBS5TI10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Mar 2010 00:33:42 -0800 (PST) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-01.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o228Xep7027823; Tue, 02 Mar 2010 08:33:40 +0000 (GMT) Date: Tue, 02 Mar 2010 09:33:39 +0100 From: Casper.Dik@sun.com Subject: Re: RBAC update: user attrs from profiles [PSARC/2010/072 FastTrack timeout 03/03/2010] In-reply-to: <201003020128.o221SMe9009454@sac.sfbay.sun.com> Sender: casper@holland.sun.com To: Gary Winiger Cc: PSARC-ext@sun.com Message-id: <201003020833.o228Xep7027823@dm-holland-01.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003020128.o221SMe9009454@sac.sfbay.sun.com> Status: RO Content-Length: 2361 >> This project proposes updates to the rbac implementation. >> >> Release binding: minor. >> >> The current rbac implementation has several shortcomings: > > The project team doesn't say why these are shortcomings. > I was having a hard time getting the motivation. Fortunately > in an offline discussion today, it was pointed out that > the particular use model was for a "kiosk user" model and that > the intent was to explicitly define specific user accounts > that would be restricted as an exception to the architecture > introduced when RBAC was introduced. > > Given that I too am happy with the case (+1), but have a few nits > with the specification that I'd like acknowledged. >> - it's not easy to override the default privileges >> defined in /etc/security/policy.conf >> >> - every user *always* inherits whatever is specified in >> /etc/security/policy.conf: AUTHS_GRANTED, PROFS_GRANTED > > And the "console owner" gets the CONSOLE_USER. Currently you cannot make a "pf*sh" like a restricted shell. You get "Basic Solaris User" and also "All". This is the reason why we have the "stop" profile: it removes the additional profiles, include all those listed in policy.conf (including, console_user). I allows a "restricted" shell without having to build a controlled directory. > There is nothing inherent in this proposal that will stop > getting other keywords. In particular audit_flags as > specified in PSARC/2010/003, EOL and removal of audit_user(4) > and getausernam(3bsm). Correct. Each and every keyword requires a similar amount of work: you do not get the others for free and that is why I have limited myself to these keywords. >> The new system defined profile "Stop"; when this profile >> is encountered it excludes all the later profiles which would >> normally be encountered. Specifically, if a user has a profile >> in its list which includes "Stop", then the PROFS_GRANTED >> profiles are never considered for this user and the >> AUTHS_GRANTED are ignored. > > Additionally if the user is the "console owner", the CONSOLE_USER > profiles are never considered for this user. > > Only authorizations seem to be explicitly addressed here. How are > executables addressed? That is the use of pfexec? Through the profiles. There are no "defaults" exec attributes listed in policy.conf. Casper From gww@sac.sfbay.sun.com Tue Mar 2 21:04:00 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o23540cF026627 for ; Tue, 2 Mar 2010 21:04:00 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2353w25028279 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 2 Mar 2010 21:04:00 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KYO0020LWQNSL00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Mar 2010 22:03:59 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KYO00M12WQMNF20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Mar 2010 22:03:59 -0700 (MST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2353vWA002318; Tue, 02 Mar 2010 21:03:57 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2353vd9026624; Tue, 02 Mar 2010 21:03:57 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o2353v4A026623; Tue, 02 Mar 2010 21:03:57 -0800 (PST) Date: Tue, 02 Mar 2010 21:03:57 -0800 (PST) From: Gary Winiger Subject: Re: RBAC update: user attrs from profiles [PSARC/2010/072 FastTrack timeout 03/03/2010] To: Casper.Dik@sun.com Cc: PSARC-ext@sun.com Message-id: <201003030503.o2353v4A026623@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 375 > > Only authorizations seem to be explicitly addressed here. How are > > executables addressed? That is the use of pfexec? > > Through the profiles. There are no "defaults" exec attributes listed in > policy.conf. So you're saying that the pfexec search as well as the auth search stops at the "Stop" reserved Rights Profile name. That answers my question. Gary.. From casper@holland.sun.com Wed Mar 3 00:03:21 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2383KnV026613 for ; Wed, 3 Mar 2010 00:03:21 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2383Gq5007660 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Mar 2010 02:03:20 -0600 (CST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KYP00M0X513I200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Mar 2010 01:03:03 -0700 (MST) Received: from dm-holland-01.uk.sun.com ([129.156.101.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KYP00MHE512NDB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Mar 2010 01:03:03 -0700 (MST) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-01.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o23831FR028892; Wed, 03 Mar 2010 08:03:01 +0000 (GMT) Date: Wed, 03 Mar 2010 09:03:01 +0100 From: Casper.Dik@sun.com Subject: Re: RBAC update: user attrs from profiles [PSARC/2010/072 FastTrack timeout 03/03/2010] In-reply-to: <201003030503.o2353v4A026623@sac.sfbay.sun.com> Sender: casper@holland.sun.com To: Gary Winiger Cc: PSARC-ext@sun.com Message-id: <201003030803.o23831FR028892@dm-holland-01.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003030503.o2353v4A026623@sac.sfbay.sun.com> Status: RO Content-Length: 402 >> > Only authorizations seem to be explicitly addressed here. How are >> > executables addressed? That is the use of pfexec? >> >> Through the profiles. There are no "defaults" exec attributes listed in >> policy.conf. > > So you're saying that the pfexec search as well as the auth > search stops at the "Stop" reserved Rights Profile name. > > That answers my question. Yes, correct. Casper From gww@sac.sfbay.sun.com Wed Mar 3 12:27:48 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o23KRmV1006086 for ; Wed, 3 Mar 2010 12:27:48 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o23KRlTh015795 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Mar 2010 12:27:47 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KYQ00H0F3IBOG00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Mar 2010 12:27:47 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KYQ00GC23I9FW70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Mar 2010 12:27:46 -0800 (PST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o23KRiuZ002470; Wed, 03 Mar 2010 12:27:44 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o23KRiT9006083; Wed, 03 Mar 2010 12:27:44 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o23KRiNx006082; Wed, 03 Mar 2010 12:27:44 -0800 (PST) Date: Wed, 03 Mar 2010 12:27:44 -0800 (PST) From: Gary Winiger Subject: Re: RBAC update: user attrs from profiles [PSARC/2010/072 FastTrack timeout 03/03/2010] To: PSARC-ext@sun.com, casper.dik@sun.com Message-id: <201003032027.o23KRiNx006082@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 148 > This project proposes updates to the rbac implementation. > > Release binding: minor. This case was approved at today's PSARC meeting. Gary..