RBAC update: user attrs from profiles [PSARC/2010/072 FastTrack timeout 03/03/2010]
> This project proposes updates to the rbac implementation. > > Release binding: minor. This case was approved at today's PSARC meeting. Gary..
RBAC update: user attrs from profiles [PSARC/2010/072 FastTrack timeout 03/03/2010]
> > 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..
RBAC update: user attrs from profiles [PSARC/2010/072 FastTrack timeout 03/03/2010]
> 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..
Network Auto-Magic (NWAM) Phase 1 Updates part 2 (PSARC 2010/049)
> PSARC 2008/532 NWAM Phase 1 > PSARC 2009/577 Network Auto-Magic (NWAM) Phase 1 Updates +1 And see below for a code review comment. Gary.. >any of these. The Network Autoconf profile is now split into the >Network Autoconf User and Network Autoconf Admin profiles. The User >profile is assigned to the console user, and allows the user to activate >profiles, and create/modify Known WLAN entries. The Admin profile >includes all authorizations given to the User profile, plus the ability >to create and modify NWAM profiles. The way to do this is to include the User profile in the Admin profile with the "profiles=" keyword.
PSARC/2009/642 audit_control(4) EOL and removal
> I'm sponsoring this case for Jan Friedel and the Solaris Audit project team. > It is the second phase of converting the audit service configuration to > SMF. The first phase was PSARC/2009/022 audit_startup(1m) EOL and removal. This case was approved at today's PSARC meeting. Gary..
PSARC/2009/642 audit_control(4) EOL and removal
> All logins, not just root login? Sharon Proposal: Project Private properties are added to auditd(1m). 7) Deliver the service manifest with slightly different default configuration from what audit_control contained (flags lo, naflags lo, plugin audit_binfile(5) active). audit_control flags were empty and naflags were lo, which would audit for failed events of the "login" class, but not for successful ones. The change is to audit both successful and failed logins when auditing is enabled. audit_binfile default is unchanged. Gary..
PSARC/2009/642 audit_control(4) EOL and removal
I'm sponsoring this case for Jan Friedel and the Solaris Audit project team. It is the second phase of converting the audit service configuration to SMF. The first phase was PSARC/2009/022 audit_startup(1m) EOL and removal. PSARC/2008/787 Obsolete of some Solaris Audit commands and PSARC/2009/636 Obsolete getacinfo(3bsm) announced Obsolescence (EOF) of a number Solaris Audit interfaces in the next Patch release. When the audit service, auditd(1m), was created (6232332 auditd should run under SMF) as part of the conversion from /etc/rc scripts to SMF (PSARC/2002/547 Greenline) the configuration information in audit_startup(1m) and audit_control(4) were not converted. This case proposes to provide the configuration information contained in audit_control in audit service private properties and to remove audit_control(4) in a Minor release. Copies of the Obsolete audit_control(4) and getacinfo(3bsm) man pages, a diff marked auditconfig(1m) man page and the new proposed audit_flags(5) man page, as well as the delivered audit_control file are in the case directory. The interface taxonomy of auditconfig(1m) is unchange (Committed). For reference purposes a "references" subdirectory is provided with other related man pages and a prototype audit service manifest. The timer is set for 19 Jan 2010. Gary.. + Background: == audit_control(4) is a file that contains configuration of the default audit classes (flags: and naflags: keywords) [see audit_flags(5) and audit_class(4)] and audit trail destinations (plugin: keyword) [the dir: and minfree: keywords were effectively EOLed but not removed by PSARC/2002/150 Secure Remote Audit Log -- "Secure" a misnomer here]. An administrator can configure these by editing the audit_control file. Proposal: Project Private properties are added to auditd(1m). 1) Remove the Obsolete Committed audit_control(4) file from the system. 2) As the audit_control(4) file was not world readable, add Project Private read protected SMF property groups (PSARC/2007/177 SMF Read-Protected Property Storage) to contain the persistent values for the default audit flags and audit trail destinations. 3) Remove the Obsolete Committed getacinfo(3bsm) APIs from the system. These interfaces are used to access fields in the audit_control file. 4) Add project private properties to the audit service to contain the information in the removed audit_control file. 5) Add auditconfig(1m) subcommands -getflags, -getnaflags, -getplugin, -setflags, -setnaflags, -setplugin to display and set the default audit classes and audit trail destinations. 6) Modify auditd(1m) to initialize the default audit classes and audit trail destinations from audit service properties. 7) Deliver the service manifest with slightly different default configuration from what audit_control contained (flags lo, naflags lo, plugin audit_binfile(5) active). audit_control flags were empty and naflags were lo, which would audit for failed events of the "login" class, but not for successful ones. The change is to audit both successful and failed logins when auditing is enabled. audit_binfile default is unchanged. 8) Update au_user_mask(3bsm) to use default audit classes configured in the audit service. auditconfig(1m): NAME auditconfig - configure auditing SYNOPSIS auditconfig subcommand ... SUBCOMMANDS +-getflags +Display the default audit preselection flags. +-getnaflags +Display the non-attributable audit mask. +-getplugin [name] +Display information about the plugin name. If name is not +specified, display all plugins. +-setflags audit_flags +Set the default audit classes, see audit_flags(5). The default +audit classes are combined with the user's specific audit +flags to form the user's process audit preselection mask. +-setnaflags audit_flags +Set the non-attributable audit classes, see audit_flags(5). +Non-attributable audit classes define what classes of events +are to be audited when the action cannot be attributed to +an authenticated user. Failed login is an example of an +event that is non-attributable. +-setplugin name active | inactive [ attributes [ qsize]] +Configure the plugin name to be "active" or "inactive". +Optionally configure the attributes and number of +unprocessed audit records to queue for the plugin. +See the audit plugin man pages and auditd(1m). NOTES +The change to plugins (-setplugin) settings do not take effect +(such as becoming active or inactive, changing the active attribute +or queue size values) until the audit service is refreshed. Use +audit(1M) to refresh the audit service. Notes: == 1) Activation of u
User object audit token [PSARC/2010/001 FastTrack timeout 01/11/2010]]
For some reason, this never made it to the case log or my inbox. Sorry for the delay. > From: Richard L. Hamilton > To: opensolaris-arc at opensolaris.org > Subject: Re: User object audit token [PSARC/2010/001 FastTrack timeout > 01/11/2010] > Date: Sat, 02 Jan 2010 05:39:59 -0800 (PST) > > Is the user SID also in audit output? If it isn't, shouldn't it be, if > available, esp. > if the UID is ephemeral? Wouldn't it be worth recording for forensics? The short answer is no presuming SIDs are Windows Security IDs as opposed to Solaris Audit Session IDs. Windows SIDs are not presently part of OpenSolaris. Auditing covers identified and authenticated users logged into OpenSolaris. No OpenSolaris user has an ephemeral user ID. The purpose of the user object token is to represent a user as the object of some action, not as the subject of an action. In particular, as noted in the case "passwd -f" auditing would be served well by being able to express the user as an object in a searchable way. Thus, the motivation for this new token. Cheers, Gary..
User object audit token [PSARC/2010/001 FastTrack timeout 01/11/2010]
This case was approved at today's PSARC meeting. Gary..
Reserved uid/gid for distinguishing unmappable users/groups in NFSv4 ACLs [PSARC/2009/683 FastTrack timeout 01/06/2010]
Darren writes: > While I think it is unfortunate we need yet another special uid/gid for > this it seems like the only workable solution (I'd already discussed > this offline with the project team). So I'm happy to given this case a > +1 as specified. I agree with Darren, it's unfortunate (and that nobody4 cannot be repurposed). Tim writes: > Proposed Solution: > -- > > The /etc/passwd entry will be as follows: > unknown:x:96:96:Unknown Remote UID:/: > > The /etc/shadow entry will be as follows: > unknown:NP::: Why is this being proposed as a nologin account (NP) rather than a locked account (*LK*)? Why does unknown need to run jobs on the system? +1 if a locked account. Gary..
Improving the use and debugging of the basic privilege set. [PSARC/2009/686 FastTrack timeout 01/01/2010]
> --- priv_addset.3 Mon Dec 21 12:08:24 2009 > +++ priv_addset.3.new Mon Dec 21 12:10:00 2009 > @@ -20,6 +20,8 @@ > > void priv_emptyset(priv_set_t *sp); > > + void priv_basicset(priv_set_t *sp); > + > void priv_fillset(priv_set_t *sp); > > void priv_freeset(priv_set_t *sp); > @@ -58,6 +60,8 @@ > > The priv_emptyset() function clears all privileges from sp. > > + The priv_basicset() function copies the basic privilege set to sp. > + > The priv_fillset() function asserts all privileges in sp, includ- > ing the privileges not currently defined in the system. +1 Gary..
Basic Network Privilege [PSARC/2009/685 FastTrack timeout 01/01/2010]
> I want to clarify the definition of the NET_ACCESS privilege as follows: > > privilege NET_ACCESS > > Allows a process to open a TCP, UDP or SCTP network endpoint. > > > This makes clear that ICMP and RAW sockets do not require more than the > NET_ICMPACCESS or NET_RAWACCESS. +1 Gary..
User object audit token [PSARC/2010/001 FastTrack timeout 01/11/2010]
I'm sponsoring the case on behalf of myself, the Audit Project Team and the RBAC and Admin Project Team. It requests a Patch Release Binding. However, there is no intention to back port unless there is a business need to do so. The exposed interfaces were never formally ARCed. They have been treated as Committed by the Audit Project team for some time. The man pages are updated to indicate this. The project requests a Committed Interface Taxonomy for the proposed changes. Full diff-marked man pages are in the case directory. The timer is set for 11 Jan, 2010. Gary.. ~~ Background: == Audit records include information on who did what to what. The who is the subject of the audit record, the what is the audit event and the to what is the object of the audit record. Audit records are generally searchable based on who, what and to what by auditreduce(1m). Audit records dealing with the administration of user attributes are not searchable for the user affected. Present audit records contain a text token of the user name. Examples of such audit records are those generated by passwd user, passwd -f user, usermod user. Text tokens are generally used for supplemental information not object identifiers. Current object types include "path" for files, "fmri" for FMRIs, "ipc" for System V IPC, "process" for processes. Proposal: Add a new audit token named "user" and permit selection of audit records that contain that user value. The auditreduce user object user name is the same form as the other auditreduce user specifications. The actual token value is both a uid_t and a user name string. Both are needed for the case where the user has been removed from the system and the name to uid translation is not available. audit.log(4): NAME audit.log - audit trail file DESCRIPTION The audit.log files contains audit records. Each audit record is made up of audit tokens. Each record contains a header token followed by various data tokens. Depending on the audit policy in place by auditon(2), optional other tokens such as trailers or sequences may be included. +The user token consists of: + token ID1 byte + user ID 4 bytes + user name length2 bytes + user nameincluding terminating NULL byte auditreduce(1m): +++ NAME auditreduce - merge and select audit records from audit trail files SYNOPSIS auditreduce [options] [audit-trail-file]... OPTIONS Record Selection Options The record selection options listed below are used to indi- cate which records are written to the output file produced by auditreduce. Multiple arguments of the same type are not permitted. -o object_type=objectID_value Select records by object type. A match occurs when the record contains the information describing the specified object_type and the object ID equals the value specified by objectID_value. The allowable object types and values are as follows: + user=user name +Select records containing the user object whose name +is specified. User objects are generally specified +for administrative actions on a user.
PSARC/2008/195 Validated Execution
At the request of the project team, this case has been superseded by PSARC/2009/676 Validated Execution Umbrella Case. Gary..
PSARC 2009/576 pam_krb5 pkinit - final spec
> I've attached updated pam_krb5.5 and pam_krb5.5.diffmarked. +1 Gary..
PSARC 2009/576 pam_krb5 pkinit - final spec
> The final spec and man page for the pam_krb5 pkinit project > have been put into the case directory. If there are no > further objections, this case should get approved at the meeting > this week. From message 60 of 17 Nov and not yet answered: Gary.. == >From pkinit-final: "The pam_krb5 password module will change in that if PKINIT authentication was done it will return PAM_IGNORE in the following cases: - the new passwd is NULL - the old passwd is NULL - verification of the old passwd fails. If none of the above is true then pam_krb tries to change the password and will return an error if that fails. The rational behind this is if some PAM module causes pam_acct_mgmt() to return PAM_NEW_AUTHTOK_REQD and/or the app subsequently calls pam_chauthtok(), pam_krb5 will change a user's password. But this may well fail: the KDC may not want to allow a PKINIT user to change/set a password since the user may be expected to use PKINIT." This information does not seem to be in the man page. How does the administrator know it? Not being a pkinit expert, I'd like to understand how the password stack will know if the user was authenticated by pkinit? I feel TCR strong that the man page needs to be complete relative to this part of the spec. I'm also concerned that pam_krb5 in the password stack won't likely be called without PAM_AUTHTOK or PAM_OLDAUTHTOK set. Which call to pam_sm_chauthtok() PAM_PRELIM_CHECK and/or PAM_UPDATE_AUTHTOK will be making these checks?
2009/661 [noaclfab share option]
> Improving ACL fabrication and making it do a better job of approximating > NFSv4 ACL, will still have the following problem: > > >> > >> - The user could retrieve the fabricated ACL on the client and attempt > >> to perform some operation only to be denied when the "real" ACL is > >> evaluated on the server. This was my compelling reason for not doing my normal, I hate configuration options, please fix it so ACL fabrication works. IMO, it can't be reasonably fixed because ACL/ACE are different. That's something we/the ARC accepted in the ZFS and NFSv4 cases. Gary..
[kerberos-discuss] PSARC/2009/576 final spec
> > One question; should pam_krb5 doing PKINIT ever try using the password > > acquired via pam_authtok_get as the PIN if pam_krb5 is stacked below > > pam_authtok_get like so: > > > >login auth required pam_unix_cred.so.1 > >login auth sufficient pam_krb5.so.1 pkinit > >login auth requisite pam_authtok_get.so.1 > >login auth required pam_dhkeys.so.1 > >login auth required pam_unix_auth.so.1 > > ? > > > > I was thinking that pam_krb5 could try doing PKINIT preauth with the > > user's password and if that failed would try PKINIT preauth again, this > > time prompting for the user's PIN. If that is a bad idea then pam_krb5 > > doing PKINIT would ignore the user's password and always prompt for the > > PIN regardless of where it was in the auth stack. IMO, it is a site configuration error to put pkinit below authtok_get. That said, it is possible for applications to set PAM_AUTHTOK before calling pam_authenticate. IMO, you either have an administrative error, or an application error. I'd say, if PAM_AUTHTOK is set to use it rather than prompt. If it locks out the card, the admin/application will be noted as buggy. Gary..
noaclfab share option [PSARC/2009/661 FastTrack timeout 12/11/2009]
> I'm sponsoring this fast-track on behalf of Vallish Vaidyeshwara (RPE). > This case seeks minor binding. Is this really only needed in Solaris Next? It seems OK to me for a Patch binding if needed. +1 for either binding. Gary..
delete obsolete system call traps [PSARC/2009/657]
> I am sponsoring this fast-track case for myself. > > No external/ABI interfaces are changing, so there is no documentation change. I don't see any mention of how Solaris Audit will be affected. I've not looked at the current implementation to see how each of the current syscalls maps into audit events. Are all the current audit events preserved? Gary..
Software Events Notification Parameters CLI [PSARC/2009/617 FastTrack timeout 11/18/2009]
> setnotfy and delnotify are just wrappers that create and delete > properties and property groups. The auditing of these operations are > handled by the standard property and property group add/modify/delete > audit records. Do you think a more robust auditing is required here? OK, thanks. +1 Gary.. > Gary Winiger wrote: > >> New exported interface Stability Binding > >> --- > >> setnotify subcommand of svccfg(1M) Committed Patch > >> listnotify subcommand of svccfg(1M) Committed Patch > >> delnotify subcommand of svccfg(1M) Committed Patch > > > > It seems to me that setnotify and delnotify would qualify > > as auditable administrative actions. I see no mention of > > audit.
Obsolete getacinfo(3bsm) [PSARC/2009/636 Self Review]
I'm sponsoring this case for myself and the the Solaris Audit project team. I believe it qualifies for self review and am marking it closed approved automatic. I'm happy to turn it into a fast track and set the timer if anyone believes I've misjudged. The case requests an obselescence announcement in a Patch release for potential removal in a Minor release. For convenience full diff-marked man pages are in the case directory. Gary.. == Background: +++ PSARC/2008/787 "Obsolete of some Solaris Audit commands" changed the interface taxonomy of the audit_control(4) file to Obsolete Committed and announced it in a Solaris 10 update. getacinfo(3bsm) is a set of library interfaces that extract fields from the audit_control file. With the potential for removal of the audit_control file, interfaces to extract fields from the will no longer work. Auditing was introduced some time around SunOS 5.2 and getacinfo() was never ARCed or assigned a formal Interface Taxonomy. This case assumes that it is form of Stable. The project team assumes Evolving (now Committed). Proposal: + * Change the Interface Taxonomies of getacinfo(3bsm) to Obsolete Committed in a Patch release of Solaris. * Add a paragraph to the man page NOTES section: These functions are Obsolete and may be removed and replaced with equivalent functionality in a future release of Solaris. * Add an announcement in the "What's New in the Solaris Release" document: A previous What's New announced that in a future release, the configuration file for controlling the audit service -- auditd(1M), audit_control(4), may be removed and replaced with equivalent functionality. In a future release that removes audit_control(4), getacinfo(3bsm) - get audit control file information will also be removed. As discussed in PSARC/2008/787, the intent is to move functionality of [audit_startup and] audit_control into the SMF service svc:/system/auditd (auditd(1M)). As PSARC/2009/022 "audit_startup(1m) EOL and removal" did for audit_startup, a future case will be submitted for the actual EOL and removal of audit_control(4) and getacinfo(3bsm).
snmp-notify: SNMP Notification Daemon for Software Events [PSARC/2009/618 FastTrack timeout 11/18/2009]
> >> Additionally this case seems not to follow the SMF policy for > >> configuring properties. See > >> http://sac.eng.sun.com/cgi-bin/bp.cgi?NAME=SMF.bp > >> (there is an opensolsaris.org equivalent, but that website is > >> not presently responding so I can't cut a paste the url). > >> See appendix D relative to value_authorization. > > > > > > Ok - let me look through this and get back. > > Ah - ok - I see what you mean now. I've added the following authorizations > for > configuring the service properties for the two daemons, respectively: > > solaris.smf.value.smtp-notify > solaris.smf.value.snmp-notify You've answered my issues. And as commented at today's PSARC meeting, uid 0 and all privs is (unfortunately) required by the underlying channel initialization infrastructure. > I've added these two authorizations to the "Event Notification Agent > Management" > profile (which also encapsulates the manage authorizations for these two > daemons) > > I've also made the appropriate modifications to the service manifests. +1 Gary..
smtp-notify: Email Notification Daemon for Software Events [PSARC/2009/619 FastTrack timeout 11/18/2009]
> > of by the daemon? If so, why isn't that the choice. If not, > > why not? > > > The daemon needs to start as uid/gid 0, because it needs to create/bind a > sysevent channel during initialization. Afterward doing this, it reduces > it's privilege set to the minimal set noted above and changes its uid/gid > to user noaccess (60002). As commented at today's PSARC meeting uid 0 and all privs is (unfortunately) required by the underlying channel initialization infrastructure. +1 Gary..
snmp-notify: SNMP Notification Daemon for Software Events [PSARC/2009/618 FastTrack timeout 11/18/2009]
> Rob's sent me updated materials which reflect the clarifications due > to the conversation here around privileges and the removal of > config/debug from the manpages. > > I've put them in the case directory. > config/rootdir > > This is an astring property that defaults to "/". >When set, the specified root directory will be used for >all pathnames evaluated by snmp-notify. > 4.11. Security Impact: > > During daemon initialization, the smtp-notify daemon will reduce its > privileges to the following minimal set: > > afsr# ppriv 103247 > 103247: /usr/lib/fm/notify/snmp-notify > flags = PRIV_AWARE > E: basic > I: basic > P: basic > L: basic > > The case will introduce the following new authorization for management > of the smtp-notify service: > > solaris.smf.manage.snmp-notify > > This case also introduces the "Event Notification Agent Management" > profile which will include the above authorization as well as the new > authorization being added for the smtp-notify service. Similar to 2009/619, Can this privilege reduction be done with a method context instead of by the daemon? If so, why isn't that the choice? If not, why not? What uid/gid does the daemon run with and why -- unless it is noaccess. Additionally this case seems not to follow the SMF policy for configuring properties. See http://sac.eng.sun.com/cgi-bin/bp.cgi?NAME=SMF.bp (there is an opensolsaris.org equivalent, but that website is not presently responding so I can't cut a paste the url). See appendix D relative to value_authorization. Nit, I suspect there's a case dependency on PSARC/2009/617 Gary..
smtp-notify: Email Notification Daemon for Software Events [PSARC/2009/619 FastTrack timeout 11/18/2009]
> Rob's sent me updated materials which reflect the clarifications due > to the conversation here around privileges and the removal of > config/debug from the manpages. > > I've put them in the case directory. > 4.11. Security Impact: > During daemon initialization, the smtp-notify daemon will reduce its > privileges to the following minimal set: > > afsr# ppriv 104651 > 104651: /usr/lib/fm/notify/smtp-notify > flags = PRIV_AWARE > E: basic,proc_setid > I: basic,proc_setid > P: basic,proc_setid > L: basic,proc_setid The updated materials don't state what uid(s)/gid(s) the service runs with. If it starts with uid/gid 0 and changes it's uid/gid, what is the new uid? Note: proc_setid Allow a process to set its UIDs at will, assuming UID 0 requires all privileges to be asserted. Can this privilege reduction be done with a method context instead of by the daemon? If so, why isn't that the choice. If not, why not? Nit, I suspect there's a case dependency on PSARC/2009/617 Gary..
Software Events Notification Parameters CLI [PSARC/2009/617 FastTrack timeout 11/18/2009]
> New exported interface Stability Binding > --- > setnotify subcommand of svccfg(1M) Committed Patch > listnotify subcommand of svccfg(1M) Committed Patch > delnotify subcommand of svccfg(1M) Committed Patch It seems to me that setnotify and delnotify would qualify as auditable administrative actions. I see no mention of audit. Gary..
PSARC 2009/576 pam_krb5 PKINIT support - APPROVED
> > The submitter has updated the spec and I believe all of the issues have > > been addressed. The timer expired yesterday, this case is now > > approved. > > I believe this is premature. In any case Darren and I discussed > things Wed afternoon and came up with a number of points. Again thanks for the time to do another review. I split out the "final" man page into the case directory for easier viewing. Using it as the "final" spec along with pkinit-final.txt, unfortunately, I believe there are still open issues. I've been told the project team is on holiday. I'll move the timer to 3 Dec if the project team is not at the next PSARC meeting. As I said, Darren and I chatted last week. (I'm sure he'll correct me if I've misstated our conversation.) I also received unsolicited mail from someone in the Sun field who supports large customers stating that PAM is difficult enough to configure, so my previous points 1 and 2 should not be taken lightly. That was also part of Darren and my discussion. 1 I'm still uncomfortable with stacking pam_krb5 multiple times within the same stack type. IMO, it will lead to more confusion than the cost of generating a new module. I'll "hold my nose[tm]" here and hope the project team doesn't get customer calls. 2 I'm uncomfortable about keying off of an empty PAM_AUTHTOK to mean do PKINIT. See above. With this input in mind, I'm no longer comfortable holding my nose and feel TCR strong about having this resolved. Darren and I believe there are straight forward solutions to 1-2: * provide a separate pam_pkinit module (my and the field person's preference), * add a "pkinit" option to pam_krb5. and do not key off of an empty PAM_AUTHTOK. I feel TCA strong about the separate module. Given the project's schedule, according to the manager, first chance to integrate isn't until 2010/02, I believe factoring the code, most of which is library, into a separate module is doable and the cleanest way to view a pam.conf configuration. The man page and pkinit-final differ with respect to keying off of PAM items: "In order to avoid misleading prompting by pam_authtok_get (which assumes a password must be prompted for) pam_krb5 would be modified to do its own prompting when it determines that the PAM_USER and PAM_AUTHTOK are not available which indicates it is above pam_authtok_get in the auth stack. pam_krb5 would assume at this point that PKINIT is to be used to acquire the user's Kerberos credential. If PKINIT fails to acquire a Kerberos credential an error would be returned." I assume that the man page is accurate and only PAM_AUTHOTK is keyed (recall the TCR strongness to resolve this as above). Relative to my previous point 3 3 In the case of stacking two pam_krb5(5) modules such that the first will pass through to pam_authtok_get(5), I'm unclear from the pam_sm_authenticate() spec what pam_authtok_get will do. Please specify what PAM items are set by the first instance so the admin knows what they will get from pam_authtok_get. I suspect there are two cases here: * PKINIT is not done, or fails; * PKINIT succeeds. The man page seems silent, however pkinit-final says: "pam_krb does not set any PAM items when doing PKINIT on the auth stack." Independent of how pkinit is stacked, PAM_USER must be set to the authenticated user's name if the auth stack succeeds. Perhaps I've missed something in my reading, I don't see where PAM_USER is set by this proposal. (Calling pam_get_user(3) ensures that PAM_USER is set ;-) Viz: + login auth required pam_unix_cred.so.1 + login auth sufficient pam_krb5.so.1 + login auth requisite pam_authtok_get.so.1 + login auth required pam_dhkeys.so.1 + login auth required pam_unix_auth.so.1 >From pkinit-final: "The pam_krb5 password module will change in that if PKINIT authentication was done it will return PAM_IGNORE in the following cases: - the new passwd is NULL - the old passwd is NULL - verification of the old passwd fails. If none of the above is true then pam_krb tries to change the password and will return an error if that fails. The rational behind this is if some PAM module causes pam_acct_mgmt() to return PAM_NEW_AUTHTOK_REQD and/or the app subsequently calls pam_chauthtok(), pam_krb5 will change a user's password. But this may well fail: the KDC may not want to allow a PKINIT user to change/set a password since the user may be expected to use PKINIT." This information does not seem to be in the man page. How does the administrator know it? Not being a pkinit expert, I'd like to understand how the password stack will know if the user was authenticate
acpihpd ACPI Hotplug Daemon [PSARC/2009/551 fast-track timeout 10/19/2009]
Gerry, > Please also refer to inline comments below. > Thanks! > --Gerry > > Gary Winiger <mailto:gww at eng.sun.com> wrote: > > Mike, > > > >> I'm working with Intel to answer your questions. Essentially we > >> want to provide the least amount of access possible for this daemon > >> to do its job. > > > > IIRC, my initial question had 3 parts: How does the project meet > > the SMF requirement for authorizations to manage? What is the > > Method Context used to start the service? The service is to be > We haven't defined any method_environment, method_profile, > method_credential or method_context properties in the manifest file. > So it should use the default configuration, is that OK? Not really. The point is to meet the principle of least privilege. That is done with a method_context in the start method. The default method_context is euid=ruid=egid=rgid = 0, privs = all. Why is this required for this service? What above noaccess, privs = none is actually required? > > enabled only on the xxx platform - how is this done? > The service will be enabled on all x86 platforms. We provide an x86 > specific package named SUNWacpihpd, which includes the service > manifest file for acpihpd. When installing the package, the acpihpd > service should be installed and enabled. So seems we don't need to > touch the platform profile file, is that true? I personally don't know about how the platform profiles are intended to be used. Contact the smf team about that. The SMF usage policy http://hub.opensolaris.org/bin/view/Community+Group+arc/SMF%2Dpolicy states: "Services must be delivered (by manifest or programatically) disabled by default to align with Sun's security goals. Projects impacted by Appendix C, must consult with the ARC to determine if this aspect of the policy is applicable." So, it seems that the project team should address why and how the service is enabled. > > I'd like to clarify the first part about authorizations. When > > we talked I may not have been complete. > > If there are no properties that configure the service as in > > a property group of type application, there is no need for > > value authorizations to manage them. > Currently acpihpd service doesn't define any properties of category > "application", so seems we don't need to define the "modify_authorization", > "value_authorization" and "read_authorization" security properties. > Is that true? "application" type property groups are not the only types that have configurable properties. The question is about any/all configurable properties. Property group types are arbitrary. > > If the service is never intended to be enabled/disabled by > > the administrator (but always enabled/started automatically > > at boot time and never disabled), there is no need for > > action/value authorizations to manage the service. > The service should always be enabled and not intended to be managed > by administrators. So there are no circumstances that the service should be disabled? Then I think the open questions are: 1) what is the least user/group ids and privileges? 2) how is the service enabled? 3) is there any configuration? Gary..
PSARC 2009/576 pam_krb5 PKINIT support - APPROVED
> The submitter has updated the spec and I believe all of the issues have > been addressed. The timer expired yesterday, this case is now > approved. I believe this is premature. In any case Darren and I discussed things Wed afternoon and came up with a number of points. Since he was traveling, I was going to send them. I've not had the chance to do so yet. I'll review whter the case stands by next meeting to ensure the outstanding issues are resolved. Gary..
[kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009]
> I think this is > sufficient for now and it doesn't preclude adding module options or a > krb5.conf stanza (or even user_attr(4) name=value pairs) to control this > in the future. Hopefully pam_eval will be a longer term way of doing this. > I'm happy with the latest spec that has been proposed. I asked for through today at the meeting. Here's my summary: 1 I'm still uncomfortable with stacking pam_krb5 multiple times within the same stack type. IMO, it will lead to more confusion than the cost of generating a new module. I'll "hold my nose[tm]" here and hope the project team doesn't get customer calls. 2 I'm uncomfortable about keying off of an empty PAM_AUTHTOK to mean do PKINIT. See above. 3 In the case of stacking two pam_krb5(5) modules such that the first will pass through to pam_authtok_get(5), I'm unclear from the pam_sm_authenticate() spec what pam_authtok_get will do. Please specify what PAM items are set by the first instance so the admin knows what they will get from pam_authtok_get. I suspect there are two cases here: * PKINIT is not done, or fails; * PKINIT succeeds. 4 I'm still concerned that pam_sm_acct_mgmt() isn't applied when PKINIT is done. Viz with the diff marks removed. Kerberos V5 Account Management Module The Kerberos account management component provides a function to perform account management, pam_sm_acct_mgmt(). This function checks to see if the pam_krb5 authentication module has noted that the user's password has not expired. This does not apply if the module is using PKINIT preauthentication. The following options may be passed in to the Kerberos V5 account management module: Does pam_sm_authenticate() fail? What the outcome of not applying account management? Does it mean accounts cannot be expired if PKINIT is used? 5 I'm still concerned that pam_sm_chauthtok() isn't applied when PKINIT is done. Viz with diff marks removed. Kerberos V5 Password Management Module The Kerberos V5 password management component provides a function to change passwords, pam_sm_chauthtok(), in the Key Distribution Center (KDC) database. This does not apply if the module is using PKINIT preauthentication. The following flags may be passed to pam_sm_chauthtok(3PAM): What does this mean to the example PAM password stack and kpasswd? 6 Nit, this project has a Minor release binding. Therefore it makes no sense to describe things in terms of dtlogin. 7 Has the project team coordianted with SunRay (SRSS) team (as the primary implementor of smartcards)? Has the project team coordinated with the TX team and how this may work/affect the multi-level desktop? Bottom line, IMO, 3, 4 and 5 need to be addressed in the spec. If they have been, please point me to where? I'll "hold my nose[tm]" relative to 1 and 2. Thanks for the extra time, Gary..
[kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009]
> > What is the Release Binding? > > Minor/Patch Which is it Minor or Patch -- they are different see http://sac.eng/BestPractices/release_taxonomy.html and http://sac.eng/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp Patch implies Minor, Minor does not imply Patch. Gary..
[kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009]
> > > I want to see an updated pam_krb5(5) man page explaining how to use > > > PKINIT > > > and including the example PAM stacks for use of PKINIT. I don't seem to find a Release Binding in the case materials. What is the Release Binding? Gary..
[kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009]
> > > I want to see an updated pam_krb5(5) man page explaining how to use > > > PKINIT > > > and including the example PAM stacks for use of PKINIT. If I understand the project correctly: * The project wants to do different prompting than pam_authtok_get(5). * The project proposes to keying off of the contents of PAM_AUTHTOK * The project proposes adding new configuration options. * The project proposes to bypass account management and password change. * The project proposes changes the the PAM stack. I'd like to propose a different tact. This seem to be to suggest a separate PAM service module. Has that been considered? I'd suggest something like pam_pkinit(5) that interacts with the current way the PAM stack is configured for pam_krb5(5). * pam_pkinit would sit on the PAM stacks above pam_authtok_get(5) * If the KDC and krb5.conf(5) are configured for PKINIT and there's no present user (PAM_USER), pam_pkinit:pam_sm_authenticate() prompts for the type of login desired: "Public Key," "Password," ... If it is "Public Key", do the pkinit thing If it is "Password", return PAM_IGNORE. * If the KDC and krb5.conf(5) are configured for PKINIT and there is a present user (PAM_USER), pam_pkinit:pam_sm_authenticate() determines if the user had done the pkinit thing. If yes, do the pkinit thing for reauthentication. If not, return PAM_IGNORE. * If the KDC and krb5.conf(5) are not configured for PKINIT, return PAM_SYSTEM_ERR (or possibly PAM_IGNORE). * for pam_pkinit:pam_sm_setcred(), return PAM_IGNORE. * pass sufficient information in PAM_USER, PAM_AUTHTOK and SUNW-KRB5-AUTH-DATA pam_data for pam_krb5(5) to know what to do. Or add another pam_krb pam_data_item ala KRB5_AUTOMIGRATE_DATA. Note the definition of pam_authtok_get(5) is to only prompt for the user name if PAM_USER is not set an only prompt for an authtok (using PAM_PROMPT) if PAM_AUTHTOK is not set. Why should it be that account management and password change are disallowed? It seems to me that PKINIT would act similarly to password in pam_krb5 that account management could be done. It seems to me that the public key certificate may have expired and the KDC would say so and return PAM_NEW_AUTHTOK_REQD. Similarly it seems to me that even if the user had done a public key login that they may which to update their Kerberos password. To me, a separate module as described seem cleaner and easier to understand and configure than how I understand the current proposal. What have I missed in my understanding (or have I missed so much that it can't even be explained ;-)? Gary..
Open Fabrics User Verbs (OFUV) primary kernel components [PSARC/2009/421 FastTrack timeout 11/13/2009]
> I am the licensee. As a licensee you should know what to do. Contact your mentor and RTM http://sac.eng.sun.com/arc/Processes/ARC-LicenseeDuties.html In general it's automagic it you use the tools. Gary..
Open Fabrics User Verbs (OFUV) primary kernel components [PSARC/2009/421 FastTrack timeout 11/13/2009]
Ted, > Note to PSARC admin folks: I may need manual > intervention to get this into the agenda. > (As far as I can tell, the tools don't support > a fasttrack using an existing case with > one-pager already in place.) Not sure what you're asking. If you have a case that needs an owner and it is a fast track, you need to directly find an owner from the list of available owners (members, intern, licensees). Gary..
Abandon the use of snapshots in mntfs. [PSARC/2009/352 FastTrack timeout 06/19/2009]
Brian, > I little house cleaning. After this case was approved, the project > team decided to take a different approach which was submitted and > approved in PSARC 2009/566. Since the approach in 2009/352 is no > longer valid, I am marking it as withdrawn to avoid future confusion. Wouldn't superceeded be more appropriate? Gary..
[kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009]
> While working out the various permutations of PAM auth stacks I've > discovered that my fasttrack was not complete in regards to new > interfaces. At yesterday's meeting, I asked for more time through today. Unfortuntely, I'm not going to be able to get through this case today. So, I'd like to ask the case be extended to next meeting. A few brief comments that may have already been covered, if so, I apologize. 1st, I think pam_eval() that Nico mentioned could well be a positive alternative -- I know I'm the bottle neck in code review. 2nd, applications can set PAM_AUTHTOK just the same way they can set PAM_USER. So keying off unset PAM_USER/PAM_AUTHTOK may not be as robust as it might have been thought. 3rd, a module could be written and stacked above pam_authtok_get(5) that prompted for what type of authentication was desired and set PAM_PROMPT before returning PAM_IGNORE and falling into pam_authtok_get(5). I'm working to get caught up on this case. I unfortunately missed the pre-review and when I asked where it stood, was told the issues had been resolved. More later, Gary.. P.S.I, too, would really like to see a man page update for pam_krb5(5) as a separate part of the case materials.
EOF of plotting components [PSARC/2009/540 FastTrack timeout 10/21/2009]
> Garrett asked me for codereview, and in looking, I've noticed that xterm > still > supports the crufty old Tek 4014 mode, and one can actually make it work with > graph and plot (at least). So it's *conceivable* that someone is still using > this, although it would have to be nasty moldy old code, I'd think. > > Given that those people can certainly use graph | postplot, we may officially > not care about them. I'm willing to accept that; I just want to make sure > those > with an opinion know that we're removing the bundled stuff that someone might > be > using, because, strictly speaking, it's one of the few workable things we > have > in Solaris at the moment. > > Given the followups for plotutils, I can't imagine this will be any kind of > issue for long, so this is only a nit to make doubly sure the committee > agrees. At today's PSARC meeting Garrett asked for a follow up to this comment. Since graph is not part of the removal, and there appears to be an OpenSolaris follow up. I don't see an issue surrounding cleaning up the 4014 stuff in a Minor release. Gary..
contract for 2008/181 Hotplug Framework to use 2000/517 audit interfaces and 2003/397
I've executed and recorded 2000/517-19 for PSARC/2008/181 Hotplug Framework to use the project private interfaces described in the prototype contract approved in 2003/397. 2003/397 and 2008/181 have a symlink to the executed contract. Gary..
PSARC 2009/538 EOF of Tadpole SPARCLE
> I didn't see any +1s on this, although the case timed out. Can I get a > member to review this? The case states: > Approximately 2.5 years ago, we integrated the basic platmod support > for the Douglas platform (PSARC 2007/152), which is the Tadpole SPARCLE > laptop. These laptops contain an UltraSPARC-IIe or IIi processor from 500 to > 650 MHz. > > Even at that time, the platforms were a bit on the underpowered side. > > This laptop was very briefly marketed by Sun as the Sun Ultra 3, but it > would appear that very few units were sold under this brand. (Those units > shipped with a customized version of Solaris 10, provided by Tadpole.) > Note that the Sun Ultra 3 was also used to cover mobile laptops from > Naturetech, which are not affected by this case. And I'm aware that there is a "Tadpole" based on UltraSPARC IIIi that is still in use in some TX environments. I suspect such use would also carry over to Solaris Next with TX. How does this case affect that "Tadpole"? And if it does, have you checked with the TX folk on how that might affect those customers? Gary..
acpihpd ACPI Hotplug Daemon [PSARC/2009/551 fast-track timeout 10/19/2009]
Mike, > I'm working with Intel to answer your questions. Essentially we want to > provide the least amount of access possible for this daemon to do its > job. IIRC, my initial question had 3 parts: How does the project meet the SMF requirement for authorizations to manage? What is the Method Context used to start the service? The service is to be enabled only on the xxx platform - how is this done? I'd like to clarify the first part about authorizations. When we talked I may not have been complete. If there are no properties that configure the service as in a property group of type application, there is no need for value authorizations to manage them. If the service is never intended to be enabled/disabled by the administrator (but always enabled/started automatically at boot time and never disabled), there is no need for action/value authorizations to manage the service. If both are true and there is no need for defining authorizations for the service, there is no need for a service related Rights Profile. HTH, Gary.. > > For starting the daemon, I'm guessing that we'll have to create > something similar to > usr/src/cmd/svc/profile/platform_SUNW,SPARC-Enterprise.xml > for these x86 machines since we want the service to be enabled by > default on the platforms that support it. Does anyone have any > recommendation about who to talk to about how to get this done? > > Thanks, > > Mike > > On Tue, 2009-10-13 at 13:29 -0700, Gary Winiger wrote: > > > The acpihpd is started and stopped using the standard Solaris service > > > management facility. The acpihpd is an smf service, and will only be > > > enabled on > > > the platforms which supports IOH/CPU/memory hot plug. > > > > How is the SMF usage policy met? > > http://opensolaris.org/os/community/arc/policies/SMF-policy > > Specifically the authorizations, what Rights Profile the authorizations > > will be contained in, method context, ... > > > > How will this be enabled? Is it enabled from platform.xml? > > > > Gary.. > > >
acpihpd ACPI Hotplug Daemon [PSARC/2009/551 fast-track timeout 10/19/2009]
> The acpihpd is started and stopped using the standard Solaris service > management facility. The acpihpd is an smf service, and will only be enabled > on > the platforms which supports IOH/CPU/memory hot plug. How is the SMF usage policy met? http://opensolaris.org/os/community/arc/policies/SMF-policy Specifically the authorizations, what Rights Profile the authorizations will be contained in, method context, ... How will this be enabled? Is it enabled from platform.xml? Gary..
Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009]
> >> This project proposes changing the maximum value for NGROUPS_MAX > >> from 32 to 1024 by changing the definition of NGROUPS_UMAX from 32 > >> to 1024. > > > >> NGROUPS_MAX as defined by different Unix versions are as follows > >> (http://www.j3e.de/ngroups.html): > >> > >>Linux Kernel >= 2.6.3 65536 > > > > Just a note: a (possibly future) change above INT16_MAX > > will require fixing ON audit code that assumes the > > maximum number of groups is a "short" -- this would need > > to be changed to "ushort". > > I found that bit of code; more is needed, specifically adding so much > data to a cred without using it. Probably off topic, so let's take it off line if there's more to discuss. I was referring to au_to_groups() in the kernel and au_to_newgroups() in userland. Gary..
Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009]
> This project proposes changing the maximum value for NGROUPS_MAX > from 32 to 1024 by changing the definition of NGROUPS_UMAX from 32 > to 1024. > NGROUPS_MAX as defined by different Unix versions are as follows > (http://www.j3e.de/ngroups.html): > > Linux Kernel >= 2.6.3 65536 Just a note: a (possibly future) change above INT16_MAX will require fixing ON audit code that assumes the maximum number of groups is a "short" -- this would need to be changed to "ushort". +1 Gary..
Removal of NIS+ [PSARC/2009/530 FastTrack timeout 10/12/2009]
> I'm sponsoring this Fast Track for Raja Gopal Andra, the RPE naming team, > and the NIS+ core team. It requests removal of all the NIS+ related > interfaces and documentation in a Minor Release. While this is somewhat > long, the case owner and project team believe it still qualifies for a > Fast Track as the length details the how the EOL required dependences are > satisfied. This case was approved as specified at today's PSARC meeting. Gary..
Removal of NIS+ [PSARC/2009/530 FastTrack timeout 10/12/2009]
I'm sponsoring this Fast Track for Raja Gopal Andra, the RPE naming team,
and the NIS+ core team. It requests removal of all the NIS+ related
interfaces and documentation in a Minor Release. While this is somewhat
long, the case owner and project team believe it still qualifies for a
Fast Track as the length details the how the EOL required dependences are
satisfied.
This project is unrelated to pam_ldap(5) and has no effect on it or
the Sun Java System Directory Server.
The current NIS+(1) man page and redacted opinions for PSARC/2000/370 (EOL of
NIS+) and PSARC/2004/638 (Removal of Sun Directory Server 5.1 from Solaris WOS)
are in the case directory.
The timer is set for 12 Oct., 2009.
Gary..
~~~
Background:
==
NIS+(1) seems to have been introduced prior to the recording of PSARC cases
in 1991. The first references I've found are Vikul Khosla's nisaddcred flag
(PSARC/1992/187) and Chuck McManis' NIS+ diagnostics (PSARC/1992/188) cases.
They refer to NIS+, but not to any previous cases, though ZNS demos
(PSARC/1991/023) seems somehow related. The NIS+ promise never achieved
sufficient traction to supplant NIS (nee YP). X500 directory servers and
the Lightweight Directory Access Protocol (LDAP) have supplanted the promise
of NIS+. EOL of NIS+ (PSARC/2000/370) started the process leading to this
case.
Dependences:
===
o PSARC/2000/370 (EOL of NIS+) opinion states:
2. Decision & Precedence Information
. . .
Note: the approval of this case does not authorize the
actual removal of NIS+ support from Solaris. That removal
will need to be the subject of another case. That case will
depend on at least:
PSARC/2000/311 NIS+/LDAP Migration
PSARC/2000/363 Native LDAP phase II
LSARC/2001/101 Bundling of LDAP Directory Server
{actually PSARC/2001/101 -gww}
4. Opinion
The main issue raised for this case was that of providing
adequate notice and support to existing NIS+ users. The
requirement to announce the upcoming EOL of NIS+ as soon as
possible in order to head off new adoption of the technology
was seen as conflicting with the requirement not to panic
existing users.
The committee decided that a three step schedule:
1. adequate notice
2. availability of all replacement technology
3. actual EOL
would satisfy both requirements and imposed technical
changes needed to obtain such a schedule. See [2] for
opposing views.
{[2] Email discussion. File: mail}
o PSARC/2004/638 (Removal of Sun Directory Server 5.1 from Solaris WOS) was
denied. The denial was overturned on appeal and iDS was removed from
the Solaris WOS. That removal impacts the removal of NIS+ as the
opinion states:
4.10. Potential Impact on NIS+ Removal
PSARC/2000/370 "EOL of NIS+" states:
"Note: the approval of this case {PSARC/2000/370} does
not authorize the actual removal of NIS+ support from
Solaris. That removal will need to be the subject of
another case. That case will depend on at least:
PSARC/2000/311 NIS+/LDAP Migration
PSARC/2000/363 Native LDAP phase II
PSARC/2001/101 Bundling of LDAP Directory Server"
Without a bundled LDAP directory server, the preconditions
for the removal of NIS+ from Solaris are not met and NIS+
may not be removed from Solaris based on the approved archi-
tectural decisions.
Details:
===
* PSARC/2000/311 NIS+/LDAP Migration and PSARC/2000/363 Native LDAP
phase II have both been delivered since Solaris 9.
* 1) adequate notice
The announcement of the EOL of NIS+ has been completed since Solaris 9
The current (S10u8) NIS+ man pages contain the note:
NIS+ might not be supported in future releases of the
Solaris operating system. Tools to aid the migration from
NIS+ to LDAP are available in the current Solaris release.
Formoreinformation,visit
http://www.sun.com/directory/nisplus/transition.html.
* 2) availability of all replacement technology
With the integration of PSARC/2008/745 nss_ldap shadowAccount support
in the current development release and the back port to S10u8,
all the functionality that was provided by NIS+ is now available
using a LDAP directory server as a name service (i.e., nsswitch.conf
configuration such as shown in the delivered sample nsswitch.ldap).
* With the permission to remove the bundled LDAP Directory Server by
the approval upon appeal of
CUPS as the default print service [PSARC/2009/514 FastTrack timeout 10/02/2009]
> >> 2) Are there any plans to enhance CUPS to distributed network printer > >> configuration via NIS? Or is there a replacement for this service > >> already present? (I guess this is what Bonjour is intended for?) > > There are no plans for NIS. CUPS supports LDAP, DNS-SD, SLP, and CUPS > > Browse protocols for print queue advertisement/discovery. Since CUPS > > is the "de facto" standard print service on *nix these days, it's > > interoperable with other systems. Our name service support support > > isn't. > > So one thing I'd like to see here, in order to eventually remove the LP > service altogether, is a set of tools or documents to help > administrators migrate from using NIS to other protocols. Is something more than PSARC/2001/282 NIS to LDAP Transition Project (N2L) being requested? Gary..
contract for 2008/725 TMP Support to use 2000/517 audit interfaces and 2003/397
I've executed and recorded 2000/517-18 for PSARC/2008/725 TPM Support to use the project private interfaces described in the prototype contract approved in 2003/397. 2003/397 and 2008/725 have a symlink to the executed contract. Gary..
Label Builder CLI [LSARC/2009/457 FastTrack timeout 08/31/2009]
> With Gary's issues clarified can someone +1 this project? My last comment was really just a nit, so +1. Gary..
Label Builder CLI [LSARC/2009/457 FastTrack timeout 08/31/2009]
> >>> ATTRIBUTES > >>> See attributes(5) for description of the following attributes: > >>> _ > >>> | ATTRIBUTE TYPE | ATTRIBUTE VALUE | > >>> |_|_ ___| > >>> | Availability| SUNWtgnome-tsol-libs| > >>> |_|_| > >>> | Interface stability | Uncommitted | > >>> |_|_| > >> > >> The output from the command should probably be "Not An Interface" > > Calling scripts will rely on both the printed string for the selected > label and the exit status so this very much needs to be an interface. Maybe I'm still confused. I agree that exit status can be "stable". The string spit out by label_to_str(3) is not "stable". It is controlled by the sites label_encodings(4). Gary..
Label Builder CLI [LSARC/2009/457 FastTrack timeout 08/31/2009]
> I have placed the attached man page document in the case directory under > the materials subdirectory. For the record from a private thread with the project team: My primary comment on the man page and case all together is that it's unclear what the output of call to the CLI is. Is it a single label, a dimming list (from the contracted project private interfaces), a construction of all labels between min and max, in which case what does the default have to do with it. Also the man page doesn't say what context (global zone, sys_trans_label, ...) is needed? > txselectlabel - label selection dialog utility It's unclear to me how this utility presents a dialogue with the user. > EXIT STATUS > The following exit values are returned: > > 0 A label was successfully selected > > 1 Missing or ivalid command argument(s) > > 2 A label translation error occured Is there something more here? str_to_label gives a pointer to what part of the string was in error. Is something spit out to stderr? > 5 Dialog was canceled without selecting a label It's unclear what dialogue is taking place. More information would be useful. > > FILES > The following files are used by this utility: > > /usr/bin/txselectlabel The command-line executable > > ATTRIBUTES > See attributes(5) for description of the following attributes: > _ > | ATTRIBUTE TYPE | ATTRIBUTE VALUE | > |_|_ ___| > | Availability| SUNWtgnome-tsol-libs| > |_|_| > | Interface stability | Uncommitted | > |_|_| The output from the command should probably be "Not An Interface" Gary..
daemon() in libc [PSARC/2009/444 FastTrack timeout 08/24/2009]
> Here's updated man page with new COMMENTS section giving high level > overview of the options for daemon environment setup. > > If there is a need for more specific references (to actual functions > like priv_set(3C) and such) I can add them. Probably not, but please add privileges(5) to the SEE ALSO. Gary..
Anti-spoofing Link Protection [PSARC/2009/436]
> gw-1 What's the administrative interface? dladm? What's the policy for setting these properties? Eric and I were going to resolve any issues with the policy for these properties offline. Since the meeting I've done the research I hadn't gotten to. dladm is contained in the Network Management Rights Profile with appropriate privilege to make they necessary system calls. Gary..
PSARC 2008/181 Solaris Hotplug Framework
> I've updated the case directory in the commitment3.materials directory > with updated materials. No such file or directory. /net/sac.sfbay/export/sac/Archives/CaseLog/arc/PSARC/2008/181 marduk.eng-gww[200]: l 20080306_govinda.tatti@commitment2.materials/ 20090617.2008.181.inception@ inception.materials/ 20090617.2008.181.inception.mp3@ issues 20090722.2008.181.commitment@ issues.broken 20090722.2008.181.commitment.mp3@ mail IAM.Solaris_Hotplug_Framework sc/ SCCS/ uirb/ commitment.materials/
daemon() in libc [PSARC/2009/444 FastTrack timeout 08/24/2009]
> DESCRIPTION > If the nochdir option is other than zero the working directory will > not be changed to the root directory, otherwise it will be. Is this / or ~root? > RETURN VALUES > Upon successful completion, daemon() returns 0. Otherwise it returns -1. What are the failure modes? Is errno set? Clarifications in the man page would be helpful. Gary..
adt_alloc_event update [PSARC/2009/400 Self Review]
I'm self sponsoring this case. I believe it qualifies for self-review and am marking it "closed approved automatic." I am happy to turn it into a fast track and set the timer if anyone believes I've misjudged. The case requests a Patch Release Binding and an unchanged Contracted Project Private Interface Taxonomy. The project team has no current plan to backport. No current uses of adt_alloc_event() are affected by this change. A full diffmarked man page is in the case directory. Gary.. ~~~ Background: == PSARC/2000/517 "Thread-safe audit API" introduced a number of user land (Contracted) Project Private interfaces for generating Solaris Audit records. PSARC/2003/397 "Contracted audit interfaces for open source" further discussed the Contracts for those interfaces. The interfaces can be used without checking whether Solaris Audit is enable or that the audit service, auditd(1m) is active. In looking over the code, I noticed that adt_alloc_event() should be able to return an error for invalid parameters. Doing so has the potential to save applications from a segment fault. adt_event_data_t *adt_alloc_event(const adt_session_data_t *session_data, au_event_t event_id); returns an event structure to be filled in by the application based on the event (event_id) passed to it. Even if audit is off, it always returns the structure. If for some reason the event_id passed in isn't valid, adt_alloc_event will presently return a adt_event_data_t pointer (adt_event_data_t is a union of the defined events). This could lead the application to try to fill in memory outside of the memory allocated. While this should never happen because the use is contracted, thus the application and structure should always be in sync, it is easy to return an error if it does occur. Proposal: = Add EINVAL to the returns for adt_alloc_event. adt_alloc_event(3adt) DESCRIPTION This set of three functions are used to generate audit records within the current audit session context defined by the session_data parameter to adt_alloc_event(). See the union adt_event_data definition in adt_event.h for the name of the structure that corresponds to the event_id. For example, event_id ADT_login structure name is adt_login_t. adt_alloc_event() returns a pointer to memory allocated for an event of type event_id. This structure is to be filled in by the caller to provide the user-specific data contained in the audit record. The allocated memory structure includes linkage to the audit session handle. It is the responsibility of the caller to free the event memory by calling adt_free_event() when it is no longer needed. RETURN VALUES adt_alloc_event(): != NULL OK == NULL error; errno is set to one of the following: + EINVAL -- invalid event_id value ENOMEM unable to allocate memory
Redux: PSARC/2009/348 Security Labels for ZFS
> > issues in summary. An updated spec will follow the convergence of the case. > > This case was approved at today's PSARC meeting. An updated > spec will be delivered to the case tomorrow when I get the > wording straight for making mlslabel undelegatable. Below and in the case (spec.txt) please find the updated spec. Tim and zfs team, if the wording around delegation is inaccurate, please let me and the project team know and suggest some proper wording so it is clear to all. spec.old and zfs.1m.old are the previous verions (also under SCCS). Thanks, Gary.. ~~~ I'm sponsoring this Fast Track for Ric Aleshire and the Trusted Extensions development team. Trusted Extensions was introduced in PSARC/2002/762 Layered Trusted Solaris with filesystem interfaces defined in the subcase PSARC/2005/723 Solaris Trusted Extensions Filesystem Labeling One of the goals of Trusted Extensions was to make no modifications to the on disk filesystem structures. This was different than the releases of Trusted Solaris (1.0-2.5.1, 7, 8). In those systems on disk filesystem changes were made in order to support labels. That made those filesystems incompatible with the unlabeled forms. With the advent of PSARC/2002/240 ZFS (Zettabyte Filesystem) some amount of labeling can be introduced in a fully compatible way. This case requests a Committed Interface Taxonomy, and a Patch Release Binding with a dependency on PSARC/2002/240. A full diffmarked zfs(1m) man page is in the case directory. The timer is set for 17 June, 2009. Gary.. ~~~ Background: == The Trusted Extensions feature of Solaris provides sensitivity labels, and mediates data access accordingly. These labels are associated with zones; each zone on a system is configured to have a unique label. Labels are not stored with the filesystem but are inferred based on the containing zone. Mount-time policy controls access to filesystems and the objects they contain. Problem: === Based on customer requests for Trusted Extensions and possible future Common Criteria Evaluation criteria, there are requirements to be able to store labels with corresponding data. In Trusted Extensions, a ZFS dataset currently has only an implied label, based on where it is mounted (i.e., in which zone). To prevent administrators or users from accidentally mounting datasets in ways that would mislabel information, that information should be recorded as a persistent ZFS attribute. Labeled ZFS filesystems will also improve the security of removable devices (such as USB media) in Trusted environments. Proposal: ZFS filesystem mechanisms make it possible to support labels as attributes of the data. To protect these labels from user manipulation, they will be system attributes as defined by ZFS, and will be supported by kernel policy to maintain the label and control access to the corresponding data. ZFS kernel mount logic will access the label attribute and perform a check for label dominance, similar to the policy found in lofs and nfs mount code. Labeling of previously unlabeled ZFS file systems will generally be automatic and not require administrative action. Details: === A new system property called "mlslabel" is defined. Its value on disk is a string which represents the internally encoded label of the dataset. (E.g., "0x0002-08-08", which corresponds to the "public" label.) mlslabel is an inheritable property; when not present, it defaults to the string "none" to indicate no label is present. The mlslabel property follows the same rules as the other inheritable properties. When Trusted Extensions is enabled, mount-time checks will verify that the dataset label matches the label of the zone that the dataset is mounted into. If the labels do not match, the mount syscall fails with an EACCES error. The mlslabel property may be set from the command line using the zfs command, for example: zfs set mlslabel=public export/something Setting the mlslabel property can only be done when Trusted Extensions is enabled. The file_upgrade_sl privilege is required when setting an initial label, or changing a non-default label to a higher level label. The file_downgrade_sl privilege is required when removing a label (setting it to "none") or when changing a non-default label to a lower level label. Unlike other properties, the mlslabel property is a Mandatory
Redux: PSARC/2009/348 Security Labels for ZFS
> issues in summary. An updated spec will follow the convergence of the case. This case was approved at today's PSARC meeting. An updated spec will be delivered to the case tomorrow when I get the wording straight for making mlslabel undelegatable. Gary..
Redux: PSARC/2009/348 Security Labels for ZFS
> From gww at eng.sun.com Tue Jun 9 18:02:31 2009 > Date: Tue, 09 Jun 2009 18:02:13 -0700 (PDT) > From: Gary Winiger > Subject: Redux: PSARC/2009/348 Security Labels for ZFS > To: PSARC-ext at sun.com > Cc: rampart-dev-team at sun.com, ric.aleshire at sun.com > Content-transfer-encoding: 7BIT > X-PMX-Version: 5.4.1.325704 > > AAR, Fat fingered the case number when cleaning up the To and Cc lists. > Please reply to this mail. > > Gary.. > == > I'm sponsoring this Fast Track for Ric Aleshire and the Trusted Extensions > development team. > > Trusted Extensions was introduced in PSARC/2002/762 Layered Trusted > Solaris with filesystem interfaces defined in the subcase > PSARC/2005/723 Solaris Trusted Extensions Filesystem Labeling > > One of the goals of Trusted Extensions was to make no modifications to > the on disk filesystem structures. This was different than the releases > of Trusted Solaris (1.0-2.5.1, 7, 8). In those systems on disk filesystem > changes were made in order to support labels. That made those filesystems > incompatible with the unlabeled forms. With the advent of > PSARC/2002/240 ZFS (Zettabyte Filesystem) and its property structure defined > by PSARC/2007/315 Extensible Attribute Interfaces, some amount of labeling > can be introduced in a fully compatible way. > > This case requests a Committed Interface Taxonomy, and a Patch Release > Binding with a dependency on PSARC/2002/240 and PSARC/2007/315. > > A full diffmarked zfs(1m) man page is in the case directory. > > The timer is set for 17 June, 2009. > > Gary.. > ~~~ > Background: > == > The Trusted Extensions feature of Solaris provides sensitivity > labels, and mediates data access accordingly. These labels are > associated with zones; each zone on a system is configured to > have a unique label. Labels are not stored with the filesystem > but are inferred based on the containing zone. Mount-time > policy controls access to filesystems and the objects they > contain. > > Problem: > === > Based on customer requests for Trusted Extensions and possible > future Common Criteria Evaluation criteria, there are > requirements to be able to store labels with corresponding > data. In Trusted Extensions, a ZFS dataset currently has only > an implied label, based on where it is mounted (i.e., in which > zone). To prevent administrators or users from accidentally > mounting datasets in ways that would mislabel information, that > information should be recorded as a persistent ZFS attribute. > Labeled ZFS filesystems will also improve the security of > removable devices (such as USB media) in Trusted environments. > > Proposal: > > ZFS filesystem mechanisms make it possible to support labels as > attributes of the data. To protect these labels from user > manipulation, they will be system attributes as defined by ZFS, > and will be supported by kernel policy to maintain the label > and control access to the corresponding data. > > ZFS kernel mount logic will access the label attribute and > perform a check for label dominance, similar to the policy > found in lofs and nfs mount code. Labeling of previously > unlabeled ZFS file systems will generally be automatic and > not require administrative action. > > Details: > === > A new system property called "slabel" is defined. Its value is a > string which represents the internally encoded label of the > dataset. (E.g., "0x0002-08-08", which corresponds to the > "public" label.) slabel is an inheritable property; when not > present, it defaults to the string "none" to indicate no label > is present. The slabel property follows the same rules as the > other inheritable properties. > > When Trusted Extensions is enabled, mount-time checks will > verify that the dataset label matches the label of the zone > that the dataset is mounted into. If the labels do not match, > the mount syscall fails with an EACCES error. > > The slabel property may be set from the command line using the > zfs command, for example: > zfs set slabel=0x0002-08-08 export/something > > Setting the slabel property can only be done when Trusted > Extensions is enabled. The file_upgrade_sl privilege is required >
Redux: PSARC/2009/348 Security Labels for ZFS
> OK then ;-) I'll be posting a summary of the issues discussed > and responses shortly so we're all on the same page. During this case discussion a few points were raised. In order to work towards convergence of the case the project team would like to respond to those issues in summary. An updated spec will follow the convergence of the case. Gary.. == * PSARC/2007/315 Extensible Attribute Interfaces was referenced as a dependency. The ZFS project team pointed out this was not a relevant reference and that PSARC/2002/240 ZFS (Zettabyte Filesystem) was the only case dependency required. References to PSARC/2007/315 have been removed. * What is the inheritance characteristic of the slabel property? The slabel property is inherited just the same as the other data set properties. Modifying the slabel's value requires the specified privilege. * How does zfs send deal with the slabel property? send (and receive) preserve the slabel property. Making the received data set available (mount) is restricted as specified in the case materials mount policy. * How is the slabel property related to delegation (zfs allow)? Delegation deals with owner rights (Discretionary Policy as in Discretionary Access Control, DAC), slabel is a Mandatory Policy attribute. It deals with label based Mandatory Access Control, MAC, thus unlike other zfs properties, additional policy applies to the slabel property. In addition to having DAC rights to modify the slabel property, the specified policy (privileges, or setting to the label of the zone in which it is mounted Read/Write) is required. * Why have all three none/admin_low/admin_high; what is the relationship between them? The intent of this case is to prevent inadvertent access to labeled data. The default slabel value (including when not present), none, implies the data has not been labeled, thus default access is allowed. admin_low and admin_high are "administrative" labels associated with system, rather than user, data. They are only set explicitly by Trusted Extensions administrators to indicate how they wish system data to be protected. As opposed to other labels in a Trusted Extensions configuration, they are not automatically set when mounted. Trusted Extensions administrators have to explicitly specify how they want system data protected. When mounted in the global zone, admin_low data sets must not have the existing zoned property set and must be mounted read only. labeled-(non-global)-zone admin_low data sets must be mounted read only. admin_high labeled data sets, must not have the zoned property set and may only be mounted in the global zone. This allows the Trusted Extensions administrator to ensure that such labeled data sets will not be unintentionally mounted in ways that could cause inadvertent data access or modification. * Why must zfs set slabel= and zfs get slabel only deal with internally formatted labels? There is no reason. The case will be updated to allow human readable as well as internally formatted labels. Internally formatted labels will be stored as the string value of the slabel property. The zfs command will do the translation using the standard Trusted Extensions interfaces which take into account the calling user's rights to view/set human readable label strings. * What is the interaction between the zfs crypto project and this case? The on disk format of the slabel string is public information (unclassified) and requires no protection.
Redux: PSARC/2009/348 Security Labels for ZFS
> > That's why the internal format (aka hex label) is what is stored. > > By official government ruling (at least from us DoD) it is > > unclassified and may be view by anyone. > > Does that then mean we can't allow for 'zfs get slabel' to return the > label_to_str() version ? I could live with that providing we can > provide the 'zfs set slabel=public' rather than needing to use the > internal format to do zfs set. Fortunately, no. Explicitly the translation would be label_to_str(str_to_label(zfs get slabel), M_LABEL) As I tried to say (below) takes into account the restrictions (that is the caller must dominate the label being translated or the translation will fail). This has been the case since SunOS CMW 1.0. > > Indeed the compartment > > names are generally classified at the level of their name and > > must not be visible below that level. label_to_str takes into > > account these restrictions as well as produces the unclass version > > of an m_label for storage where it doesn't need protection. > > If the US DoD is happy with the internal format being treated as > unclassified then I'm fine with using a property for this providing the > issue of delegation is okay with the project team - ie it must follow > the normal delegation rules for properties - I would like to see > positive confirmation from the ZFS core team that they are comfortable > with this given the additional information provided. OK then ;-) I'll be posting a summary of the issues discussed and responses shortly so we're all on the same page. Gary..
Redux: PSARC/2009/348 Security Labels for ZFS
> > Well, they are static, no? > > Static to a given site. The issue is that the labels themselves are > classified information for some customers - usually only the compartment > bits - and as such it would be better if we could encrypt them so that > the handling of disks that contain labels could be reduced. That's why the internal format (aka hex label) is what is stored. By official government ruling (at least from us DoD) it is unclassified and may be view by anyone. Indeed the compartment names are generally classified at the level of their name and must not be visible below that level. label_to_str takes into account these restrictions as well as produces the unclass version of an m_label for storage where it doesn't need protection. Gary..
Redux: PSARC/2009/348 Security Labels for ZFS
> > + slabel= > > + This property is used with Trusted Extensions. This is > > + the internal encoding of a sensitivity label (also called > > + a hex label). (See label_to_str(3tsol), label_encodings(4), > > + hextoalabel(1M), atohexlabel(1M).) At mount time, this label > > + must match that of the zone where the dataset is being mounted, > > + or the mount fails. > > > I'm happy with everything in this case except that the user interface to > setting the property requires the use of an internally encoded label, > I'm happy with allowing it. This seems really unfortunate that we can't > just do: > > zfs set slabel=public tank/foo Gosh I overlooked that in ensuring what was on disk was an internally formatted label string. Indeed I agree, there should be no reason to require the admin to enter a atohexlabel, or for the system to display an internally formatted label. The point is to not have the kernel have to deal with translating human readable labels, likely before the label service is up. I'll ask the project team about this all later today when I meet with them. Gary..
Subject: PSARC/2009/354 Always on / no reboot Solaris Audit
I'm sponsoring this case for Marek Pospisil and the Solaris Audit project team. It requests a Minor Release Binding and an unchanged interface taxonomy. I believe it qualifies for self-review and have marked it "closed approved automatic." I'm happy to turn it into a fast track and set a timer if anyone believes I've misjudged. Full diffmarked man pages are in the case directory. Gary.. ~~~ Background: == Historically, Solaris Auditing required the administrator to run the now obsolete bsmconv(1m) command, configure auditing and REBOOT. To disable auditing the administrator had to run the now obsolete bsmunconv(1m) command and REBOOT. Customer feedback from most enterprise shops has consistently been that rebooting has been an impedement to their use of Solaris Auditing. See also, RFE 6192139 Solaris auditing should always be enabled bsmconv has contained two functions. One was to modify system(4) to load the Solaris Audit kernel module (set c2audit:audit_load = 1), thus requiring the reboot, and enable the audit service. The other was to configure device allocation, allocate(1). In preparation for this case and one that rearchitects device allocation to be always available, PSARC/2008/787 Obsolete of some Solaris Audit commands, obsoleted bsmconv/bsmunconv. A future case when device allocation no longer requires running bsmconv/bsmunconv will request their removal. With the integration of this case, bsmconv/bsmunconv will still enable/disable the audit service and configure/disable device allocation. If desired, it remains possible to modify system(4) to cause the audit module not to be loaded (exclude c2audit). Proposal: No longer require the modification of system(4) and the implied reboot. Solaris Auditing will always be available to be configured and then enabled either by bsmconv(1m) if device allocation is also desired or by audit(1m) -s. Solaris Auditing can similarly be disabled by running bsmunconv(1m) or by audit(1m) -t. While audit -s/-t is the preferred, documented, and historic interface for enabling(or refreshing)/disabling the audit daemon (from pre-smf days through this case), svcadm enable/refresh/disable svc:/system/auditd will work as well. The audit(1m), auditd(1m) and bsmconv/bsmunconv(1m) man pages are updated: audit(1m): == OPTIONS -n Notify the audit daemon to close the current audit file and open a new audit file in the current audit directory. -s Notify the audit daemon to read the audit control file. The audit daemon stores the information internally. If the audit daemon is not running, - but audit has been enabled by means of - bsmconv(1M), the audit daemon is started. + enable (start) the audit daemon. -t Direct the audit daemon to close the current - audit trail file, disable auditing, and die. Use + audit trail file and disable (stop) the audit daemon. Use -s to restart auditing. -v pathVerify the syntax for the audit control file stored in path. The audit command displays an approval message or outputs specific error mes- sages for each error found. NOTES -The functionality described in this man page is available -only if the Solaris Auditing feature has been enabled. See -bsmconv(1M) for more information. For the -s option, audit validates the audit_control syntax and displays an error message if a syntax error is found. If a syntax error message is displayed, the audit daemon does not re-read audit_control. Because audit_control is pro- -cessed at boot time, the -v option is provided to allow syn- +cessed at the time the audit deamon is enabled, the -v +option is provided to allow syn- tax checking of an edited copy of audit_control. Using -v, audit exits with 0 if the syntax is correct; otherwise, it returns a positive integer. auditd(1m): == DESCRIPTION audit(1M) is used to control auditd. It can cause auditd to: +oto enable auditd if not enabled; oclose the current audit file and open a new one; oclose thecurrentauditfile,re-read /etc/security/audit_control and open a new audit file; oclose the audit trail and terminate auditing. NOTES -The functionality described in this man page is available -only if the Solaris Auditing feature has been enabled. See -bsmconv(1M) for more information. -auditd is loaded in the global zone at boot time if auditing -is enabled. See bsmconv(1M). bsmconv/bsmunconv(1m): == ATTRIBUTES _
Redux: PSARC/2009/348 Security Labels for ZFS
Tim, Thanks for adding zfs-team. > PSARC 2007/315 defines extensible system attributes, which are a file-level > mechanism. What you are describing is a new dataset-level property. So I > don't see a need to tie this new case with 2007/315. I didn't recall system attributes being part of the original ZFS case. Do you have a case pointer for dataset-level system properties? Or are you saying that there are no dataset level system properties? I'm pretty sure the project team believes there are. > By default a child dataset inherits property values from its parent. There > are > exceptions to this, and if this is one of those, that should be noted. Also, > will you allow a label to be inherited from a parent dataset via 'zfs > inherit'? > > Does this property need to remain with the dataset if the dataset is streamed > somewhere via 'zfs send'? That will affect the implementation. > > Will you allow label setting to be delegated (i.e, 'zfs allow')? All other > properties support this. I'll let the project reply to this part. I'd appreciate a proper case reference for dataset system properties. Thanks, Gary..
Redux: PSARC/2009/348 Security Labels for ZFS
AAR, Fat fingered the case number when cleaning up the To and Cc lists.
Please reply to this mail.
Gary..
==
I'm sponsoring this Fast Track for Ric Aleshire and the Trusted Extensions
development team.
Trusted Extensions was introduced in PSARC/2002/762 Layered Trusted
Solaris with filesystem interfaces defined in the subcase
PSARC/2005/723 Solaris Trusted Extensions Filesystem Labeling
One of the goals of Trusted Extensions was to make no modifications to
the on disk filesystem structures. This was different than the releases
of Trusted Solaris (1.0-2.5.1, 7, 8). In those systems on disk filesystem
changes were made in order to support labels. That made those filesystems
incompatible with the unlabeled forms. With the advent of
PSARC/2002/240 ZFS (Zettabyte Filesystem) and its property structure defined
by PSARC/2007/315 Extensible Attribute Interfaces, some amount of labeling
can be introduced in a fully compatible way.
This case requests a Committed Interface Taxonomy, and a Patch Release
Binding with a dependency on PSARC/2002/240 and PSARC/2007/315.
A full diffmarked zfs(1m) man page is in the case directory.
The timer is set for 17 June, 2009.
Gary..
~~~
Background:
==
The Trusted Extensions feature of Solaris provides sensitivity
labels, and mediates data access accordingly. These labels are
associated with zones; each zone on a system is configured to
have a unique label. Labels are not stored with the filesystem
but are inferred based on the containing zone. Mount-time
policy controls access to filesystems and the objects they
contain.
Problem:
===
Based on customer requests for Trusted Extensions and possible
future Common Criteria Evaluation criteria, there are
requirements to be able to store labels with corresponding
data. In Trusted Extensions, a ZFS dataset currently has only
an implied label, based on where it is mounted (i.e., in which
zone). To prevent administrators or users from accidentally
mounting datasets in ways that would mislabel information, that
information should be recorded as a persistent ZFS attribute.
Labeled ZFS filesystems will also improve the security of
removable devices (such as USB media) in Trusted environments.
Proposal:
ZFS filesystem mechanisms make it possible to support labels as
attributes of the data. To protect these labels from user
manipulation, they will be system attributes as defined by ZFS,
and will be supported by kernel policy to maintain the label
and control access to the corresponding data.
ZFS kernel mount logic will access the label attribute and
perform a check for label dominance, similar to the policy
found in lofs and nfs mount code. Labeling of previously
unlabeled ZFS file systems will generally be automatic and
not require administrative action.
Details:
===
A new system property called "slabel" is defined. Its value is a
string which represents the internally encoded label of the
dataset. (E.g., "0x0002-08-08", which corresponds to the
"public" label.) slabel is an inheritable property; when not
present, it defaults to the string "none" to indicate no label
is present. The slabel property follows the same rules as the
other inheritable properties.
When Trusted Extensions is enabled, mount-time checks will
verify that the dataset label matches the label of the zone
that the dataset is mounted into. If the labels do not match,
the mount syscall fails with an EACCES error.
The slabel property may be set from the command line using the
zfs command, for example:
zfs set slabel=0x0002-08-08 export/something
Setting the slabel property can only be done when Trusted
Extensions is enabled. The file_upgrade_sl privilege is required
when setting an initial label, or changing a non-default label
to a higher level label. The file_downgrade_sl privilege is
required when removing a label (setting it to "none") or when
changing a non-default label to a lower level label.
In addition to manually setting dataset labels, the system will
appropriately initialize the label attribute automatically. At
mount time, if the dataset has no slabel property or only the
default one ("none"), the slabel property will be set during
the mount.
Changing the label on a dataset (i.e. setting the slabel
property, when a non-default slabel value already exists), is
only allowed when the dataset is not mounted. Setting an
initial slabel is permitted regardless of whether the dataset
PSARC/2009/349 Security Labels for ZFS
I'm sponsoring this Fast Track for Ric Aleshire and the Trusted Extensions
development team.
Trusted Extensions was introduced in PSARC/2002/762 Layered Trusted
Solaris with filesystem interfaces defined in the subcase
PSARC/2005/723 Solaris Trusted Extensions Filesystem Labeling
One of the goals of Trusted Extensions was to make no modifications to
the on disk filesystem structures. This was different than the releases
of Trusted Solaris (1.0-2.5.1, 7, 8). In those systems on disk filesystem
changes were made in order to support labels. That made those filesystems
incompatible with the unlabeled forms. With the advent of
PSARC/2002/240 ZFS (Zettabyte Filesystem) and its property structure defined
by PSARC/2007/315 Extensible Attribute Interfaces, some amount of labeling
can be introduced in a fully compatible way.
This case requests a Committed Interface Taxonomy, and a Patch Release
Binding with a dependency on PSARC/2002/240 and PSARC/2007/315.
A full diffmarked zfs(1m) man page is in the case directory.
The timer is set for 17 June, 2009.
Gary..
~~~
Background:
==
The Trusted Extensions feature of Solaris provides sensitivity
labels, and mediates data access accordingly. These labels are
associated with zones; each zone on a system is configured to
have a unique label. Labels are not stored with the filesystem
but are inferred based on the containing zone. Mount-time
policy controls access to filesystems and the objects they
contain.
Problem:
===
Based on customer requests for Trusted Extensions and possible
future Common Criteria Evaluation criteria, there are
requirements to be able to store labels with corresponding
data. In Trusted Extensions, a ZFS dataset currently has only
an implied label, based on where it is mounted (i.e., in which
zone). To prevent administrators or users from accidentally
mounting datasets in ways that would mislabel information, that
information should be recorded as a persistent ZFS attribute.
Labeled ZFS filesystems will also improve the security of
removable devices (such as USB media) in Trusted environments.
Proposal:
ZFS filesystem mechanisms make it possible to support labels as
attributes of the data. To protect these labels from user
manipulation, they will be system attributes as defined by ZFS,
and will be supported by kernel policy to maintain the label
and control access to the corresponding data.
ZFS kernel mount logic will access the label attribute and
perform a check for label dominance, similar to the policy
found in lofs and nfs mount code. Labeling of previously
unlabeled ZFS file systems will generally be automatic and
not require administrative action.
Details:
===
A new system property called "slabel" is defined. Its value is a
string which represents the internally encoded label of the
dataset. (E.g., "0x0002-08-08", which corresponds to the
"public" label.) slabel is an inheritable property; when not
present, it defaults to the string "none" to indicate no label
is present. The slabel property follows the same rules as the
other inheritable properties.
When Trusted Extensions is enabled, mount-time checks will
verify that the dataset label matches the label of the zone
that the dataset is mounted into. If the labels do not match,
the mount syscall fails with an EACCES error.
The slabel property may be set from the command line using the
zfs command, for example:
zfs set slabel=0x0002-08-08 export/something
Setting the slabel property can only be done when Trusted
Extensions is enabled. The file_upgrade_sl privilege is required
when setting an initial label, or changing a non-default label
to a higher level label. The file_downgrade_sl privilege is
required when removing a label (setting it to "none") or when
changing a non-default label to a lower level label.
In addition to manually setting dataset labels, the system will
appropriately initialize the label attribute automatically. At
mount time, if the dataset has no slabel property or only the
default one ("none"), the slabel property will be set during
the mount.
Changing the label on a dataset (i.e. setting the slabel
property, when a non-default slabel value already exists), is
only allowed when the dataset is not mounted. Setting an
initial slabel is permitted regardless of whether the dataset
is mounted or not.
In a labeled zone the only value which can be set for the
slabel property of
Update: PSARC/2009/208 - sending audit log to a remote system.
During the implementation and code review phase of PSARC/2009/208, a few changes to the protocol seemed to be advisable to make before audit_remote(5) was integrated. The version number remains unchanged. Only GSS-API functionality is supported at this time. Additionally, IANA granted the "solaris-audit" service port 16162/tcp. /etc/services will be updated with this integration. IANA will be sent the updated protocol specification. I've diff marked and updated audit_remote(5) man page and put it in the case directory. If anyone believes it's necessary to reopen the case, I'll do so and set a new timer. Gary.. ~~ Summary of protocol changes: 1) The protocol version handshake has been changed and moved from within the GSS context to precede GSS context establishment. This change is to allow other forms of OTW protection such as TLS, or even none as might be the case for IPsec protected peers. 2) As part of the GSS security context negotiation, input channel bindings is used to authenticate the version hand shake. 3) An "audit record" sequence number has been added to the sent audit records. That sequence number needs to be returned as part of the message retrieval acknowledgement. This greatly improves the efficiency of audit_remote's receiving thread in verification of the peer's receipt of audit records. Summary of non-protocol changes: 1) The default timeout has been reduced from 60 seconds to 5 (and the retry algorithm is a semi-exponential backoff) The default number of retries remains 3. 2) The use of TCP_CORK has been eliminated. It didn't appear to provide any benefit. Based on the current Solaris implementation, it seemed to require additional sender code complexity and system calls. If, in the future, this proves to be an unwise decision, TCP_CORK can be re-implemented in audit_remote(5) without affecting the protocol. 3) An explicit outstanding audit record count (rather than the implicit one from the kernel's queue control high water mark) can be specified. The qsize keyword specifies this value. Note that auditd also interprets this keyword for each plugin and allocates plugin specific resources based on it. auditd's default is also the kernel's queue control high water mark.
PSARC/2009/332 New projects with boundless resources
> > I have another suggestion. Seeing that /etc/project already uses > > user. and group., why not svc., where is > > derived from the service FMRI? That seems sufficient to achieve our real > Doubleplus good. ;-) Gary..
PSARC/2009/332 New projects with boundless resources
> > We already have a "system" project why not: > > "system.inetd" > > "system.foo" > > I think Scott's concern about nesting is valid, but that's otherwise a > nice idea. Just as we have user.root, and group.staff, system.inetd seems the right level of nestedness. Gary..
nss_ldap should support AD-style groups [PSARC/2009/328 FastTrack timeout 06/10/2009]
> So +1 from me. Hopefully Gary is also reviewing this and making sure > that neither Nico nor I are missing anything. +1 Gary..
nss_ldap should support AD-style groups [PSARC/2009/328 FastTrack timeout 06/10/2009]
This case was never published to psarc-ext. I'm doing so on behalf of Nico (the I below) and extending the timer for a week from publication. Gary.. == I'm submitting this fasttrack on behalf of Erwin Aitenbichler, an OpenSolaris contributor. The release binding is micro/patch (with no intention to backport). This case introduces new behavior in nss_ldap(5) that rises to the level of an interface; this behavior will be Committed. BACKGROUND Microsoft's Active Directory (AD) can be used as Solaris name service repository through nss_ldap(5) by using Windows Identity Management for Unix (IDMU) or Service For Unix (SFU) and configuring schema mapping on the Solaris native LDAP clients. This is true on Solaris 10, Solaris Nevada, and OpenSolaris. PROBLEM AD supports richer group (as in Unix group) semantics than Unix. For example, it supports nested groups. But nss_ldap(5) does not support these semantics. Specifically, nss_ldap(5) uses the RFC2307bis+ memberUid attribute of group objects to construct a list of all users in a group. Whereas AD uses a different attribute, 'member', containing not UIDs but the DNs of members' directory objects (which may be users and groups alike). Also, each group object has a 'memberof' attribute listing the groups that the group is a member of. PROPOSAL nss_ldap(5)'s getbynam/getbygid entry points will use the 'member' attribute if the memberUid attribute is not present or has an empty value for the given group, but the member attribute is present and has a non-empty value. And nss_ldap(5) will expand the list of members recursively by searching the directory for each listed member and looking up any member group's members. nss_ldap(5)'s getbymember entry point will find the user's DN and then will query all groups a user is member of using this DN. For each group, the memberof attribute will be chased recursively to obtain the full list of groups that the user is a member of directly or indirectly. In both cases loops in group membership will be detected to prevent infinite looping. No additional configuration is needed to enable this feature.
PSARC/2009/333 str_to_label() update
> I'm sponsoring this case for myself. It updates the PSARC/2005/259 > "Layered Trusted Solaris Label Interfaces" str_to_label(3tsol) function. > > The commitment level remains Committed. A Patch release binding is requested. > A full diff marked man page is in the case directory. This case was approved at today's PSARC meeting. Gary..
PSARC/2009/333 str_to_label() update
I'm sponsoring this case for myself. It updates the PSARC/2005/259 "Layered Trusted Solaris Label Interfaces" str_to_label(3tsol) function. The commitment level remains Committed. A Patch release binding is requested. A full diff marked man page is in the case directory. The timer is set for 10 June, 2009. Gary.. ~~~ Background: == str_to_label() is the Committed interface to translate strings to various type of labels in Solaris Trusted Extensions. The implementation is a client side in libtsol(3LIB), which for label translation services call the labeld(1M) service. labeld in turn implements a set of algorithms which parse strings based on rules define in label_encodings(4). For MAC_LABEL type labels, a set of supplemental rules called the ACCREDITATION RANGE: are defined. str_to_label() does not provide an interface that takes these rules into account. There is a Project Private interface to check against the accreditation range. A recent request for a Committed interface lead to RFE 6845609 "str_to_label(3) should be able to verify if the label is within the accreditation range" Proposal: Provide for optional checking if the string being translated is acceptable to the accreditation range rules. A new error code, M_OUTSIDE_AR, will be returned if the resulting str_to_label() translation is not in the label_encodings(4) defined accreditation range and a new flag, L_CHECK_AR, is passed in. str_to_label(3TSOL): int str_to_label(const char *string, m_label_t **label, const m_label_type_t label_type, uint_t flags, int *error); DESCRIPTION The str_to_label() function is a simple function to parse human readable strings into labels of the requested type. [ . . . ] If flags is L_DEFAULT, the previously parsed label is replaced and the parsing algorithm makes a best effort to imply a valid label from the elements of string. +If flags contains L_CHECK_AR logically or-ed with another value, +the resulting label will be checked to ensure that it is within +the "Accreditation Range" of the DIA encodings schema. This flag +is only interpreted for MAC_LABEL label types. [ . . . ] ERRORS The str_to_label() function will fail if: EINVAL Invalid parameter. M_BAD_STRING indicates that string could not be parsed. M_BAD_LABEL indicates | that the label passed in was in error. M_OUTSIDE_AR + indicates that the resulting label is not within the + "Accreditation Range" specified in the DIA encodings + schema.
system_noshell [PSARC/2009/327 FastTrack timeout 06/05/2009]
> Which again re-enforces that system_noshell() *is* intended to be a
> replacement for system(3C).
>
> I have not problem with providing a variant of system(3C) that is more
> secure. However I'm not convinced that a new symbol - and thus changes
> to existing code to use it. Is the best way to do it. I wonder if this
> can be done more like the non exec stack, ie something that gets set at
> build time.
I too have no real problem with a more secure convenience function
version of system(3). I'm not convinced that this is it. Or without
changing to existing source code that system_noshell(3) will really
provide benefit sought.
Is part of this project to go through Solaris and fix callers
of system(3)? I didn't see that in the proposal.
I'm concerned about statements like:
"SN_RESETIDS If this flag is set, the file is executed by resetting
the effective user ID and the effective group ID of the
child process executing the file to the real user ID and
the real group ID of the parent.
The system_noshell() function resets the user and group IDs to those
of the real user, when used in setuid binaries. Use system_noshell_x()
and system_noshell_xv() to override this behavior. There will be no
change in privileges when the system_noshell() function is used in
non setuid binaries."
What does setuid have to do with privilege? Is this just imprecision
and the intent is setuid 0 -- thus implying all zone "forced"
privileges? Why wouldn't I want the ability to reset the privileges
to basic (or some priv set passed in)?
I'd think a convenince function should have similar ability to
if ((pid = fork()) != 0) {
/* parent */
while (pid != waitpid(pid, &status)) {
continue;
}
return (WEXITSTATUS(status);
} else if (pid == -1) {
/* couldn't fork */
return (-1);
}
/* child */
if (resetuids) {
(void) setuid(getuid());
(void) setgid(getgid());
}
if (resetprivs) {
(void) setppriv(PRIV_SET, PRIV_LIMIT, basic);
}
if (execv(path, argv) == -1) {
_exit(127)
}
/* NOPATH */
The project team should note that setuid 0 is not the only way
a program gains privilege. pfexec(1) -P and pfexec from a granted
Rigths Profile, svc.startd method_context are examples of other
ways. Is the intent to help these programs also?
Perhaps I've missed something as to why system_noshell() is being
proposed or proposed as it is.
Maybe some concrete usage examples (see Glenn's comment)).
Gary..
Configurable Boot Archive Updates [2009/312 05/26/2009]
> >>> Haven't we always documented uadmin(2) as the wrong way to do that? > >> I suspect you looked at the page, but for the record, the language is: > >> > >>"This function is tightly coupled to the system > >>administrative procedures and is not intended for > >>general use." > > > > Souldn't this be updated since uadmin now supports suspend/resume? No. As I've said before uadmin(1m) should be used. uadmin(1m) will appropriately shutdown services as needed across reboot and suspend/resume. > I'd consider that to still hold. sys-suspend(1) is the general > entry-point. If this is the PSARC/2009/112 sys-suspend(1), that's fine also. Though it does have some unresolved bugs. It is an interface that also will appropriately shutdown services. There are still issues going forward that the powermanagement team needs to resolve before there is a fully functional result. Fortunately this are below the uadmin(1m)/sys-suspend(1) layer. Gary..
Amendments to pconsole fast-track [PSARC/2009/275 FastTrack timeout 05/27/2009]
> >Ok, for TIOCSTI, there are effectively three choices here. > > > > 1. maintain the current behaviour, which appears to require > > PRIV_ALL > > 2. modify the behaviour to allow the device owner to use TIOCSTI, > > when the sessions match. > > 3. modify the behaviour to allow the device owner to use TIOCSTI > > regardless of session. > > > >Casper appears to believe that 1 is the only sane answer. Nico appears > >to believe that 2 is a reasonable answer. I suspect that 3 is off the > >table. > > The current implementation is: > if the ioctl flag is FREAD (read-only), then require all or EPERM > else > if (the session is the same as the current session) > then ok > else > require all or EACCES > So I'd say that the current behaviour is choice #2. > > But I think that's not what you actually want. If the return is EPERM, then pconsole has a bug that should just be fixed. If it is EACCES, then the question is why is it going after a tty not in its session? If pconsole's reason for existance is to violate the TIOCSTI, then either 3 or a Rights Profile is the way forward. BTW, has the question of policy on other systems that implement TIOCSTI been answered? Gary..
nfswatch [PSARC/2009/295 FastTrack timeout 05/14/2009]
> Thanks Garrett, Peter, Seb and Gary, for your review and > the comments for the case. We'll look into the concerns > that brought up and see what we can do. I thought Garrett derailed. Yet it still seems to have a waiting fast-track status. Garrett, if it is derailed, please update the status and work with the submitter and fast track owner to get a case owner and clarify the way forward. From this mail, it doesn't seem like the submitter is up to speed on the next steps. If it's not derailed, please clarify that. Gary..
nfswatch [PSARC/2009/295 FastTrack timeout 05/14/2009]
> I'll also point out that the case seems (IMO), to overlap with other > tools -- nfsstat, netstat, and snoop for example in a way that I think > the statement in the materials that this doesn't "compete" with other > Solaris tools or technologies might not be entirely true. > > So, given these problems, I'm formally derailing this case. And I hate to have to continue to be the rewind and replay last message: On SunOS 4.x and SunOS 5.x (Solaris 2.x): You must be the super-user to invoke _n_f_s_w_a_t_c_h or it must be installed setuid to ``root.'' Does the service manifests method context grant rights above that of the noaccess user and basic privilege set? [ ] Yes - ARC review required [*] No Are there any setuid/setgid privileged binaries in the project? [ ] Yes - ARC review required [*] No - continue with next section (section 3.4.3) So which is it? No privileges, or suid 0, implying all privileges. How does this match the administrative model for OpenSolaris of Rights Profiles? Gary..
Amendments to pconsole fast-track [PSARC/2009/275 FastTrack timeout 05/08/2009]
> From Norm.Jacobs at sun.com Wed May 6 22:07:44 2009 > Date: Thu, 07 May 2009 00:07:39 -0500 > From: Norm Jacobs > Subject: Re: Amendments to pconsole fast-track [PSARC/2009/275 FastTrack > timeout 05/08/2009] > To: Gary Winiger > Cc: gww at sac.sfbay.sun.com, leland.chen at sun.com, nicolas.williams at > sun.com, > psarc-ext at sun.com, timh at spidey.central.sun.com > Content-transfer-encoding: 7BIT > X-PMX-Version: 5.4.1.325704 > User-Agent: Thunderbird 2.0.0.21 (X11/20090323) > > Gary Winiger wrote: > >>IMO, this case should be withdrawn and the bug should be fixed. > >>If I'm wrong about the bug, then the case should be reintroduced > >>with rational as to why there isn't a bug and what the policy really > >>should be for TIOCSTI. > >> > >>I'll give the project team a while to answer this before considering > >>further steps, such as withdrawn, waiting need spec or even derail > >>for a meeting. > >> > > > > Filed: > > P3, 6838249 The TIOCSTI policy appears to require too many privileges > > > If we consider TIOCSTI failure with EPERM on devices you own a bug, then > this case can probably be withdrawn. Hummm, EPERM not EACCES. Assuming I'm reading things correctly, from the code pre-privileges, you'd get EPERM if you weren't root and you didn't have the file open for read. That's changed to if you don't have all privileges and you don't have the file open for read. So perhaps there's a pconsole change needed. On the other hand, again assuming I'm reading things correctly, from the code pre-privileges, you'd get EACCES if you were not root and the stream/tty was not in the same controlling session as the thread issuing the TIOCSTI. That's changed to, if you don't have all privileges and the issueing thread isn't in the same controlling session as the stream/tty. Is the intended use of pconsole to feed input to streams/ttys not in same controlling session as the thread issuing the TIOCSTI? Gary..
Amendments to pconsole fast-track [PSARC/2009/275 FastTrack timeout 05/08/2009]
> > IMO, this case should be withdrawn and the bug should be fixed. > If I'm wrong about the bug, then the case should be reintroduced > with rational as to why there isn't a bug and what the policy really > should be for TIOCSTI. > > I'll give the project team a while to answer this before considering > further steps, such as withdrawn, waiting need spec or even derail > for a meeting. Filed: P3, 6838249 The TIOCSTI policy appears to require too many privileges Gary..
Amendments to pconsole fast-track [PSARC/2009/275 FastTrack timeout 05/08/2009]
> Norm, > 4) Conclusion on privs/uids. > Nit: the exec_attr entry s/suser/solaris/ > Is it really the euid that matters, or is it that euid=0 gives > privs=all? I don't know how to answer the tiocsti question. > I'm not sure that's this case (though it would be nice if > the policy was revisited and this case dependent on that revisit), > but I'm not suggesting that be the a case requirement. > > Perhaps an offline email if I've not been clear. Talking to Nico off line about something else, he said he'd looked some at tiocsti and felt it was a bug that you couldn't control the tty/pty that you own. I don't find TIOCSTI adequately documented by Sun. But google did it. From my understanding of what it does, feeds input to a tty, I would say privs=all is quite extreme. The secpolicy_sti() comment says: "Simulate terminal input; another escalation of privileges avenue" I can see that if you're writing to a tty that you don't own. But if you own it, IMO this shouldn't be the policy and it is a bug. IMO, the correct architectural thing to do here is to fix the bug. I'd guess the policy to be, if you have write access to the tty, you should be able to issue a TIOCSTI. And to stop privilege escalation, the if owned by uid 0 policy also comes into play (file_dac_write is insufficient, privs=all is required). IMO, this case should be withdrawn and the bug should be fixed. If I'm wrong about the bug, then the case should be reintroduced with rational as to why there isn't a bug and what the policy really should be for TIOCSTI. I'll give the project team a while to answer this before considering further steps, such as withdrawn, waiting need spec or even derail for a meeting. Trying to stomp out bugs (that lead to unnecssary privileges), Gary..
snort [PSARC/2009/256 FastTrack timeout 05/04/2009]
Seb, > On Wed, 2009-05-06 at 13:23 -0700, Gary Winiger wrote: > > Explicitly copied Seb since he was case owner for libpcap. > Yes, and this is exactly why I suggested that /dev/bpf only require > net_observability for reading packets as part of the review for > 2009/232. If that happens, modifying libpcap to use /dev/bpf instead of > DLPI would result in all libpcap consumers only needing > net_observability. That isn't this case, though, it's the BPF case. > > As it stands today, because libpcap uses DLPI, consumers of libpcap need > net_rawaccess (it's what's required to interact with DLPI devices). If you're happy with that perhaps you want to give it a +1. My other comments were architecturally closer to code review. Gary..
Amendments to pconsole fast-track [PSARC/2009/275 FastTrack timeout 05/08/2009]
Norm, Sorry I didn't number my questions. I agree a Rights Profile is far more in keeping with minimizing the attack surface of programs than making them suid. Any how: 1) To whom is the "Parallel Console Access" Rights Profile granted? 2) How is the "Parallel Console Access" Rights Profile granted to users? What I'm trying to get at here is: Is Parallel Console Access automatically granted and if so to whom? 3) A help file needs to be part of creating this Rights Profile. See: http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ 4) Conclusion on privs/uids. Nit: the exec_attr entry s/suser/solaris/ Is it really the euid that matters, or is it that euid=0 gives privs=all? I don't know how to answer the tiocsti question. I'm not sure that's this case (though it would be nice if the policy was revisited and this case dependent on that revisit), but I'm not suggesting that be the a case requirement. Perhaps an offline email if I've not been clear. Thankx, Gary.. > Gary Winiger wrote: > >> /etc/security/prof_attr: > >> Parallel Console Access:::Connect to remote consoles with pconsole: > >> > > > > To whom/how is this Rights Profile granted? > > > > Also note that a help file needs to come with the addition of > > a Rights Profile. See: > > http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ > > > > > >> /etc/security/exec_attr: > >> Parallel Console Access:suser:cmd:::/usr/sbin/pconsole-bin:euid=0 > >> > > > > I've not seen a conclusion on privileges/uids. > > > It appears that unless the policy around TIOCSTI changes to allow the > device owner to use it, then pconsole-bin needs to run with euid=0 to be > useful. It seemed like creating a rights profile for this and allowing > assignment of that rights profile to a select set of users made more > sense than making pconsole-bin suid root. With a rights profile, our > customers can control access to it by assigning this profile to users > that have a need for pconsole. With it suid root, anyone can use it and > potentially use it to effectively hijack someone else's session. With > no rights profile and no suid root, you have to become root to use it. > > As for who is most likely to use it and therefore need access to the > profile, I expect, based on the original case, it will be sysadmins > managing clusters. > > -Norm >
snort [PSARC/2009/256 FastTrack timeout 05/04/2009]
Explicitly copied Seb since he was case owner for libpcap. > 1. For privileges(5), PRIV_NET_RAWACCESS is least required since snort > depends on > libpcap which sets NIC to RAW mode in order to monitor the flow of the box. > And the "Network Management" profile is necessary. From definition of > "net_observability" > in priv_names in /etc/security, it says > # > net_observability > Allows a process to access /dev/lo0 and the devices in /dev/ipnet/ > while not requiring them to need PRIV_NET_RAWACCESS. > # > > But libpcap needs to set NIC to raw, so I think net_rawaccess is > required, not net_observability. > One note however: snort only read data packets from libpcap, and it > doesn't try to encapsulate > an IP/TCP/UDP/* packet to send because libpcap doesn't support it. Not to belabor things here: Should libpcap be fixed so that it only needs net_observibility when reading packets? > 2. About the method context, I think user "root" and group "root" is > necessary. As following, please: Why is that? Why isn't noaccess:noaccess, privileges=net_raw_access (or net_observibility -- base on Seb's reply) sufficient? P.S. I don't see a reason for your stop method to have a method context. It appears to only be doing a :kill. > >> Network Management:solaris:cmd:::/usr/bin/snort:privs=net_rawaccess > >> > > > > Why isn't net_observibility be sufficient? > > > Please see above section about the reason and tell me if I misunderstand it. > Thank you in advance. OK and see my reply. > > > > > > > > > > >value='solaris.smf.manage.snort' /> > > > > > > > > Don't you also want a value authorization? See the SMF policy: > > http://opensolaris.org/os/community/arc/policies/SMF-policy/ > > > Sorry I was not quite familiar with the SMF, and in my understanding > about the SMF-policy after reading, it should be like following: Thus the policy. Project teams are responsible for following applicable policies -;) > ## > > value='solaris.smf.manage.snort' /> > value='solaris.smf.manage.snort' /> > > ## > > In this way, auth_attr should be inserted one item: > ## > solaris.smf.manage.snort:::Manage Snort Service > States::help=ManageSnort.html > ## > > In exec_attr, 1 item should be added. > The related exec_attr, auth_attr, snort.xml are in attachment. > ## > Network Management:solaris:cmd:::/usr/bin/snort:privs=net_rawaccess > ## Seem fine modulo the libpcap question. Gary..
Amendments to pconsole fast-track [PSARC/2009/275 FastTrack timeout 05/08/2009]
> /etc/security/prof_attr: > Parallel Console Access:::Connect to remote consoles with pconsole: To whom/how is this Rights Profile granted? Also note that a help file needs to come with the addition of a Rights Profile. See: http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ > /etc/security/exec_attr: > Parallel Console Access:suser:cmd:::/usr/sbin/pconsole-bin:euid=0 I've not seen a conclusion on privileges/uids. Gary..
snort [PSARC/2009/256 FastTrack timeout 05/04/2009]
> > > value='solaris.smf.manage.snort' /> > Don't you also want a value authorization? See the SMF policy: http://opensolaris.org/os/community/arc/policies/SMF-policy/ Gary..
snort [PSARC/2009/256 FastTrack timeout 05/04/2009]
> Hi, Gary, > >>> Snort does far more than just read files. It links to libpcap and can > >>> snoop on network interfaces in real time. To do *that*, it will > >>> require elevated privileges. > >>> > >>> > >> Right. > >> > > > > What are those elevated privileges. > > > For "privileges", I think you mean the auths of RBAC. No, I mean privileges(5). If it is a service then it also requires authorizations that follow the policy: http://opensolaris.org/os/community/arc/policies/SMF-policy/ And a further question if run as a service is what is the method context? > > What will be delivered into what Rights Profile? > > > It is very similiar to "wireshark" which has been delivered, since > both of the utilities take advantage of libpcap to read data and handle > them after set NIC to raw mode. For snort, it doesn't read data directly > from kernel memory, raw I/O from NIC is the way it works. > > And I believe "Network Management" profile is enough. > > The project will deliver SUNWsnortr and SUNWsnortu. On SUNWsnortr, > it will deliver profiles in /etc/security/exec_attr (added snort): > > Network Management:solaris:cmd:::/usr/bin/snort:privs=net_rawaccess Why isn't net_observibility be sufficient? Gary..
Amendments to pconsole fast-track [PSARC/2009/275 FastTrack timeout 05/08/2009]
> Amendment 1: > > The pconsole-bin binary requires elevated privilege to be useful. We > request to move the binary from the originally stated /usr/bin to > /usr/sbin, in line with where other binaries requiring privilege > usually exist. > > Amendment 2: > > A new execution profile and attribute will be defined. The specific > RBAC additions are: > > /etc/security/prof_attr: > Parallel Console Access:::Connect to remote consoles with pconsole: > > /etc/security/exec_attr: > Parallel Console Access:suser:cmd:::/usr/sbin/pconsole-bin:euid=0 ^ ^^ This is fine for S7-S9, but not for S10 forward. exec_attr(4): policyThe security policy that is associated with the profile entry. The valid policies are suser (stan- dard Solaris superuser) and solaris. The solaris policy recognizes privileges (see privileges(5)); the suser policy does not. The solaris and suser policies can coexist in the same exec_attr database, so that Solaris releases prior to the current release can use the suser policy and the current Solaris release can use a solaris policy. solaris is a superset of suser; it allows you to specify privileges in addition to UIDs. Policies that are specific to the current release of Solaris or that contain privileges should use solaris. Policies that use UIDs only or that are not specific to the current Solaris release should use suser. What are the elevated privileges and why are they required? Just those privileges should be specified in the privs= attribute. Why is there a need to specify a uid? Gary..
PSARC 2009/215 PCITool Public Interrupts
> From gww at eng.sun.com Fri May 1 11:31:26 2009 > Date: Fri, 1 May 2009 11:31:24 -0700 (PDT) > From: Gary Winiger > To: gww at sac.sfbay.sun.com, Erwin.Tsaur at sun.com > Subject: Re: PSARC 2009/215 PCITool Public Interrupts > Cc: Alan.Slivensky at sun.com, PSARC-ext at sun.com, pci-core at sun.com > > > > I've missed seeing the specification that pcitool will be > > > added to Maintenane and Repair and with what attributes. > > > > > > > > >> See > > >> http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ > > >> for how to add to the RBAC databases. > > >> > > > > > > I'm happy to coach how to deliver into the RBAC databases should > > > the best practice not be sufficient for the project team. > > > > > I've read the link above, and I believe I just need to... (please > > correct if wrong) add the line: > > > > Maintenance and Repair:solaris:cmd:::/usr/sbin/pcitool:privs=all > > > > to usr/src/lib/libsecdb/exec_attr.txt > > This is correct and says implicitly that there is no special > uid requirement. > If you need assistance in the delivery mechanism, let me know. My comment here presumed this is not part of ON. If it is part of ON packaging is already there. We can talk off line if we need to. Send me private email and we'll arrange a time. Gary..
PSARC 2009/215 PCITool Public Interrupts
> > I've missed seeing the specification that pcitool will be > > added to Maintenane and Repair and with what attributes. > > > > > >> See > >> http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ > >> for how to add to the RBAC databases. > >> > > > > I'm happy to coach how to deliver into the RBAC databases should > > the best practice not be sufficient for the project team. > > > I've read the link above, and I believe I just need to... (please > correct if wrong) add the line: > > Maintenance and Repair:solaris:cmd:::/usr/sbin/pcitool:privs=all > > to usr/src/lib/libsecdb/exec_attr.txt This is correct and says implicitly that there is no special uid requirement. If you need assistance in the delivery mechanism, let me know. > That's right, something left over from the old PSARC case, which I > removed now. Updated manpage included My issues are all addressed. I'll give it a +1. Gary..
PSARC 2009/215 PCITool Public Interrupts
> After discussing with Gary Winiger I am amending the PSARC case to > include more details about security. I'm probably being overly picky here. In my offline discussions there seemed to be confusion about the (architectural) details. Including that I'm not the only one on the committee. > From project team: > It is currently not in the "Maintenance and Repair" Rights Profile and > we don't plan to ship it with it configured in it. Do you recommend > otherwise? > > From Gary Winiger: > Manintenance and Repair seems like an appropriate Rights Profile. > The specification can state that the will be adding /usr/sbin/pcitool > to the existing Maintenance and Repair Rights Profile with attributes > of --- and you state the attributes. I've missed seeing the specification that pcitool will be added to Maintenane and Repair and with what attributes. > See > http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ > for how to add to the RBAC databases. I'm happy to coach how to deliver into the RBAC databases should the best practice not be sufficient for the project team. > Maintenance Commands pcitool(1M) > > NAME > pcitool - interrupt routing tool > > SYNOPSIS > /usr/sbin/pcitool PCI_nexus_node -i ino=ino [ -r [ -c ] | -w > cpu=CPU [ -g ] ] [ -v ] [ -q ] > > /usr/sbin/pcitool [ -h ] > Required privileges > > The user must have all privileges in order to access inter- > rupt information. A regular user can access interrupt > information when su(1M) to root or granted the "Maintenance > and Repair" rights profile in the user_attr file. See > user_attr(4) and rbac(5). > SEE ALSO > pci(4), su(1M), user_attr(4), rbac(5) > > NOTES > Root access is required to execute all commands in this > tool. Probably a nit. The preceeding gives me pause over what the specification for Rights Profiles inclusion really is. Should this note just be eliminated, or is there some hard requirement for euid==ruid==0 which cannot be met otherwise. Gary..
PSARC 2007/064 Unified POSIX and Windows Credentials for Solaris
> From sacadmin Mon Nov 5 12:12:37 2007 > Date: Mon, 5 Nov 2007 12:07:58 -0800 (PST) > From: Gary Winiger > To: gww at eng.sun.com, mws at zion.sfbay.sun.com > Subject: Re: PSARC 2007/064 Unified POSIX and Windows Credentials for Solaris > Cc: psarc at sac.sfbay.sun.com, arc-discuss at opensolaris.org, john.plocher > at sun.com > > > I'll handle the opinion updates. > > Done. I've fixed the opinion. I finally got this re-re-redacted. This time I took a big hammer to the mail log. If members object to this, feel free to redo it ;-) Gary..
snort [PSARC/2009/256 FastTrack timeout 05/04/2009]
> > Snort does far more than just read files. It links to libpcap and can > > snoop on network interfaces in real time. To do *that*, it will > > require elevated privileges. > > > Right. What are those elevated privileges. > > Do those come from RBAC, or is the user expected to use "sudo"? > > > "sudo" could work. What will be delivered into what Rights Profile? Gary..
PSARC 2009/265 fmdump -m
> I am sponsoring the following case for Rob Johnston to add a -m > option to fmdump to permit administrators to retrieve the human-readable > message for a fault entry from an FMA log. >4.4. Interfaces: > The command-line options and human-readable output for fmdump(1m) are > evolving. Nit. Evolving is old speak. In new speak it would be Committed. Do you really what to say the human-readable output is a Committed programming interface. Perhaps command line option is Committed and human-readable output is Not-An-Interface (also part of new speak). Gary..
snort [PSARC/2009/256 FastTrack timeout 05/04/2009]
> sort monitors logfiles; if it can read those, there's no need for additional > privileges. OK, thanks. I didn't get that from looking at the man page or website;-) Gary..
snort [PSARC/2009/256 FastTrack timeout 05/04/2009]
> 3.4.2 Authorization > (see http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ > and > http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ > and > http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ >for details) > Are there any setuid/setgid privileged binaries in the project? > [ ] Yes - ARC review required > [*] No - continue with next section (section 3.4.3) > > If yes then are the setuid/setgid privileges handled by the use of > roles? > [ ] Yes > [ ] No - ARC review required If it's not suid (as ping is), I presume that snort needs something like net_observibility or net_raw_access to run properly. How does it get that or any other privileges it may need? What Rights Profile (and exec_attr(4) properties are required)? Gary..
PSARC 2009/215 PCITool Public Interrupts
> >>My recollection from 2005/232 was there was a discussion > >>about non-standard install places. How was that resolved? > >> > >> I wasn't part of that discussion back then. Not sure what that would be > >> about. > >> > > > > As the project is largely relying on that case with was about > > an unbundled integration, it seems to me appropriate for the > > project team to review the basis of this case and ensure that > > the issues that were raised there are resolved now. > > Saying something is not shipped with the WOS, but as an unbundled > > with a limited set of users leads to different packaging and > > installation that something shipping with the WOS. Since a > > patch binding has been requested, the WOS in this case is > > S10. > > > Yes good point. There is another discussion going on about this whole > packaging issue. It is definitely being scrutinized as the requesters > for this tool all have their own requirements and such. If this is still being discussed, isn't the case premature? Shouldn't this case be in waiting need spec until all relevant peripheral discussions have completed? > >>> Risks and Assumptions: > >>> PCITool allows privileged users to remap interrupt-CPU bindings > >>> > >>What's a "privileged user"? What Rights Profile will pcitool > >>be in? Again my recollection from 2005/232 is that "all" > >>privileges is required. Is that still the case? Is there > >>also some specific userID that's necessary > >> > >> Same rights nothing has changed, except some documentation. > >> > > > > Again there was a discussion of privileges that didn't > > seem to converge. From the man page, I could read that > > the only privilege needed is sys_res_config. 2005/233 > > seemed to imply privs=all. This case materials doesn't > > define how, now that pcitool will be provided as part of > > the WOS, the sys_res_config privilege is granted to > > pcitool. Specifically, what Rights Profile and is sys_res_config > > the only privilege granted? Are there any uid requirements? > > > The privileges really refer to the ioctls which this package has nothing > to do with. We are only dealing with the userland binary. Ok, the privileges refer to the ioctls. I presume the userland binary calls the ioctls. Is the only privilege the userland binary requires sys_res_config? How does the userland binary gain this or any other privileges? Gary..
PSARC 2009/215 PCITool Public Interrupts
> From: Gary Winiger > > Project Description: > > PCITool was previously conceived in PSARC 2005/232, but was > > intended as an internal only tool. This case would make the > > command line interface, pcitool, available to external customers. > > My recollection from 2005/232 was there was a discussion > about non-standard install places. How was that resolved? > > I wasn't part of that discussion back then. Not sure what that would be > about. As the project is largely relying on that case with was about an unbundled integration, it seems to me appropriate for the project team to review the basis of this case and ensure that the issues that were raised there are resolved now. Saying something is not shipped with the WOS, but as an unbundled with a limited set of users leads to different packaging and installation that something shipping with the WOS. Since a patch binding has been requested, the WOS in this case is S10. > > Risks and Assumptions: > > PCITool allows privileged users to remap interrupt-CPU bindings > > What's a "privileged user"? What Rights Profile will pcitool > be in? Again my recollection from 2005/232 is that "all" > privileges is required. Is that still the case? Is there > also some specific userID that's necessary > > Same rights nothing has changed, except some documentation. Again there was a discussion of privileges that didn't seem to converge. From the man page, I could read that the only privilege needed is sys_res_config. 2005/233 seemed to imply privs=all. This case materials doesn't define how, now that pcitool will be provided as part of the WOS, the sys_res_config privilege is granted to pcitool. Specifically, what Rights Profile and is sys_res_config the only privilege granted? Are there any uid requirements? Nit: the case mail says volatile commitment, while the man page says project private. Gary..
