From sacadmin Wed Jun 12 10:53:24 2002 Date: Wed, 12 Jun 2002 10:50:38 -0700 From: Jordan Brown X-Accept-Language: en MIME-Version: 1.0 To: psarc@sac.eng.sun.com, Casper Dik Subject: 2002/188 Least privilege Content-Transfer-Encoding: 7bit Status: RO Lines: 65 X-Lines: 65 Content-Type: text/plain; charset="us-ascii" Content-Length: 3516 I added a level 0 issue on this case this morning, and now I'm reminded that I have a conflicting SC review on my project. Sigh. I'll try to join briefly, but don't know if I'll be able to. Here's a brief summary of my concern/proposal. I've discussed this with the project team before, but I don't think I ever adequately communicated it - they didn't seem to "get" what I was proposing and why it was perhaps a good idea. Perhaps somebody is reading mail on their notebook and can read or summarize this during the meeting. Hopefully somebody on PSARC will "get it" and can carry the ball. If not, then this must just be the product of my fevered imagination... I don't claim that I have identified all of the issues with this proposal, or how all of the details would be managed. I don't claim that there are no killer problems with it. However, so far I haven't seen any, and in my mind the resulting model is sufficiently better than the Least Privilege proposal that it merits serious consideration. Thanks. --- This project proposes to add a new mechanism for conveying "extra" powers on a process, a new namespace for specifying those powers, and new administrative mechanisms for managing them. Solaris already has a mechanism for managing "extra" powers: the RBAC authorizations mechanism. It seems to me that these two mechanisms can be merged, forming a more powerful model without significantly increasing the complexity of the administrative model. Fundamentally, I believe that the two mechanisms are very similar. They both give a process powers over and above its "natural" powers. I believe that the fact that RBAC authorizations are checked by userland programs and "privileges" are checked by the kernel is irrelevant. The point is that a privileged entity (the kernel, a daemon, or a setuid program) checks to see whether the entity making the request is appropriately authorized. In a model where the "userland" and "kernel" cases are handled differently, what would happen if functionality migrates from one place to the other? Would all the world's administrators have to change their configurations to reflect the new implementation? Such a transition is not merely conjecture; it's happened to one extent or another several times in the past. Suppose that we wanted to control whether or not a particular entity could create directories. "mkdir" used to be a setuid root program that did mknod() and link() calls to do its work. As a userland program, it would presumably use an RBAC authorization to make its authorization decision. When mkdir was made into a system call, it would presumably use a privilege to make the decision. Similarly, I believe we've seen kernel functionality moved into daemons, with library interfaces hiding the implementation. One obvious difference is that authorizations are granted on a per-user basis, while privileges are per-process. I believe that this difference can mostly be addressed by making authorizations per-process too, and having login and its ilk set up the initial authorizations for a session based on the authorizations specified for the user. Those authorizations would then be inherited by any descendents, as long as none of the descendents didn't explicitly renounce any of them. The effect would be much the same as group membership: /etc/group says that I'm a member of group sac, but the actual implementation of that membership is through initialization at login time and then process inheritance. From sacadmin Wed Jun 12 14:44:27 2002 Date: Wed, 12 Jun 2002 14:43:04 -0700 (PDT) From: Gary Winiger To: psarc-record@sac.eng.sun.com Subject: PSARC 2002/188 Least Privilege commonality with FSI Status: RO Content-Length: 36 Lines: 2 X-Lines: 2 ----- Begin Included Message ----- From least-priv-request@sun.com Wed Jun 12 14:41:11 2002 Date: Wed, 12 Jun 2002 14:41:07 -0700 (PDT) From: Gary Winiger To: fsi-iteam@sun.com Subject: FSI PSARC 2000/305 Interface commonality with PSARC 2002/188 Least Privilege Cc: least-priv@sun.com, casper.dik@sun.com, psarc@sac.eng.sun.com Status: RO Content-Length: 1032 Lines: 21 X-Lines: 21 Bev suggested this was the proper alias to send this information. If it should go further, would someone kindly forward it. PSARC/2002/188 Least Privilege for Solaris proposes to introduce fine grained privileges into Solaris for various access checks. As a side effect, it proposes to make the cred structure opaque and introduces a number of interfaces for cred structure element manipulation (e.g., crgetuid()). At PSARC today, it was suggested that coordination between 188 and FSI is appropriate. Further 188 proposes to abstract much (all) of the policy from the present inline code to procedures for transparency to privilege and other future (kevlar, Trusted Solaris, ...) policies (e.g., secpolitcy_fs_ids_modify(cred_t *, vnode_t *)). Again coordination between projects seems appropriate. While the case materials are not final, IMO, they are quite sufficient to get a good feeling of these two coordination opportunities before the project teams look for committment. Gary.. ----- End Included Message ----- From sacadmin Tue Jun 18 08:46:55 2002 To: Jordan Brown cc: psarc@sac.eng.sun.com Subject: Re: 2002/188 Least privilege Date: Tue, 18 Jun 2002 17:44:06 +0200 From: Casper Dik Status: RO Content-Length: 9642 Lines: 181 X-Lines: 181 >Here's a brief summary of my concern/proposal. I've discussed this with >the project team before, but I don't think I ever adequately >communicated it - they didn't seem to "get" what I was proposing and why >it was perhaps a good idea. Perhaps somebody is reading mail on their >notebook and can read or summarize this during the meeting. Hopefully >somebody on PSARC will "get it" and can carry the ball. If not, then >this must just be the product of my fevered imagination... I think we get it, we just don't agree with your argument. I feel you are focussing too much on just one aspect of least privilege, assigning privileges through /etc/user_attr, and not the overall picture. Least Privilege is about breaking root's powers in smaller bits; it is not about giving more powers to processes. It's about getting rid of all-or-nothing. Let me start off with stating that the difference between authorizations and privileges is not something we arbitrarily made up; it is a well established distinction, witness this quote from the (defunct) POSIX draft (with substitutions of privilege for capability): Authorization vs Privilege The power to perform an action in a trusted system based on user identity is called an ``authorization.'' Authorizations are generally designed around operational requirements and tasks rather than system services. For example, an authorization to perform backups would be granted to a user. The backup program however, would enable and disable specific privileges to perform the backup function. A system that supports authorizations simplifies the administrative task of the security officer by eliminating the need to comprehend exactly which privileges each program requires and how to allocate those privileges to users. This, I think, already explains a great deal about the relationship between authorizations and privileges. I agree that by also giving the ability to award privileges directly to users, we are somewhat muddying the distinction; but we are more or less required to do so because, as an extra step in hardening the system, we have moved some unprivileged operations to the set of privileged actions and want to give all users these privileges by default. This mechanism was then easily extended to allow direct granting of privilege, which we feel is useful for a limited set of privileges in a limited set of circumstances. (Realtime) >Solaris already has a mechanism for managing "extra" powers: the RBAC >authorizations mechanism. It seems to me that these two mechanisms can >be merged, forming a more powerful model without significantly >increasing the complexity of the administrative model. Least Privilege is mostly about removing powers, not adding to them. The part you object to just falls out for a tiny administrative cost. RBACs assigns these additional powers to *users* or *roles*. These powers are *application specific* and potentially fine grained. The RBAC powers are invoked on purpose by invoking the application that uses these authorizations to specifically perform a specific task. RBAC authorizations allow, e.g., the ability to read/modify all files owned by a *specific* user, kill all process owned by a *specific* user, modify a particular set of fields inside a particular file, allows to bind to a specific reserved port using helper programs that may run privileged or may run as a different uid. E.g., we can easily extend RBAC with solaris.jobs.casper.* or solaris.objects.casper.*. The potential number of authorizations is boundless. Least Privilege splits the traditional super-user power in little itty powers; these powers are limited in number, are used by many applications, and have a global scope (a privilege works on all files, all processes, all user ids, the complete file contents, all reserved ports, etc) >Fundamentally, I believe that the two mechanisms are very similar. They >both give a process powers over and above its "natural" powers. I >believe that the fact that RBAC authorizations are checked by userland >programs and "privileges" are checked by the kernel is irrelevant. The >point is that a privileged entity (the kernel, a daemon, or a setuid >program) checks to see whether the entity making the request is >appropriately authorized. Authorizations do not give a *process* additional powers, they give a *user* additional powers. A privilege can be used inside a process, an authorizations requires a *different process* to be started, making the use of an authorization a *deliberate* act. Privileges, on the contrary, are valid in the context of any process. It is important that the privilege to give files away is not usually present as it would make unpacking tar files a nightmare. The authorization to give files away can be invoked if need be; such an implementation would necessarily make use of the privilege to give files away but using an intermediate process that verifies the authorization and then runs with (a) certain privilege(s). >In a model where the "userland" and "kernel" cases are handled >differently, what would happen if functionality migrates from one place >to the other? Would all the world's administrators have to change their >configurations to reflect the new implementation? Pretty much the same happens as will happen with our current proposed changes. Currently, authorizations may cause certain applications to be executed with different uids or, more specifically, euid 0. Or setuid root applications perform authorization checks themselves and then perform actions with elevated privilege (i.e., euid 0). An Authorizations maps to euid 0 in a restricted fashion. In our proposed scheme, the authorizations don't change, but the elevated privilege scheme changes; rather than giving all of euid 0, we use only specific privileges to perform the authorized function. An Authorization maps to one or more privileges in a restricted fashion. It is not that important if certain functionality moves from the kernel to userland or vice versa; the specific authorization remains, the underlying implementation changes. >Such a transition is not merely conjecture; it's happened to one extent >or another several times in the past. Suppose that we wanted to control >whether or not a particular entity could create directories. "mkdir" >used to be a setuid root program that did mknod() and link() calls to do >its work. As a userland program, it would presumably use an RBAC >authorization to make its authorization decision. When mkdir was made >into a system call, it would presumably use a privilege to make the >decision. Similarly, I believe we've seen kernel functionality moved >into daemons, with library interfaces hiding the implementation. The mkdir example is not very convincing; while the program was required to be set-uid root, that was merely a workaround for a deficiency in the Unix kernel, not because mkdir() was a privileged operation. Mkdir() required two dangerous, restricted, operations which, when combined in the manner mkdir(1) combined them, were almost benign. (Users could still mess up the filesystem using set-uid mkdir()). Since it mkdir() was never restricted, this borders on a strawman. >One obvious difference is that authorizations are granted on a per-user >basis, while privileges are per-process. I believe that this difference >can mostly be addressed by making authorizations per-process too, and >having login and its ilk set up the initial authorizations for a session >based on the authorizations specified for the user. Those >authorizations would then be inherited by any descendents, as long as >none of the descendents didn't explicitly renounce any of them. The >effect would be much the same as group membership: /etc/group says that >I'm a member of group sac, but the actual implementation of that >membership is through initialization at login time and then process >inheritance. I'm not sure if I follow this; you want me to completly change the semantics of authorizations jsust so that they can be implemented like privileges? Authorization would suddenly be "revokable" and could possibly be given by users to other users (by means of Forced "Privileges"), again something we do not which to allow; the *.grant authorizations would become implicit, as unwanted side effect. You'd also have "privileges" that allow you to perform tasks that require different privileges. E.g., the solaris.chown.file Authorization would be one bit which would be checked by RBAC and then it would run code with the "file_chown" bit set. It should be clear by now why someone with the "solaris.file.chown" Authorization doesn't get to run all his processes with the "file_chown" Privilege. How do you explain that a process with the "solaris.apache.purge.logfiles" Authorization (kernel based) cannot ``unlink("/var/log/apache/web.log")'' but needs to go through RBAC anyway? I think that all is very confusing. I think we should keep authorizations as they are, in user space. Ammend exec_attr to use privileges instead of euid 0. The changes to user_attr at to the administration; but privileges cannot only be added but also limited, etc. It's a model that doesn't fit with the static nature of authorizations. You could add authorizations as you add groups: fixed at login time; but without allowing transferring of authorizations. Drawback: users cannot have authorizations added without logging back in nor can authorizations be revoked as fast as the nameservice propagetes the changes. But that is beyond the scope of this project .... Casper From sacadmin Tue Jun 18 17:32:46 2002 Date: Tue, 18 Jun 2002 17:26:20 -0700 From: Jordan Brown X-Accept-Language: en MIME-Version: 1.0 To: Casper Dik CC: psarc@sac.eng.sun.com Subject: Re: 2002/188 Least privilege Content-Transfer-Encoding: 7bit Status: RO Lines: 220 X-Lines: 220 Content-Type: text/plain; charset="us-ascii" Content-Length: 10119 > I think we get it, we just don't agree with your argument. I feel > you are focussing too much on just one aspect of least privilege, assigning > privileges through /etc/user_attr, and not the overall picture. No, not at all. My biggest concerns are: . namespaces - why have two? . administrative model - why have two? . flexibility and generality - where the feature is implemented should not be important. Solaris (and UNIX - much of this is legacy) already has too darned many authorization control mechanisms. Can't we try to unify some of them, and implement new features as extensions to existing ones? A brief list: . file system access bits and ACLs . implications of your UID and GID . at.{deny,allow} . cron.{deny,allow} . RBAC . lpadmin -u . SunMC access rules and probably any number of others that I'm missing. > Least Privilege is about breaking root's powers in smaller bits; it is > not about giving more powers to processes. It's about getting rid of > all-or-nothing. Sure. So are Authorizations. In the bad old world if you wanted to give a user some extra powers, you had to give them the root password. With Authorizations, you can just give them the authorizations they need. Your one-pager says (section 2.1): ... allowing processes with a non-0 effective uid to still have some of the powers that originally were root's prerogative ... which sure sounds a lot like giving them more powers. > RBACs assigns these additional powers to *users* or *roles*. These > powers are *application specific* and potentially fine grained. > The RBAC powers are invoked on purpose by invoking the application > that uses these authorizations to specifically perform a specific task. Why is system("pfexec /bin/chown jordan:staff /etc/passwd") intrinsically different from chown("/etc/passwd", 26718, 10) ? How do you know that chown() isn't implemented using system()? Why does it matter? > The potential number of authorizations is boundless. Sure. Isn't the potential number of privileges boundless too? Didn't somebody say Past experience has shown that for any number N, and for almost any object O, the statement "we'll never need more than N of O" is invariably untrue. > Authorizations do not give a *process* additional powers, they give > a *user* additional powers. A privilege can be used inside a process, > an authorizations requires a *different process* to be started, making > the use of an authorization a *deliberate* act. Again, how do you know how chown() is implemented? Starting a new process may be an implementation detail of implementing a particular API - an implementation detail that should make no difference. A process is either allowed to perform a particular action - however it might be implemented - or it's not. *Why* it's permitted to perform that operation should not be important to the checking mechanism, and where the check is implemented should not be important to the mechanism that the administrator uses to control whether the operation is permitted. > The mkdir example is not very convincing; while the program was required > to be set-uid root, that was merely a workaround for a deficiency in the > Unix kernel, not because mkdir() was a privileged operation. Mkdir() > required two dangerous, restricted, operations which, when combined in > the manner mkdir(1) combined them, were almost benign. (Users > could still mess up the filesystem using set-uid mkdir()). > > Since it mkdir() was never restricted, this borders on a strawman. Considering the last point first, sure, it's a straw man. We're talking about hypothetical futures here. The system is pretty mature; people have done a pretty good job of sifting "primitive" operations from "complex" operations and migrations like this are likely to be uncommon. You've said that you want to be able to restrict operations that are currently available to a "standard" user... mightn't mkdir be one of the operations that could be restricted? Here's another straw man: /bin/passwd is merely a workaround for a deficiency in the kernel: it doesn't have a "set password" system call. Presumably RBAC should control whether or not you're allowed to run today's /bin/passwd, right? Suppose that we implement a "set password" system call. That would allow /bin/passwd to run without full root privileges, and without even the dangerous power to write /etc/passwd. In fact, /bin/passwd mightn't need *any* special privileges; it could be an ordinary program exercising the setpasswd() system call just like any other program could exercise it. How would we then decide who is allowed to set passwords? If there's a new privilege associated with setpasswd() then presumably administrators have to grant that privilege to users, right? Wouldn't it be better if the RBAC authorization that /bin/passwd used to check was still exactly the right way to control who can set their password? (Yes, granting an authorization could be mapped to granting a privilege. In many ways that's what I'm suggesting, that privileges could be completely buried as an implementation detail and the only thing that administrators would need to be aware of would be authorizations.) > I'm not sure if I follow this; you want me to completly change the > semantics of authorizations jsust so that they can be implemented > like privileges? I wouldn't say "completely change"; I would say "extend". I think the existing semantics of authorizations would be _pretty much_ retained, but they would gain new semantics. The goal would not be "so that they can be implemented like privileges", but rather so that privileges could be implemented as authorizations, so that there would not be a new concept created but rather an old concept extended to cover new ground. > Authorization would suddenly be "revokable" Meaning that they could be turned off? Sure. Sounds like a good idea to me; I want to be able to run my freeware game in an environment where it can't say system("pfexec chmod 666 /etc/passwd") even if I have the "Object Access Management" profile. (Yes, this is confusing the issue by bringing profiles into it, but there too /etc/security/exec_attr should have been tied to authorizations, not profiles.) > and could possibly be given by users to other users (by means of > Forced "Privileges"), again something we do not which to allow; > the *.grant authorizations would become implicit, as unwanted side effect. Hmm. Interesting. However, I contend that such a mechanism already exists - if I make an executable setuid to myself, it can execute other programs and make use of my authorizations and profiles. In fact, all it'd need to do is to setuid(geteuid()) and exec pfsh. Presumably the answer to this question is to check the relevant *.grant authorization before allowing a user to set a forced privilege. Wouldn't you want a similar check on privileges? Putting the shoe on the other foot, doesn't it seem reasonable to be able to set Netscape so that it has the "is allowed to print" authorization, allowing a user not otherwise allowed to print to print from Netscape? Shouldn't the daemon that receives network print requests have exactly the "allowed to queue print jobs" authorization, and nothing more? Do we have to create a new UID for every service that needs a distinct set of user-level authorizations? Wouldn't it be nice if I could grant my CGI program the ability to print files as me, or the ability to send mail as me, without granting it the ability to write my files? > You'd also have "privileges" that allow you to perform tasks that > require different privileges. E.g., the solaris.chown.file > Authorization would be one bit which would be checked by RBAC and then > it would run code with the "file_chown" bit set. It should be clear by > now why someone with the "solaris.file.chown" Authorization doesn't > get to run all his processes with the "file_chown" Privilege. I understand why they might not *want* to, but I don't understand why they don't *get* to. If I have Object Access Management, I can run all programs *as if* they have file_chown by writing a shared object that interposes on chown() and does system("pfexec chown ...") under the covers. > How do you explain that a process with the "solaris.apache.purge.logfiles" > Authorization (kernel based) cannot ``unlink("/var/log/apache/web.log")'' > but needs to go through RBAC anyway? So if I (jordan) have the solaris.apache.purge.logfiles Authorization, why can't I "rm /var/log/apache/web.log"? The answer is that they are context sensitive: not only must you be attempting an authorized operation, but you must be attempting it using an authorized mechanism. That raises a different issue: why isn't the ability to unlink this file controlled by the ACLs on its directory? > [...] the static nature of authorizations. Are UIDs static, or dynamic? They're statically assigned in /etc/passwd, but can be dynamically changed using setuid() and setuid programs. > You could add authorizations as you add groups: fixed at login time; > but without allowing transferring of authorizations. Drawback: users > cannot have authorizations added without logging back in nor can > authorizations be revoked as fast as the nameservice propagetes the > changes. But that is beyond the scope of this project .... I don't quite follow the first sentence here; I think it's a lot like what I was suggesting. (At least it has the same drawbacks :-). However, I can't get too worried about revoking an authorization fast when we can't revoke system access fast. (That is, turning somebody's account off doesn't kill their processes.) --- So, PSARCers: if you've read to this point, you've read just about all I have to say on the subject. If what I'm saying makes sense as something to discuss further, please say so. If nobody but me thinks that it's an interesting approach to pursue, then I'll happily stop wasting people's time; either I'm a visionary ahead of my time, or I'm on drugs. From sacadmin Tue Jun 18 17:44:19 2002 Date: Tue, 18 Jun 2002 17:42:42 -0700 (PDT) From: Gary Winiger To: Casper.Dik@Sun.Com, Jordan.Brown@Sun.Com Subject: Re: 2002/188 Least privilege Cc: psarc@sac.eng.sun.com Status: RO Content-Length: 681 Lines: 29 X-Lines: 29 > Solaris (and UNIX - much of this is legacy) already has too darned many > authorization control mechanisms. Can't we try to unify some of them, > and implement new features as extensions to existing ones? I've not read closely, but somethings jumped out here. > A brief list: > > . file system access bits and ACLs Missing is SysV IPC access bits. > . implications of your UID and GID This should all be replaced by privileges and authorizations. > . at.{deny,allow} > . cron.{deny,allow} > . RBAC > . lpadmin -u > . SunMC access rules RBAC should replace all these. But since the world is not yet of a single mind multiplicity is still rampent. Gary.. From sacadmin Tue Jun 18 18:02:16 2002 Date: Tue, 18 Jun 2002 17:55:51 -0700 From: Jordan Brown X-Accept-Language: en MIME-Version: 1.0 To: Casper Dik , psarc@sac.eng.sun.com Subject: Re: 2002/188 Least privilege Content-Transfer-Encoding: 7bit Status: RO Lines: 11 X-Lines: 11 Content-Type: text/plain; charset="us-ascii" Content-Length: 511 I see that your proposal wants to add new attributes onto file system objects, but seems to say that you can't because of lack of infrastructure. Seems like this is exactly the kind of thing that the file system attributes project was intended to address; it seems like this makes it time for Phase II of that project where they start assigning some semantics to particular attribute names. BTW, I took the liberty of running "distill" on the .ps file to produce a .pdf file, since .pdf files are searchable. From sacadmin Wed Jun 19 07:25:24 2002 To: Jordan Brown cc: psarc@sac.eng.sun.com, least-priv@sun.com Subject: Re: 2002/188 Least privilege Date: Wed, 19 Jun 2002 16:22:33 +0200 From: Casper Dik Status: RO Content-Length: 1140 Lines: 27 X-Lines: 27 >I see that your proposal wants to add new attributes onto file system >objects, but seems to say that you can't because of lack of >infrastructure. Correct. Early in the project we foolishly lingered some in the expectation that the attribute project would add system attributes. >Seems like this is exactly the kind of thing that the file system >attributes project was intended to address; it seems like this makes it >time for Phase II of that project where they start assigning some >semantics to particular attribute names. The filesystem attribute project refused to reserve name space saying that "NFSv4 requires us to have no reserved name space". They made it impossible to have "system attributes', much to the chagrin of ours and other projects. It has caused us heartburn and delay; we will not address the file attributes as part of this project but would welcome to have this added as advice to the case. >BTW, I took the liberty of running "distill" on the .ps file to produce >a .pdf file, since .pdf files are searchable. Cool; I didn't know we had that (I don't think pdf2ps generates searchable files) Casper From sacadmin Wed Jun 19 07:36:19 2002 Date: Wed, 19 Jun 2002 07:29:53 -0700 From: Jordan Brown X-Accept-Language: en MIME-Version: 1.0 To: Casper Dik CC: psarc@sac.eng.sun.com, least-priv@sun.com Subject: Re: 2002/188 Least privilege Content-Transfer-Encoding: 7bit Status: RO Lines: 31 X-Lines: 31 Content-Type: text/plain; charset="us-ascii" Content-Length: 1405 > >Seems like this is exactly the kind of thing that the file system > >attributes project was intended to address; it seems like this makes it > >time for Phase II of that project where they start assigning some > >semantics to particular attribute names. > > The filesystem attribute project refused to reserve name space saying > that "NFSv4 requires us to have no reserved name space". They made it > impossible to have "system attributes', much to the chagrin of ours and > other projects. It has caused us heartburn and delay; we will not address > the file attributes as part of this project but would welcome to have > this added as advice to the case. When PSARC reviewed their case they said "we don't want to get into that yet; we will do that in a future phase". It was clear that there was a need for attributes with security semantics that would need intelligent management. If NFSv4 precludes attributes with security semantics, we should either get NFSv4 fixed or rip the Attributes project back out as a waste of memory. AndyR, you know those guys; want to have a chat with them? > >BTW, I took the liberty of running "distill" on the .ps file to produce > >a .pdf file, since .pdf files are searchable. > > Cool; I didn't know we had that (I don't think pdf2ps generates > searchable files) I get my copy from /usr/local/bin, but it looks like there's a copy in /usr/dist/exe. From sacadmin Wed Jun 19 08:52:31 2002 To: Jordan Brown cc: psarc@sac.eng.sun.com, least-priv@sun.com Subject: Re: 2002/188 Least privilege Date: Wed, 19 Jun 2002 17:49:40 +0200 From: Casper Dik Status: RO Content-Length: 8234 Lines: 216 X-Lines: 216 >> I think we get it, we just don't agree with your argument. I feel >> you are focussing too much on just one aspect of least privilege, assigning >> privileges through /etc/user_attr, and not the overall picture. > >No, not at all. My biggest concerns are: > >. namespaces - why have two? Because Authorizations an dPrivileges are two very different things; nor do we believe that polluting the kernel with userland attributes is a good thing. >. administrative model - why have two? There is only one administrative model: user_attr. >. flexibility and generality - where the feature is implemented should >not be important. Non sequitur; they are different things, therefor they are implemented differently. >Solaris (and UNIX - much of this is legacy) already has too darned many >authorization control mechanisms. Can't we try to unify some of them, >and implement new features as extensions to existing ones? > >A brief list: > > . file system access bits and ACLs > . implications of your UID and GID > . at.{deny,allow} > . cron.{deny,allow} > . RBAC > . lpadmin -u > . SunMC access rules I believe the SunMC (which if that's the SMC I'm thinking of) has the same rules as RBAC. The last 5 entries should all be under RBAC. The first two are the same (or not); but if they are not and you're talking about the implication of uid 0 or not; that is going to change to "implications of privileges". So we have: Discretionary access controls on objects (ownership, mode, ACLs) - files, devices, ipc objects, others Authorizations - Anything RBAC Privileges - Override kernel policy >Your one-pager says (section 2.1): > > ... allowing processes with a non-0 effective > uid to still have some of the powers that originally > were root's prerogative ... > >which sure sounds a lot like giving them more powers. No, it's about less power: it's uid 0 vs ordinary user + privileges >> RBACs assigns these additional powers to *users* or *roles*. These >> powers are *application specific* and potentially fine grained. >> The RBAC powers are invoked on purpose by invoking the application >> that uses these authorizations to specifically perform a specific task. > >Why is > system("pfexec /bin/chown jordan:staff /etc/passwd") >intrinsically different from > chown("/etc/passwd", 26718, 10) >? How do you know that chown() isn't implemented using system()? Why >does it matter? A lot. The first one *EXPLICITELY INVOKES* the Autorization. The second one does not and does not check for the authorization, regardless of implementation. (The mkdir authorization would not be implemented in mkdir, but rather through pfexec to prevent unwanted uses of mkdir by tar) I.e., a user may be authorized to do "pfexec chown". but he will normally choose not to use that Authorization. >> The potential number of authorizations is boundless. > >Sure. Isn't the potential number of privileges boundless too? Didn't >somebody say > > Past experience has shown that for any number N, and for > almost any object O, the statement > "we'll never need more than N of O" > is invariably untrue. We're talking about the difference between 64 possibly not being enough a few releases down the road versus "an ISV can ship a tool using thousands of authorizations". There is orders of magnitude difference between the two. >Again, how do you know how chown() is implemented? Starting a new >process may be an implementation detail of implementing a particular API >- an implementation detail that should make no difference. A process is >either allowed to perform a particular action - however it might be >implemented - or it's not. *Why* it's permitted to perform that >operation should not be important to the checking mechanism, and where >the check is implemented should not be important to the mechanism that >the administrator uses to control whether the operation is permitted. You're still not getting the difference between an Authorization and a Privilege. I don't know how I can explain this more clearly. Authorizations are not checked in library or system calls; they are checked by applications. They are part of applications space. >(Yes, granting an authorization could be mapped to granting a >privilege. In many ways that's what I'm suggesting, that privileges >could be completely buried as an implementation detail and the only >thing that administrators would need to be aware of would be >authorizations.) But the implementation detail must show in exec_attr (where euid shows as implementation detail). Assumjing other privileges through authorizations would potentially be possible except for the "limit set" which can't be implemented using authorizations. One of the first design iterations only affected "exec_attr" (i.e., more or less below the RBAC layer). However, many people commented they really wanted to have additional privileges on login, not just through authorizations on programs. >I wouldn't say "completely change"; I would say "extend". I think the >existing semantics of authorizations would be _pretty much_ retained, >but they would gain new semantics. No, they would be changed because you would bind them to processes and not users. That is "completely change" in my book. >The goal would not be "so that they can be implemented like privileges", >but rather so that privileges could be implemented as authorizations, so >that there would not be a new concept created but rather an old concept >extended to cover new ground. No, you're arguing that authorization should become like privileges so privileges can be implemented as authorizations. >Hmm. Interesting. However, I contend that such a mechanism already >exists - if I make an executable setuid to myself, it can execute other >programs and make use of my authorizations and profiles. In fact, all >it'd need to do is to setuid(geteuid()) and exec pfsh. Which is a bug, not a feature (which could be fixed as long as we checked the tools against the unchangable audit id.) >Presumably the answer to this question is to check the relevant *.grant >authorization before allowing a user to set a forced privilege. >Wouldn't you want a similar check on privileges? There are no .grant privileges so the problem doesn't exist in privilege space: the grant is implicit. You want to double the privilege space for this? >Putting the shoe on the other foot, doesn't it seem reasonable to be >able to set Netscape so that it has the "is allowed to print" >authorization, allowing a user not otherwise allowed to print to print >from Netscape? Shouldn't the daemon that receives network print >requests have exactly the "allowed to queue print jobs" authorization, >and nothing more? Do we have to create a new UID for every service that >needs a distinct set of user-level authorizations? No, that doesn't seem reasonable. If you can't print but can print to netscape (the OS inside the OS) you can print; in fact you can run any code of your choosing inside netscape. >Wouldn't it be nice if I could grant my CGI program the ability to print >files as me, or the ability to send mail as me, without granting it the >ability to write my files? It would be nice but that would require all those things to become "privileged" operations. You cannot have authorizations for essentially unprivileged operations. (printing typically requires a privilege to access a device; sending mail or reading files does not require a privilege) >I understand why they might not *want* to, but I don't understand why >they don't *get* to. If I have Object Access Management, I can run all >programs *as if* they have file_chown by writing a shared object that >interposes on chown() and does system("pfexec chown ...") under the >covers. Yes, but that means that you *chose* to do so; having the explicit privilege is very dangerous because of what netscape, tar, cpio and such do. Of course, such protection doesn't help against malicious programs that run everything through pfexec (but the Limit set can prevent pfexec from being executed) but it does help against ordinary programs that just "try" to change ownership and such. Casper From sacadmin Wed Jun 19 11:53:34 2002 Date: Wed, 19 Jun 2002 11:50:46 -0700 From: Jordan Brown X-Accept-Language: en MIME-Version: 1.0 To: Casper Dik CC: psarc@sac.eng.sun.com, least-priv@sun.com Subject: Re: 2002/188 Least privilege Content-Transfer-Encoding: 7bit Status: RO Lines: 4 X-Lines: 4 Content-Type: text/plain; charset="us-ascii" Content-Length: 238 Like I said at the end of my last message, unless I've convinced somebody that this is at least worth discussing, I'm done commenting. If nobody sees my position, then I'm probably on drugs and there's no point in wasting people's time. From sacadmin Thu Jun 20 10:27:41 2002 Date: Thu, 20 Jun 2002 11:24:36 -0600 From: Andy Rudoff X-Accept-Language: en MIME-Version: 1.0 To: Casper Dik CC: Jordan Brown , psarc@sac.eng.sun.com, least-priv@sun.com Subject: Re: 2002/188 Least privilege Content-Transfer-Encoding: 7bit Status: RO Lines: 21 X-Lines: 21 Content-Type: text/plain; charset="us-ascii" Content-Length: 1085 > The filesystem attribute project refused to reserve name space saying > that "NFSv4 requires us to have no reserved name space". They made it > impossible to have "system attributes', much to the chagrin of ours and > other projects. It has caused us heartburn and delay; we will not address > the file attributes as part of this project but would welcome to have > this added as advice to the case. This is not quite correct. It was decided that the current attribute namespace is not carved up, but that is because the attributes folks had a plan for how they will carve out new namespaces in the future. The next phase of attributes, which will not happen correctly without the collaboration of people like Casper, must address this. So even though I also did not quite agree with the lack of a reserved namespace in the attribute project, ultimately the owners of that area have a plan to solve the problem a different way and we should help them get it right. So we can put advice in, as you say Casper, but you must also work with them to help them get it right. -andy From sacadmin Wed Oct 16 11:46:57 2002 Date: Wed, 16 Oct 2002 19:40:58 +0100 From: Calum Mackay User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021011 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Casper Dik CC: Andrew Tucker , Calum Mackay , psarc-record@sac.eng.sun.com Subject: PSARC 2002/188 commitment review Content-Transfer-Encoding: 7bit Status: RO X-Lines: 15 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 396 Hi Casper, how's you? Hope you enjoyed the review today :) Looks like we have a few issues to work through; I will try to coordinate all this so you know what you need to respond to, and all the queries are resolved. For starters: would you please prepare some answers for Gary Winiger's issues (gw-*), and let Gary and I know if you're unclear as to what he's referring? cheers, Calum. From sacadmin Wed Oct 16 11:58:12 2002 Date: Wed, 16 Oct 2002 19:52:09 +0100 From: Calum Mackay User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021011 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Terrence Miller CC: psarc-record@sac.eng.sun.com, Calum Mackay , Andrew Tucker , Casper Dik Subject: 2002/188 tcm-4 backward compatibility of basic priv set Content-Transfer-Encoding: 7bit X-Lines: 10 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 217 Hi Terry, Would you be able to clarify your concern here, so Casper may address it? It seemed to me you were concerned with what happens when a new basic priv is added in a new release of Solaris? cheers, Calum. From sacadmin Wed Oct 16 12:05:20 2002 Date: Wed, 16 Oct 2002 19:59:12 +0100 From: Calum Mackay User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021011 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Glenn Skinner , Andrew Tucker , Casper Dik , Calum Mackay , psarc-record@sac.eng.sun.com Subject: 2002/188 agt-9 compatibility of adding cred to dblk Content-Transfer-Encoding: 7bit X-Lines: 11 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 278 Hi Glenn, You mentioned a concern over how non-network STREAMS driver might react to this change; are you happy with the response to this issue, or do you want to discuss it further here? Andy: are you happy with the response to your original question too? cheers, Calum. From sacadmin Wed Oct 16 12:10:34 2002 Date: Wed, 16 Oct 2002 20:04:25 +0100 From: Calum Mackay User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021011 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Carlson CC: Andrew Tucker , Casper Dik , Calum Mackay , psarc-record@sac.eng.sun.com Subject: 2002/188 jdc-1 Content-Transfer-Encoding: 7bit X-Lines: 12 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 330 Hi Jim, I wanted to continue the discussion you raised re a priv aware application protecting itself from signals in the way that a setuid app is. Were you aware of any specific app that in practice relies upon this assumption? Is this assumption warranted, e.g. a standard? What are we going to break here? cheers, Calum. From sacadmin Wed Oct 16 12:17:52 2002 Date: Wed, 16 Oct 2002 20:11:36 +0100 From: Calum Mackay User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021011 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard McDougall CC: Andrew Tucker , Calum Mackay , Casper Dik , psarc-record@sac.eng.sun.com Subject: 2002/188 rmc-1 EPERM overloading with multiple priv errors Content-Transfer-Encoding: 7bit X-Lines: 10 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 298 Hi Richard, How did you want to leave this one? Are you happy with opinion fodder noting the important of documention in this area, and Casper's updating of all relevant man pages to note that EPERM (or similar) might indicate a priv error, and a pointer to what to read next? cheers, Calum. From sacadmin Wed Oct 16 12:26:24 2002 Date: Wed, 16 Oct 2002 20:20:10 +0100 From: Calum Mackay User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021011 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard McDougall CC: Casper Dik , Andrew Tucker , Calum Mackay , psarc-record@sac.eng.sun.com Subject: 2002/188 rmc issues Content-Transfer-Encoding: 7bit X-Lines: 19 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 411 Richard, Following on from that, I suspect you want some further discussion on some of your other issues, e.g: rmc-2 separate priv for ISM? rmc-3 ship an app that provides output of getprivbynum (or whatever), or add to existing app, e.g. ppriv? rmc-5 truss (or priv debugging in general) rmc-6 integration with project framework Would you like to kick these off/continue here, please? cheers, Calum. From sacadmin Wed Oct 16 12:29:12 2002 To: Calum Mackay cc: Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: PSARC 2002/188 commitment review Date: Wed, 16 Oct 2002 21:25:04 +0200 From: Casper Dik Content-Length: 15284 X-Lines: 408 Status: RO >Hi Casper, how's you? > >Hope you enjoyed the review today :) > >Looks like we have a few issues to work through; I will try to >coordinate all this so you know what you need to respond to, and all the >queries are resolved. > >For starters: would you please prepare some answers for Gary Winiger's >issues (gw-*), and let Gary and I know if you're unclear as to what he's >referring? This is the short form of replies to issues in mostly as notes I did before the meeting. PSARC 2002/188 Privileges for Solaris Commitment review 16 October 2002 tcm-4 I'm still confused about how the set of privileges can evolve. Is the Basic Priv scheme equivalent to haveing priviledges entitled Permits all the actions not covered by any other priviledge as of version N permanently for all N where any program is entitled to the one for the version it was built against No - new functionality may introduce new priivleges which process will not have unless they require all privileges. Basic privileges allow changing current unprivileged operations to require a basic privilege. agt-7 If one of the goals is to allow deployment of realtime applications without PRIV_SYS_CONFIG, you should add a separate privilege for the p_online functionality (or add it to PRIV_SYS_PSET; this is commonly used to block interrupts to selected CPUs. Noted. agt-8 3.5: I'm not sure I understand the requirement of full privileges for controlling or modifying uid 0 things. Why is this necessary if the controlling process is euid 0, and the controlled process has a limit set that is a subset of that of the controlling process? If a process has euid 0 it can modify any configuration file, include /etc/passwd, /etc/shadow, /etc/user_attr agt-9 4.3: What are the compatibility and performance implications of the dblk_t change? Sounds like at least the behavior of socket and bind may change. Performance implications: the project is currently undergoing Perfpit tests Compatibility changes: the credential at bind time is now in force. This fixes a security hole; the credential at socket time is now ignored. This gives the original 4.x BSD socket behaviour. Changes in dblk type: the dblk is opaque; we're not touching the public fields. agt-10 4.11: I assume the 660 permissions on /dev/ip are there for a reason, do we know the implications of taking away access for group sys? Who is currently taking advantage of this? "netstat" is taking advantage of this. I believe group sys access to /dev/ip is a security hole. agt-11 Any other potentially incompatible changes to device permissions planned? The permissions of a number of mode 600 devices is relaxed to mode 666 in order to properly support privileges for networking. agt-12 I'm not clear on the purpose of extra_privs(4). It allows the allocation of extra privileges in the order specified; it may be a requirement for some that privileges be equally numbered between two systems, e.g., in single system nodes. agt-13 The answer to gw-9 (inception) talks about allowing customers to define privileges, but I don't see any interfaces for supporting that. Did I miss them? extra_privs; priv_getbyname(..., PRIV_ALLOC) [inside the kernel] agt-14 Why make the format of device_policy public? If the *_drv utilities should be used for updates, why allow "vi" access as well? agt-15 I don't understand the purpose of the -I flag to devpolicy(1M). Is this just to push the file into the kernel on boot? (If so, see agt-16.) Yes. agt-16 Why isn't the device_policy file managed by devfsadm, like other device configuration files? We studied the implications of using devfsadm; devfsadm does implement minor_perm on a reconfiguration boot; it then stores the file permissions in the underlying persistent filesystem. There is no room for such privileges in the persistent filesystem, so devfsadm would need to scan the entire device tree on boot in order to assign privileges; this, unfortunately, causes all device drivers to be loaded. It appears, though, that the current hooks in the system could be called by defsadm -I at boot. WIll investigate. agt-17 The -p option to add_drv should take multiple comma-separated policies (like -m) since a single driver can have multiple policies. The policies are white space separated as in "example 1" in add_drv(1m). The parser can tell "foo=bar" and "minorname" apart so it can find where tokens end and a new minor name starts a new policy. Other tokens where considered but most are valid in device names or privilege set specifications. jdc-1 What happens with kill(2)? One of the hidden assumptions of a setuid program is that no ordinary user can send it a signal. A process that has instead some acquired privileges seems to lack that protection. I see a privilege to control someone sending a signal, but how do I (as the person converting a setuid root application to a PA application) prevent reception from an untrusted user? The restriction on sending signals are not as strict as those on modifying processes; set-uid processes have some protection but as long as they run on a terminal they can be killed. jdc-2 Nit: using 'void' for ucred_t disables some lint checks; suggest blind structure tag instead ('struct ucred_s; typedef struct ucred_s ucred_t;'). Or even a typedef that is itself a pointer so that you have 'uid_t ucred_geteuid(ucred_t);'. (The latter, I think, encourages good developer hygiene.) But it's a *pointer* to a ucred, so I think it ought to be a pointer type lest people think they can allocate one on the stack and copy it that way. jdc-3 Nit: (response to inception gw-27) 'Evolving' implies 'Public'. jdc-4 Nit: 4.4: private details aren't Unstable unless we're telling customers about them, so secpolicy* is (possibly) Consolidation Private for now. (And should be in the tables.) It is consolidation private. jdc-5 6.2: Type of 'Private' for priv_impl.h (and others)? Consolidation or Project? Project private. rmc-1 Rationale for overloading EPERM at the expense of delivering cryptic error messages to end users. Is there a compatible way to extend the error namespace or deliver more meaningful errors via perror()? No; error numbers and messages are defined in the standard. We cannot change error returns; nor can we enhance perror(); while people know how to preserve errno before calling perror; the privilege error state is not magically copied with errno. rmc-2 Are we adding an ISM privilege? Since this is equivalent to an uncontrolled mlock(), we could conceivably add another privilege or enhance ISM to use PRIV_PROC_LOCK_MEMORY. THat would be a separate bug fix and would need to be a basic privilege in order to prevent braaking Oracle and such. rmc-3 Should ppriv allow the system administrator to list the full set of privilege options that can be applied to a process? ppriv -l rmc-4 How can I write an administration application that is aware of the privilege options that can be applied, and is able to adopt and expanded set without recompiling the application? I don't set how the namespace is dynamically discoverable... See the example in priv_names(3c) rmc-5 The truss command will be the first place an administrator is likely to go to debug a privilege issue. Can we enhance truss to understand and print privilege debugging information at the time of a system call? Privilege manipulations will likely deny truss further control of the process; generally truss can be used to determine EACCES/EPERM messages; the privilege debugging output will be in lockstep with the system call return. Non-system administrator would be able to use privilege debugging; they cannot use truss to debug privilege use. gw-1 It still seems to me that processes with privilege should be restricted to the "secure" libraries. I don't see that this proposal does so. What am I missing? The question is best answered with a question: Is root restricted to using secure libraries? The restriction is enforced when there's a transition of privilege level from low to high; when no transition takes place, programs are at liberty to load libraries. gw-2 Missed the point of boot, inetd, allocate, cron rights profiles. Noted for a future implementation. gw-3 prochasprocperm is not documented. Maybe it should be in ddi_cred(9). Neither are any of the other kernel private functions. gw-4 How will programmers know to use sec_policy* or add new ones? How will they know to use privileges in apps? For now, these are project private interfaces. They know which privileges applications need by studying manual pages where these will be documented. gw-5 3.1 Page 15 last paragraph, is there a difference between basic and default privileges? The default privilege can include file_chown_self; basic does not include file_chown_self gw-6 forced privilege emulation? What's the proposal? Set-uid root. None other. gw-7 How does a process become pa in the presence of inheritable privs (page 18)? What are those privileges? Left over from previous version. It does not become PA. gw-8 3.3.3 last para (-1). Note with allowed privs the idea is to pass privs around non priv apps from grandparent to grandchild across a parent which cannot use any privs. How will this restriction work in that light? The process that cannot use privileges will not be able to set LD_* variables that affect the child process that runs with more privileges. gw-9 States: the prototype's privileges are listed in privileges(5). What are the proposed privileges? Are they the same as the prototype? Yes. gw-10 Taxonomy of /etc/system variables. "Evolving" gw-11 Seems hard to have daemons run as user daemon if they will support diskless. How will it be determined which daemons can run without uid == 0? (3.5 and 3.8) There is no difference between diskless and ordinary operation execpt when the user runs as a non uid 0 uid *and* requires any of the file* privileges. gw-12 Will QFS be supported? QFS will work but likely use uid 0; it should be converted to use the new interfaces. gw-13 What does it mean for sys_config to be evolving ans sys_suser_compat to be obsolete? Where is this noted in the public taxonomy? The only reason why sys_suser_compat is obsolete is that the suser() function is obsolete as noted in the drv_priv() manual page. The privilege is self is stable but will gain less use over time. gw-14 user_attr(4) can suser and solaris co-exist? When is one selected over the other? The upgrade profile converts one to the other; the solaris entry will be preferred on upgrade if one exists; if not, the existing entry will be renamed to "solaris" They do not coexist. gw-15 Will the UIs enforce defaultpriv <= limitpriv; maxpriv <= limitpriv? Yes. gw-16 How will it be made safe for programs like su, dtsession if the user has a reduced limit set. It seems I could lockscreen and never be able to get out of lockscreen. I'm very concerned that limitpriv will be a call generator. The use of limitpriv is documented as possibly having unintended side effects; gw-17 I'd prefer device_policy(4) be project private. There are CLIs to administer it. It is classified as unstable. Why even expose it as an administrative interface? It's intended to be project private; the documentation is provided to allow guarding against file corruption. gw-18 Why is extra_privs(4) needed? It seems to me that when device_policy gets loaded into the kernel, new privileges listed there could be defined. To guard against typos; to allow coordinated loading of privileges before device drivers are loaded. gw-19 I don't understand file_setdac relative to file_setid. Just changing the file permissions is of a different order than allowing the creation of set-uid executables. Why does TS have both, then? gw-20 proc_set_id seems to be missing: Allows a process to set the process group of a controlling terminal to one not in the process' process group. Allows a process to set the window size on a terminal not in its session. How are these controlled? These always return EPERM, even for privileged processes in Solaris; there doesn't appear to be a reason to change this. gw-21 sys_devices seems incomplete: Allows a process to create device special files. Allows a process to use mknod(2) to create directory and regular files. Allows a process to revoke all access to a device special file. Allows a process to reassign a controlling terminal from one process to another. Allows a process to open a terminal already exclusively opened. Allows a process to revoke access to its controlling terminal. Allows a process to enable or disable keyboard abort processing. Allows a process to map frame buffer devices into its address space. Allows a process to enable or disable a disk's write-check capability. Allows a process to load a kernel loadable driver. Allows a process to control the Floating Point Accelerator. Allows a process to configure autopush STREAMS modules. Allows a process to configure the device driver policy table. Allows a process to successfully call a third party loadable module that calls DDI drv_priv. Some of these are sys_config (abort enabling/disabling does not feel at hoem under devices) Configuring the device driver policy table requires all privileges. I don't think we still have supported floating point accelerators; there are no restrictions on mapping framebuffers as there are no such restrictions in Solaris proper gw-22 sys_fs_config, sys_max_proc, sys_min_free seem to be missing. How are their functions restricted. These function do not appear to warrant their own privileges so they're lumped in with other privileges, msotly sys_resources and sys_config. gw-23 sys_mount seems incomplete: Allows a process to determine the users of a filesystem. It does not give such access. gw-24 sys_net_config and sys_nfs seem incomplete: Name sys_net_config Allows a process to configure a machine's network interfaces and routes. Allows a process to set a machine's host and domain names. Allows a process to set a machine's kerberos realm. Allows a process to load and unload host type, accreditation, and default information. Allows a process direct access to network devices. Allows a process to set endpoint names. Allows a process to use the rpcmod STREAMS module. Because part of those exist only in trusted and some are under "sys_config"; also missing is the popping of STREAMS anchors. Name sys_nfs Allows a process to start a kernel NFS daemon. Allows a process to start and stop a kernel NFS lock manager daemon. Allows a process to export directories for use by NFS clients. Allows a process to retrieve the NFS file handle for a path name. Allows a process to revoke NFS RPC credentials for a client it does not own. Noted. From sacadmin Wed Oct 16 12:30:59 2002 Date: Wed, 16 Oct 2002 20:24:41 +0100 From: Calum Mackay User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021011 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Glenn Skinner CC: Richard McDougall , psarc-record@sac.eng.sun.com, Casper Dik , Andrew Tucker , Calum Mackay Subject: 2002/188 refinement of currently listed privs Content-Transfer-Encoding: 7bit X-Lines: 12 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 296 Glenn, Did I hear you comment - during discussion of rmc-2 (separate priv for ISM) that you thought the current priv listing perhaps needed some refinement? Do you want to take that further here? It is perhaps something that should be sorted out sooner rather than later :) cheers, Calum. From sacadmin Wed Oct 16 12:35:25 2002 To: Calum Mackay cc: James Carlson , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: 2002/188 jdc-1 Date: Wed, 16 Oct 2002 21:31:17 +0200 From: Casper Dik Content-Length: 859 X-Lines: 35 Status: RO >Hi Jim, > >I wanted to continue the discussion you raised re a priv aware >application protecting itself from signals in the way that a setuid app is. > >Were you aware of any specific app that in practice relies upon this >assumption? Is this assumption warranted, e.g. a standard? What are we >going to break here? The protection of set-uid applications against signals is possibly less than Jim thinks it is: ksh $ su Password: [1] + Stopped (SIGTSTP) su $ kill -9 %1 [1] + Killed su $ I can kill any process as long as: my effective or real uid matches the target's real uid my effective or real uid matches the target's saved uid I.e., a process that wants signalprotection needs to do: setreuid(geteuid(), geteuid()) (setuid(geteuid()) only works for root). That generally leads to many more problems. Casper From sacadmin Wed Oct 16 12:35:43 2002 Date: Wed, 16 Oct 2002 20:29:19 +0100 From: Calum Mackay User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021011 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary Winiger CC: psarc-record@sac.eng.sun.com, Casper Dik , Andrew Tucker , Calum Mackay Subject: 2002/188 gw-1 PA programs restricted to secure libs Content-Transfer-Encoding: 7bit X-Lines: 11 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 257 Gary, Would you like further discussion on this issue? Casper seems to feel it has been answered several times already, but I take it you don't agree (or are unhappy with the answer) otherwise you wouldn't have raised it at commitment. cheers, Calum. From sacadmin Wed Oct 16 12:39:24 2002 To: Calum Mackay cc: Glenn Skinner , Richard McDougall , psarc-record@sac.eng.sun.com, Andrew Tucker Subject: Re: 2002/188 refinement of currently listed privs Date: Wed, 16 Oct 2002 21:35:14 +0200 From: Casper Dik Content-Length: 884 X-Lines: 30 Status: RO >Glenn, > >Did I hear you comment - during discussion of rmc-2 (separate priv for >ISM) that you thought the current priv listing perhaps needed some >refinement? > >Do you want to take that further here? It is perhaps something that >should be sorted out sooner rather than later :) Refining privileges is not that much of an issue, I think, some can be postponed to latter, even in a compatible way. A lot is lumped in with sys_config but if anything needs to be split of we can chaneg the code in a ocmpatible way: if (have sys_config or new_subpriv) allow thingemabobs. Before a customer release we don't need to bother with "have sys_config". I don't believe that too many privileges are good; that's why I removed a bunch of th etrusted Solaris privileges such as the ufs specific "do filesystem global ioctls" and "use superuser reserved bits on disk". Casper From sacadmin Wed Oct 16 12:45:39 2002 Date: Wed, 16 Oct 2002 20:39:18 +0100 From: Calum Mackay User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021011 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Calum Mackay CC: Terrence Miller , psarc-record@sac.eng.sun.com, Andrew Tucker , Casper Dik Subject: Re: 2002/188 tcm-4 backward compatibility of basic priv set Content-Transfer-Encoding: 7bit X-Lines: 20 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 514 Calum Mackay wrote: > Hi Terry, > > Would you be able to clarify your concern here, so Casper may address it? > > It seemed to me you were concerned with what happens when a new basic > priv is added in a new release of Solaris? Note that Casper has already replied (in separate email): No - new functionality may introduce new priivleges which process will not have unless they require all privileges. Basic privileges allow changing current unprivileged operations to require a basic privilege. cheers, c. From sacadmin Wed Oct 16 12:49:23 2002 Date: Wed, 16 Oct 2002 20:43:03 +0100 From: Calum Mackay User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021011 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Calum Mackay CC: Richard McDougall , Casper Dik , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: 2002/188 rmc issues Content-Transfer-Encoding: 7bit X-Lines: 30 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 751 Note that Casper has already replied to some of these: Calum Mackay wrote: > rmc-2 separate priv for ISM? THat would be a separate bug fix and would need to be a basic privilege in order to prevent braaking Oracle and such. > rmc-3 ship an app that provides output of getprivbynum (or whatever), or > add to existing app, e.g. ppriv? ppriv -l > > > rmc-5 truss (or priv debugging in general) Privilege manipulations will likely deny truss further control of the process; generally truss can be used to determine EACCES/EPERM messages; the privilege debugging output will be in lockstep with the system call return. Non-system administrator would be able to use privilege debugging; they cannot use truss to debug privilege use. cheers, c. From sacadmin Wed Oct 16 12:50:31 2002 Date: Wed, 16 Oct 2002 20:44:10 +0100 From: Calum Mackay User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021011 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Calum Mackay CC: Gary Winiger , psarc-record@sac.eng.sun.com, Casper Dik , Andrew Tucker Subject: Re: 2002/188 gw-1 PA programs restricted to secure libs Content-Transfer-Encoding: 7bit X-Lines: 21 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 399 Calum Mackay wrote: > Gary, > > Would you like further discussion on this issue? Note that Casper has already replied: The question is best answered with a question: Is root restricted to using secure libraries? The restriction is enforced when there's a transition of privilege level from low to high; when no transition takes place, programs are at liberty to load libraries. cheers, c. From sacadmin Wed Oct 16 13:56:34 2002 Date: Wed, 16 Oct 2002 13:52:26 -0700 (PDT) From: Terrence Miller Subject: Re: 2002/188 tcm-4 backward compatibility of basic priv set To: Terrence.Miller@sun.com, calum.mackay@sun.com Cc: psarc-record@sac.eng.sun.com, calum.mackay@sun.com, Andrew.Tucker@sun.com, casper.dik@sun.com MIME-Version: 1.0 Content-MD5: x9JAXST/fqZpnL11rgf8Sw== X-Lines: 39 Status: RO Content-Type: TEXT/plain; charset="us-ascii" Content-Length: 1317 > Date: Wed, 16 Oct 2002 19:52:09 +0100 > From: Calum Mackay > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021011 > X-Accept-Language: en-us, en > MIME-Version: 1.0 > To: Terrence Miller > CC: psarc-record@sac.Eng.Sun.COM, Calum Mackay , Andrew Tucker , Casper Dik > Subject: 2002/188 tcm-4 backward compatibility of basic priv set > Content-Transfer-Encoding: 7bit > > Hi Terry, > > Would you be able to clarify your concern here, so Casper may address it? > > It seemed to me you were concerned with what happens when a new basic > priv is added in a new release of Solaris? > > cheers, > Calum. > The scenario I am confused about is: 1) the code for a daemon which will run in PA mode performs an action X. 2) the daemon is compiled on Solaris N on which X requires no privilege 3) it works 4) Solaris N+1 defines a new privilege - PRIV_X that controls action X 5) despite 4) the binary from 2) works on the new OS 6) the daemon is recompiled on Solaris N+1 with no source changes 7) now attempting action X fails - EPERM 8) the programmer can easily discover what new privilege is required where PRIV_X could either be a Basic priv or not. Terrence From sacadmin Wed Oct 16 14:08:00 2002 Date: Wed, 16 Oct 2002 22:01:16 +0100 From: Calum Mackay User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021011 X-Accept-Language: en-us, en MIME-Version: 1.0 To: calum.mackay@sun.com, Glenn Skinner , Casper Dik , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: 2002/188 gcs issues on board Content-Transfer-Encoding: 7bit X-Lines: 67 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 1857 Glenn, Here's Casper's responses to your issues from the board. cheers, c. >gcs-1. froced priv via setgid - used in initial delivery No; the project team felt in unwise to allocate a large chunk of gid space for this purpose. >gcs-2. NOCD: explain NOCD is a flag set in the kernel that used to indicate "No coredumps" but was soon expanded to be some sort of generic "poison process" flag. Initially, process would happily dump core if all their uids/gids were equal. And you could control them if you had a matching uid set. This didn't cater for processes that changed uids; e.g., they may have privileged connections or raw sockets and otehr capabilities; or they could have cached parts of /etc/shadow. So it was decided to flag processes that were ever more privileged or just differently privileged as being "slightly privileged". The NOCD flag gets set in various circumstances: - uids/gids change - set-uid execution - execution with euid != uid or egid != gid and now also: - clearing privileges from the Permitted set. (i.e., irrevocably lowering privileges) NOCD processes can be killed but not truss'ed and won't dump core. >gcs-3. sysconf for priv.config ?? the priv.conf is not a separate system call; it's a sub call of "privsys". which implement all the privilege system calls except the driver related ones which are implemetned through modctl(). >gcs-4. nit: (p28) taxonnomy for cred_t The question is? > >gcs-5. dblk change: ramificatins beyond sockets Parts that illicitely reference privat parts of dblk will have trouble getting the db_uid which no longer exists. >gcs-6. NIT: priv_debug in i/F table (/etc/system) [Casper: is the question not clear? Glenn: are you just saying it's missing? cdm] >gcs-7. NIT: devpolicy in /sbin Needs to be in /sbin or we can't run it early enough in boot. From sacadmin Wed Oct 16 14:10:59 2002 Date: Wed, 16 Oct 2002 22:04:13 +0100 From: Calum Mackay User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021011 X-Accept-Language: en-us, en MIME-Version: 1.0 To: calum.mackay@sun.com, Richard McDougall , Casper Dik , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: 2002/188 rmc-6 integration with Project framework Content-Transfer-Encoding: 7bit X-Lines: 17 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 461 Richard, here's Casper's response to your rmc-6. cheers, c. Unfotunately, projects are not well integrated with the Solaris authentication framework; before that issue is addressed open bugs on PAM abuse by projects need to be fixed. But this appears to be pending on some further PAM work as well. It certainly seems logical to assign certain to projects and we will be happy to implement an RFE to that effect after the PAM issues have been addressed. From sacadmin Wed Oct 16 14:15:16 2002 Date: Wed, 16 Oct 2002 22:08:28 +0100 From: Calum Mackay User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021011 X-Accept-Language: en-us, en MIME-Version: 1.0 To: calum.mackay@sun.com, Gary Winiger , Casper Dik , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: 2002/188 gw-25 & gw-26 Content-Transfer-Encoding: 7bit X-Lines: 27 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 787 Gary, Here are Casper's responses to your gw-25 & gw-26. cheers, c. >gw-25. to add privs must recompile To add privileges to the standard ON set you must recompile, correct. To grow privilege sets you must also recompile the kernel. The project team does not see an issue with this. >gw-26. userland prive_getbyname() There is a private interface that allows allocation of privileges using modctl; we do not Intend to expose this interface other than through the driver framework. Privileges are not intended for allocating and checking in applications; conveying what privileges applications have through ucred is solely intended to allow daemons to make informed decisions on what privileges their clients have so they can use the appriopriate privileges on their behalf. From sacadmin Wed Oct 16 17:38:03 2002 Date: Wed, 16 Oct 2002 17:33:54 -0700 (PDT) From: Glenn Skinner Subject: Re: 2002/188 gcs issues on board To: calum.mackay@sun.com, casper.dik@sun.com, Andrew.Tucker@sun.com, psarc-record@sac.eng.sun.com MIME-Version: 1.0 Content-MD5: MazgEbS1Dya9Uj5dNwsUdA== X-Lines: 51 Status: RO Content-Type: TEXT/plain; charset="us-ascii" Content-Length: 1924 Date: Wed, 16 Oct 2002 22:01:16 +0100 From: Calum Mackay Subject: 2002/188 gcs issues on board Here's Casper's responses to your issues from the board. I've elided items that I don't think need further discussion, -- Glenn >gcs-3. sysconf for priv.config ?? the priv.conf is not a separate system call; it's a sub call of "privsys". which implement all the privilege system calls except the driver related ones which are implemetned through modctl(). I don't really care whether there's a single syscall with n sub-calls, or n syscalls. What I'm actually concerned about is whether the privilege configuration information can reasonably be regarded as part of the overall system configuration. If so, and I'm inclined to think so, then we ought to consider exposing that information via sysconf(). >gcs-4. nit: (p28) taxonnomy for cred_t The question is? I think the discussion on page 28 about cred_t's classification in the interface taxonomy is overly simplistic. I certainly agree that the layout and size of a cred_t instance ought to be Consolidation Private. But their existence (and the ability to pass references to them, hold and release them, and so on) needs to have a higher classification. As I said, just a nit. >gcs-5. dblk change: ramificatins beyond sockets Parts that illicitely reference privat parts of dblk will have trouble getting the db_uid which no longer exists. Ok, I've looked at how the existing field is used and am now satisfied that replacing it with a cred pointer won't be problematic. >gcs-6. NIT: priv_debug in i/F table (/etc/system) [Casper: is the question not clear? Glenn: are you just saying it's missing? cdm] The i/f table is voluminous enough that I might have missed an entry for the priv_debug /etc/system variable. But I looked for it and didn't find it. From sacadmin Wed Oct 16 18:09:20 2002 Date: Wed, 16 Oct 2002 18:06:00 -0700 From: Richard McDougall User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Calum Mackay CC: Richard McDougall , Casper Dik , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: (PSARC) 2002/188 rmc issues Content-Transfer-Encoding: 7bit X-Lines: 45 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 1420 Calum Mackay wrote: > Richard, > > Following on from that, I suspect you want some further discussion on > some of your other issues, e.g: > > rmc-2 separate priv for ISM? We are phasing out ISM for Oracle in the future - DISM or it's derrivitives will be used in place, using mlock(). However, ISM currently limits the amount of locking using the shmmax parameter. For completeness, it would be ideal to allow ISM to optionally check PROC_MEMORY_LOCK via some switch, so that a user can safely open up shmmax to unlimited and only allow Oracle to shmat. > > rmc-3 ship an app that provides output of getprivbynum (or whatever), or > add to existing app, e.g. ppriv? I think we settled on having ppriv provide the list of settable privileges. In addition, the committee asked for a mechanism to display a meaningful summary for each privilege token. > > rmc-5 truss (or priv debugging in general) > Wouldn't this still be useful for using truss on non-privileged apps that are making use of systems calls that they are allowed to now operate on - for example, if I allow my app to call mlock(), I would want to be able to truss to see if mlock() was returning EPERM, and then why... > rmc-6 integration with project framework > We use projects to assign resource management defaults to a workload, would it be feasible to extend projects to allow per-project privileges? Thanks, Richard. From sacadmin Thu Oct 17 02:18:33 2002 To: Terrence Miller cc: calum.mackay@sun.com, psarc-record@sac.eng.sun.com, Andrew.Tucker@sun.com Subject: Re: 2002/188 tcm-4 backward compatibility of basic priv set Mime-Version: 1.0 Date: Thu, 17 Oct 2002 11:14:21 +0200 From: Casper Dik X-Lines: 37 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 1146 >The scenario I am confused about is: > > 1) the code for a daemon which will run in PA mode performs an action X. > 2) the daemon is compiled on Solaris N on which X requires no privilege > 3) it works > 4) Solaris N+1 defines a new privilege - PRIV_X that controls action X > 5) despite 4) the binary from 2) works on the new OS > 6) the daemon is recompiled on Solaris N+1 with no source changes > 7) now attempting action X fails - EPERM > 8) the programmer can easily discover what new privilege is required > >where PRIV_X could either be a Basic priv or not. If "X" is not privileged in Solaris N then "PRIV_X" *must* be a basic privilege in Solaris N+1. 5) and 6) are in contradiction; whether the source is compiled in Solaris N or N+1 will not matter; the same binary will result. A daemon that is written in Solaris N will need to specify that it needs: basic + - In Solaris N, this will evaluate to not include PRIV_X because PRIV_X is unknown; in Solaris N+1 this will evaluate to include PRIV_X. The solution is both source and binary compatible. Casper From sacadmin Thu Oct 17 03:02:57 2002 To: Glenn Skinner cc: calum.mackay@sun.com, Andrew.Tucker@sun.com, psarc-record@sac.eng.sun.com Subject: Re: 2002/188 gcs issues on board Mime-Version: 1.0 Date: Thu, 17 Oct 2002 11:58:46 +0200 From: Casper Dik X-Lines: 52 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 1659 > >I don't really care whether there's a single syscall with n sub-calls, >or n syscalls. What I'm actually concerned about is whether the >privilege configuration information can reasonably be regarded as part >of the overall system configuration. If so, and I'm inclined to think >so, then we ought to consider exposing that information via sysconf(). #include long sysconf(int name); I don't quite see how I can shoehorn the privilege configuration information into a sysconf() return value. > >gcs-4. nit: (p28) taxonnomy for cred_t > > The question is? > >I think the discussion on page 28 about cred_t's classification in the >interface taxonomy is overly simplistic. I certainly agree that the >layout and size of a cred_t instance ought to be Consolidation Private. >But their existence (and the ability to pass references to them, hold >and release them, and so on) needs to have a higher classification. As >I said, just a nit. > > >gcs-5. dblk change: ramificatins beyond sockets > > Parts that illicitely reference privat parts of dblk will have trouble > getting the db_uid which no longer exists. > >Ok, I've looked at how the existing field is used and am now satisfied >that replacing it with a cred pointer won't be problematic. Thanks. > >gcs-6. NIT: priv_debug in i/F table (/etc/system) > > [Casper: is the question not clear? Glenn: are you just saying it's > missing? cdm] > >The i/f table is voluminous enough that I might have missed an entry >for the priv_debug /etc/system variable. But I looked for it and >didn't find it. it is missing; what to put there? Casper From sacadmin Thu Oct 17 06:29:10 2002 To: Calum Mackay , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: PSARC 2002/188 commitment review Date: Thu, 17 Oct 2002 15:25:01 +0200 From: Casper Dik Content-Length: 3331 X-Lines: 83 Status: RO >gw-20 proc_set_id seems to be missing: Allows a process to set the > process group of a controlling terminal to one not in the process' > process group. Allows a process to set the window size on a terminal > not in its session. > How are these controlled? > >These always return EPERM, even for privileged processes in Solaris; >there doesn't appear to be a reason to change this. The right answer is: You are quoting the Trusted Solaris privilege specification. What you have actually found is a bug in the Trusted Solaris implentation; the above description of the proc_setid privilege DOES NOT MATCH the Trusted Solaris 8 FCS implementation. The specification as included in the PSARC 2002/188 commitment materials reflects both the actual Trusted Solaris and the PSARC 2002/188 implementation. >gw-21 sys_devices seems incomplete: > Allows a process to create device special files. > Allows a process to use mknod(2) to create directory > and regular files. Allows a process to revoke all > access to a device special file. Allows a process to > reassign a controlling terminal from one process to > another. Allows a process to open a terminal already > exclusively opened. Allows a process to revoke access > to its controlling terminal. Allows a process to > enable or disable keyboard abort processing. Allows a > process to map frame buffer devices into its address > space. Allows a process to enable or disable a disk's > write-check capability. Allows a process to load a > kernel loadable driver. Allows a process to control > the Floating Point Accelerator. Allows a process to > configure autopush STREAMS modules. Allows a process > to configure the device driver policy table. Allows a > process to successfully call a third party loadable > module that calls DDI drv_priv. > >Some of these are sys_config (abort enabling/disabling does not >feel at hoem under devices) > >Configuring the device driver policy table requires all privileges. > >I don't think we still have supported floating point accelerators; >there are no restrictions on mapping framebuffers as there are no >such restrictions in Solaris proper Again this is a quote fromt the Trusted Solaris privilege spec; the "incompleteness" refers mostly to bugs in the TS specification and differences between the Solaris and TS implementation. >gw-23 sys_mount seems incomplete: Allows a process to determine the > users of a filesystem. > >It does not give such access. I.e., it is different from Trusted Solaris. > Name sys_nfs > > Allows a process to start a kernel NFS daemon. Allows > a process to start and stop a kernel NFS lock manager > daemon. Allows a process to export directories for use > by NFS clients. Allows a process to retrieve the NFS > file handle for a path name. Allows a process to > revoke NFS RPC credentials for a client it does not > own. But please note that these are privileges that are for *Consolidation private* interfaces. Should we document them to the extend that we list which privileges are needed? I think the description should be changed to: Allows a process to perform Sun private NFS specific system calls. and not mention anything else. Casper From sacadmin Thu Oct 17 10:57:38 2002 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Thu, 17 Oct 2002 13:53:17 -0400 From: James Carlson To: Casper Dik Cc: Calum Mackay , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: 2002/188 jdc-1 X-Lines: 29 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 1199 Casper Dik writes: > ksh > $ su > Password: [1] + Stopped (SIGTSTP) su > $ kill -9 %1 > [1] + Killed su I knew about that. > (setuid(geteuid()) only works for root). That's the case I was worried about. A set-uid root process can become independent of the invoker's signals by doing 'setuid(0);'. If I want to minimize this program down to the least privilege necessary to run (no more set-uid root required), I may find that I can't quite do that, or that I accidentally open new holes in doing so. I have to set-uid to somebody else, use setreuid, and I lose access to the things the invoker had access to (e.g., files) in the process. Perhaps it's just something for a future RFE. The case seems very rich and well thought-out to me and I was just a little surprised that the signal delivery didn't have the same level of control on it. But only surprised -- I was more interested to hear the response, and I wouldn't ask for any TC[AR]. -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Thu Oct 17 11:39:42 2002 Date: Thu, 17 Oct 2002 11:35:29 -0700 (PDT) From: Terrence Miller Subject: Re: 2002/188 tcm-4 backward compatibility of basic priv set To: Terrence.Miller@sun.com, Casper.Dik@sun.com Cc: calum.mackay@sun.com, psarc-record@sac.eng.sun.com, Andrew.Tucker@sun.com MIME-Version: 1.0 Content-MD5: ev/XHw1YSn7rcE754QPg7w== X-Lines: 54 Status: RO Content-Type: TEXT/plain; charset="us-ascii" Content-Length: 1862 ... See comments at end .... > To: Terrence Miller > cc: calum.mackay@sun.com, psarc-record@sac.Eng.Sun.COM, Andrew.Tucker@sun.com > Subject: Re: 2002/188 tcm-4 backward compatibility of basic priv set > Mime-Version: 1.0 > Date: Thu, 17 Oct 2002 11:14:21 +0200 > From: Casper Dik > > > >The scenario I am confused about is: > > > > 1) the code for a daemon which will run in PA mode performs an action X. > > 2) the daemon is compiled on Solaris N on which X requires no privilege > > 3) it works > > 4) Solaris N+1 defines a new privilege - PRIV_X that controls action X > > 5) despite 4) the binary from 2) works on the new OS > > 6) the daemon is recompiled on Solaris N+1 with no source changes > > 7) now attempting action X fails - EPERM > > 8) the programmer can easily discover what new privilege is required > > > >where PRIV_X could either be a Basic priv or not. > > > If "X" is not privileged in Solaris N then "PRIV_X" *must* be a basic privilege > in Solaris N+1. > > 5) and 6) are in contradiction; whether the source is compiled in Solaris N > or N+1 will not matter; the same binary will result. > > > A daemon that is written in Solaris N will need to specify that it needs: > > > > basic + - need> > > > In Solaris N, this will evaluate to not include PRIV_X because PRIV_X is > unknown; in Solaris N+1 this will evaluate to include PRIV_X. > > The solution is both source and binary compatible. > > Casper O.K. now I understand the design. However, is source compatability always what you want when security fixes are involved. Don't you want the developer of the daemon to be forced to think about PRIV_X when they produce a new version of the binary? (Binary compatibility is, of course, sacred.) Terrence From sacadmin Thu Oct 17 11:51:46 2002 To: James Carlson cc: Calum Mackay , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: 2002/188 jdc-1 Date: Thu, 17 Oct 2002 20:47:29 +0200 From: Casper Dik Content-Length: 2706 X-Lines: 75 Status: RO >That's the case I was worried about. A set-uid root process can >become independent of the invoker's signals by doing 'setuid(0);'. If >I want to minimize this program down to the least privilege necessary >to run (no more set-uid root required), I may find that I can't quite >do that, or that I accidentally open new holes in doing so. I have to >set-uid to somebody else, use setreuid, and I lose access to the >things the invoker had access to (e.g., files) in the process. Please note that our programming rules about set-uid programs are very explicit about setuid(0); IT IS NOT ALLOWED. (That's because making euid == ruid == 0 disables the world in security checks; programs that did this were a main cause of serious security problems, notably ff.core) >Perhaps it's just something for a future RFE. The case seems very >rich and well thought-out to me and I was just a little surprised that >the signal delivery didn't have the same level of control on it. But >only surprised -- I was more interested to hear the response, and I >wouldn't ask for any TC[AR]. There is actually one mechanism; it's the basic privilege {proc_session}. The {proc_session} privilege is required to kill processes outside your session; now in your particular case this doesn't help. But in generic privilege Solaris we have the following processes as daemon: 310: /usr/sbin/rpcbind flags = 0x2 E: net_privaddr,proc_fork,sys_nfs I: none P: net_privaddr,proc_fork,sys_nfs L: none 360: /usr/lib/nfs/statd flags = 0x2 E: proc_fork I: none P: proc_fork L: none 361: /usr/lib/nfs/lockd flags = 0x2 E: sys_nfs I: none P: sys_nfs L: none 573: /usr/lib/nfs/nfsd flags = 0x2 E: file_link_any,sys_nfs I: none P: file_link_any,sys_nfs L: none None of these processes have the "proc_session" privilege; that means that when I hack statd/lockd/rpcbind/nfsd I *cannot* kill or otherwise influence the other processes. #id -a uid=1(daemon) gid=1(other) groups=1(other),12(daemon),135(vusers) # truss -t kill kill -0 360 kill(360, SIG#0) = 0 # ppriv -s i-proc_session $$ # truss -t kill kill -0 360 kill(360, SIG#0) Err#1 EPERM kill(360, SIGCONT) Err#1 EPERM kill: 360: permission denied So there is some protection between processes of the same uid; but this is primarily to allow us to run unrelated daemons under the same uid without fear of "kill -9 -1" denial of service attacks. Because the above processes all started as root they cannot be trussed anyway (NOCD is set) Casper From sacadmin Thu Oct 17 11:57:16 2002 To: Terrence Miller cc: calum.mackay@sun.com, psarc-record@sac.eng.sun.com, Andrew.Tucker@sun.com Subject: Re: 2002/188 tcm-4 backward compatibility of basic priv set Date: Thu, 17 Oct 2002 20:53:04 +0200 From: Casper Dik Content-Length: 875 X-Lines: 20 Status: RO >O.K. now I understand the design. However, is source compatability always what >you want when security fixes are involved. Don't you want the developer >of the daemon to be forced to think about PRIV_X when they produce a new >version of the binary? (Binary compatibility is, of course, sacred.) Perhaps; but source compatibility is generally accepted as being somewhat important also. I'm not sure how to force that; th eonly way I vcan think of is having a "BASIC" token which is simply removed from so the application doesn't compile anymore and has to change it to "BASIC". And see whether he actually needs those added privileges. THis sort-of looks like punshing the developer and they may avoid doing PRIV_BASIC001 at all and just add the ones they know they need and then the next release will cause them heartaches. Casper From sacadmin Thu Oct 17 13:01:04 2002 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Thu, 17 Oct 2002 15:56:42 -0400 From: James Carlson To: Casper Dik Cc: Calum Mackay , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: 2002/188 jdc-1 X-Lines: 62 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 2871 Casper Dik writes: > Please note that our programming rules about set-uid programs > are very explicit about setuid(0); IT IS NOT ALLOWED. Excuse my apparent ignorance, but what precisely what rules are you referring to? I assume you mean "rules for Sun programs after this Least Privilege project integrates." Otherwise, it's a little hard to make sense of the several dozen uses of setuid(0) currently in ON. Or are there a lot of bugs that should have been filed during the Security Sweep that were not? Assuming you mean "after Least Privilege is available," then that's great, and it's not in conflict with what I'm saying. That's *precisely* what I'd like to have done when a program is converted from set-uid root to PA. However, signal delivery seems to get changed in the process. Perhaps it's just a footnote or a warning. If you did mean "we don't allow setuid(0) at Sun," then I think a lot of bugs need to be filed against existing ON code, and things like this removed: http://granby.central.sun.com/infodocs/17828.html and, perhaps a note somewhere in one of the gate READMEs would help. There are no references at all on on10.eng that I can find, and I even asked someone on the gatekeeper alias for pointers. > (That's because making euid == ruid == 0 disables the world in > security checks; programs that did this were a main cause of serious > security problems, notably ff.core) I wasn't here at Sun when that was evaluated, and 4114295 contains exactly zero useful information. It's not all that helpful as a reference point. If we really want people to follow rules, and learn from prior mistakes, I think it'd be helpful to let people know that there *are* rules. It's not at all good to make the exact rules a mystery. > >Perhaps it's just something for a future RFE. The case seems very > >rich and well thought-out to me and I was just a little surprised that > >the signal delivery didn't have the same level of control on it. But > >only surprised -- I was more interested to hear the response, and I > >wouldn't ask for any TC[AR]. > > There is actually one mechanism; it's the basic privilege {proc_session}. Yes, I realize that as well. However, sending a signal is rather different from signal delivery. It's only sending that this feature limits, and I referenced the *delivery* in the text above. > None of these processes have the "proc_session" privilege; that means that > when I hack statd/lockd/rpcbind/nfsd I *cannot* kill or otherwise > influence the other processes. Yep; understood. I knew exactly what the proc_session privilege was there for. That wasn't the issue at all. -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Thu Oct 17 13:17:04 2002 To: James Carlson cc: Calum Mackay , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: 2002/188 jdc-1 Date: Thu, 17 Oct 2002 22:12:52 +0200 From: Casper Dik Content-Length: 2451 X-Lines: 58 Status: RO >Excuse my apparent ignorance, but what precisely what rules are you >referring to? I assume you mean "rules for Sun programs after this >Least Privilege project integrates." Otherwise, it's a little hard to >make sense of the several dozen uses of setuid(0) currently in ON. Or >are there a lot of bugs that should have been filed during the >Security Sweep that were not? I count only exactly 12 occurences of setuid(0). Two of those will always fail and two others are #ifdef DEBUG. Of course, no rules are hard and fast; but set-uid executables should generally retain their real uid some place. >Assuming you mean "after Least Privilege is available," then that's >great, and it's not in conflict with what I'm saying. That's >*precisely* what I'd like to have done when a program is converted >from set-uid root to PA. However, signal delivery seems to get >changed in the process. Perhaps it's just a footnote or a warning. So we're talking only about the specific instance where a program used to run with all uids 0 and now runs as the original user but with some privileges. Perhaps such programs should better run with a uid different from 0 and different from the invoking uid. I can't think of an example of such a process, off hand. >If you did mean "we don't allow setuid(0) at Sun," then I think a lot >of bugs need to be filed against existing ON code, and things like >this removed: > > http://granby.central.sun.com/infodocs/17828.html Ugh; yes. (But only four security holes in 12 lines of code) >and, perhaps a note somewhere in one of the gate READMEs would help. >There are no references at all on on10.eng that I can find, and I even >asked someone on the gatekeeper alias for pointers. > >> (That's because making euid == ruid == 0 disables the world in >> security checks; programs that did this were a main cause of serious >> security problems, notably ff.core) > >I wasn't here at Sun when that was evaluated, and 4114295 contains >exactly zero useful information. It's not all that helpful as a >reference point. > >If we really want people to follow rules, and learn from prior >mistakes, I think it'd be helpful to let people know that there *are* >rules. It's not at all good to make the exact rules a mystery. Agreed; we're trying to make more information available; the security sweep information is still availale on secprog.eng; we still need to get it included in the golden rules. Casper From sacadmin Thu Oct 17 13:36:57 2002 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Thu, 17 Oct 2002 16:32:35 -0400 From: James Carlson To: Casper Dik Cc: Calum Mackay , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: 2002/188 jdc-1 X-Lines: 91 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 4041 Casper Dik writes: > >Excuse my apparent ignorance, but what precisely what rules are you > >referring to? I assume you mean "rules for Sun programs after this > >Least Privilege project integrates." Otherwise, it's a little hard to > >make sense of the several dozen uses of setuid(0) currently in ON. Or > >are there a lot of bugs that should have been filed during the > >Security Sweep that were not? > > I count only exactly 12 occurences of setuid(0). Two of those > will always fail and two others are #ifdef DEBUG. Are they all bugs and serious security holes? You stated before this: > Please note that our programming rules about set-uid programs > are very explicit about setuid(0); IT IS NOT ALLOWED. Now I'm confused. Not only can't I locate the rules that say this, but there are also programs that appear to violate those rules. > Of course, no rules are hard and fast; but set-uid executables > should generally retain their real uid some place. Agreed, assuming that the program does need to switch back to the invoking user at some point. It's conceivable that some do not. > >Assuming you mean "after Least Privilege is available," then that's > >great, and it's not in conflict with what I'm saying. That's > >*precisely* what I'd like to have done when a program is converted > >from set-uid root to PA. However, signal delivery seems to get > >changed in the process. Perhaps it's just a footnote or a warning. > > So we're talking only about the specific instance where a program > used to run with all uids 0 and now runs as the original user but > with some privileges. Yes. In other words, I was considering the case of the good developer who would *like* to use this new Least Privilege stuff to make his existing program more secure. He'd like to change it from just a plain old setuid root program to a Privilege Aware program. > Perhaps such programs should better run > with a uid different from 0 and different from the invoking uid. > > I can't think of an example of such a process, off hand. After looking at the problem some more, I haven't managed to find any, either, but I'm not sure that means they're not in existence. As I said, perhaps it's just something to document as part of the "converting your application over to Least Privilege" tome that I hope to see on docs.sun.com. ;-} > >If you did mean "we don't allow setuid(0) at Sun," then I think a lot > >of bugs need to be filed against existing ON code, and things like > >this removed: > > > > http://granby.central.sun.com/infodocs/17828.html > > > Ugh; yes. (But only four security holes in 12 lines of code) There's more non-specific stuff out there: http://java.sun.com/security/seccodeguide.html#ccg > >If we really want people to follow rules, and learn from prior > >mistakes, I think it'd be helpful to let people know that there *are* > >rules. It's not at all good to make the exact rules a mystery. > > > Agreed; we're trying to make more information available; the > security sweep information is still availale on secprog.eng; we > still need to get it included in the golden rules. At a minimum, there should be a pointer from on10.eng to any useful information hidden away on that site. Doing that will take just a single email message to gatekeeper@on10.eng -- and could happen today. I do try to pay attention to the broadcast email messages, but I didn't know about the 'secprog.eng' machine itself. How many other ON developers haven't been shown the secret handshake ... ? (We're really getting off topic now, but I don't see how a security sweep of any sort would be effective unless there was a public education campaign *first.* Otherwise, as soon as the sweep is done, more swill will be dumped into the gate, and nothing was really accomplished.) -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Thu Oct 17 13:42:08 2002 To: Calum Mackay cc: Gary Winiger , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: 2002/188 gw-25 & gw-26 Date: Thu, 17 Oct 2002 22:37:56 +0200 From: Casper Dik Content-Length: 700 X-Lines: 24 Status: RO >Gary, > >Here are Casper's responses to your gw-25 & gw-26. > >cheers, >c. > > > >gw-25. to add privs must recompile > >To add privileges to the standard ON set you must recompile, correct. >To grow privilege sets you must also recompile the kernel. > >The project team does not see an issue with this. To be more specific: there are 5 or so source files in the kernel that need to be recompiled if one wants to increase the size of the privilege sets. It will be a simple exercise for a project to isolate the code dependent on the size of a privilege set and/or the actual defined privileges in a single loadable kernel module for easy replacement. 2002/188 is not a replacement for 1997/334 From sacadmin Mon Oct 28 07:21:31 2002 To: Richard McDougall cc: Calum Mackay , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: 2002/188 rmc-6 integration with Project framework Date: Mon, 28 Oct 2002 16:17:07 +0100 From: Casper Dik Content-Length: 1334 X-Lines: 54 Status: RO >Unfotunately, projects are not well integrated with the Solaris >authentication framework; before that issue is addressed open >bugs on PAM abuse by projects need to be fixed. But this appears >to be pending on some further PAM work as well. > >It certainly seems logical to assign certain to projects and we >will be happy to implement an RFE to that effect after the PAM >issues have been addressed. It turns out that we can make this work with the current PAM projec implementation. (Just like "setproject()" just happens to work with dtlogin and others at this time). Would the followign satisfy you: - setproject() is enhanced to understand an additional keyword. my current one is "privileges=" but that doesn't seem to fit the "entiry.control" model: entity.control=(privilege,value,action,action,...),... I'm open for suggestions. privileges process.privileges (both seem to conflict with rctls) task.privileges user.privileges $ ppriv -v $$ 2967: sh flags = 0x0 E: basic I: basic P: basic L: all $ newtask -p realtime (*) $ ppriv -v $$ 3255: /bin/sh flags = 0x0 E: basic,proc_priocntl I: basic,proc_priocntl P: basic,proc_priocntl L: all $ (*) where realtime is a project defined to use realtime privileges. Casper From sacadmin Mon Oct 28 11:41:59 2002 Date: Mon, 28 Oct 2002 11:34:54 -0800 From: Richard McDougall User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Casper Dik CC: Richard McDougall , Calum Mackay , Andrew Tucker , psarc-record@sac.eng.sun.com, sch@eng.sun.com Subject: Re: (PSARC) Re: 2002/188 rmc-6 integration with Project framework Content-Transfer-Encoding: 7bit X-Lines: 69 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 1639 Yes, this seems to meet my concerns. I'd like to solicit the actual naming to Stephen Hahn, who is more or less responsible for the projects namespace as I understand. Thanks, Richard Casper Dik wrote: > >Unfotunately, projects are not well integrated with the Solaris > >authentication framework; before that issue is addressed open > >bugs on PAM abuse by projects need to be fixed. But this appears > >to be pending on some further PAM work as well. > > > >It certainly seems logical to assign certain to projects and we > >will be happy to implement an RFE to that effect after the PAM > >issues have been addressed. > > > It turns out that we can make this work with the current PAM projec > implementation. (Just like "setproject()" just happens to work > with dtlogin and others at this time). > > > Would the followign satisfy you: > > - setproject() is enhanced to understand an additional keyword. > > my current one is "privileges=" but that doesn't seem > to fit the "entiry.control" model: > > entity.control=(privilege,value,action,action,...),... > > I'm open for suggestions. > > privileges > > process.privileges (both seem to conflict with rctls) > task.privileges > > user.privileges > > > $ ppriv -v $$ > 2967: sh > flags = 0x0 > E: basic > I: basic > P: basic > L: all > $ newtask -p realtime (*) > $ ppriv -v $$ > 3255: /bin/sh > flags = 0x0 > E: basic,proc_priocntl > I: basic,proc_priocntl > P: basic,proc_priocntl > L: all > $ > > (*) where realtime is a project defined to use realtime privileges. > > Casper From sacadmin Mon Oct 28 14:21:10 2002 Date: Mon, 28 Oct 2002 14:16:59 -0800 From: Stephen Hahn To: Richard McDougall Cc: Casper Dik , Calum Mackay , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: (PSARC) Re: 2002/188 rmc-6 integration with Project framework Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Lines: 84 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 3121 On Mon, Oct 28, 2002 at 11:34:54AM -0800, Richard McDougall wrote: > Yes, this seems to meet my concerns. I'd like to solicit the actual naming to > Stephen Hahn, who is more or less responsible for the projects namespace as I > understand. > > > >Unfortunately, projects are not well integrated with the Solaris > > >authentication framework; before that issue is addressed open > > >bugs on PAM abuse by projects need to be fixed. But this appears > > >to be pending on some further PAM work as well. > > > > > >It certainly seems logical to assign certain to projects and we > > >will be happy to implement an RFE to that effect after the PAM > > >issues have been addressed. > > > > It turns out that we can make this work with the current PAM projec > > implementation. (Just like "setproject()" just happens to work > > with dtlogin and others at this time). > > > > Would the followign satisfy you: > > > > - setproject() is enhanced to understand an additional keyword. > > > > my current one is "privileges=" but that doesn't seem > > to fit the "entiry.control" model: > > > > entity.control=(privilege,value,action,action,...),... > > > > I'm open for suggestions. > > > > privileges > > > > process.privileges (both seem to conflict with rctls) > > task.privileges > > > > user.privileges > > > > $ ppriv -v $$ > > 2967: sh > > flags = 0x0 > > E: basic > > I: basic > > P: basic > > L: all > > $ newtask -p realtime (*) > > $ ppriv -v $$ > > 3255: /bin/sh > > flags = 0x0 > > E: basic,proc_priocntl > > I: basic,proc_priocntl > > P: basic,proc_priocntl > > L: all > > $ > > > > (*) where realtime is a project defined to use realtime privileges. I admit to being a little confused by this suggestion. (Why would a task have privileges?) Casper sent me a message proposing the integration of privileges with projects, which I (tardily?) just replied to. As I understand things, this is proposing that sets of users, who may have had different privilege sets by default, would lose such privileges when they moved their process to a different project via newtask(1). This doesn't sound very useful; moreover, it seems to be a false unification: the projects offer different resource capabilities in a quantitative sense, but do not affect privilege generally in any way. Why do these two behaviours need to be combined? (What do we gain by tying the two subsystems together?) - Stephen * In fact, I can think of a number of scenarios where mistakes in the /etc/project file would cause difficulties in constructing a desired least privileges scenario: any modification of the default or system project privileges, for instance. * Either of "privileges" or "project.privileges" is fine. There shouldn't be anything called "user." in a project entry. "process.privileges" may be the most accurate, however. (I'm still lost on "task.privileges", but that could just be me...) -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn@sun.com From sacadmin Mon Oct 28 21:21:48 2002 Date: Mon, 28 Oct 2002 21:16:27 -0800 (PST) From: Gary Winiger To: calum.mackay@sun.com, Gary.Winiger@sun.com, casper.dik@sun.com, Andrew.Tucker@sun.com, psarc-record@sac.eng.sun.com Subject: Re: 2002/188 gw-25 & gw-26 Cc: glenn.faden@sun.com Content-Length: 2704 X-Lines: 66 > Here are Casper's responses to your gw-25 & gw-26. The more complete versions of gw-25/26 from the updated issues file are: > >gw-25. to add privs must recompile gw-25 To add more privs than pre-reserved seems to require a kernel recompile. How many spare privileges will there be? Will that be enough for Trusted Solaris? > >To add privileges to the standard ON set you must recompile, correct. > >To grow privilege sets you must also recompile the kernel. > > > >The project team does not see an issue with this. > > To be more specific: there are 5 or so source files in the kernel that need > to be recompiled if one wants to increase the size of the privilege > sets. It will be a simple exercise for a project to isolate the code > dependent on the size of a privilege set and/or the actual defined > privileges in a single loadable kernel module for easy replacement. > > 2002/188 is not a replacement for 1997/334 The question is about the number of spare privileges available. How many priv_getbyname(9F) PRIV_ALLOC with distinct privilege names can be done before getting ENOMEM? In particular, Trusted Solaris will likely need some. Since the present plan is that TS not replace Solaris (at least kernel) binaries, it would be good to have enough "spare" privileges. > >gw-26. userland prive_getbyname() gw-26 gw-9 from inception, how do daemons add privileges? Equivalent of priv_getbyname(9F) PRIV_ALLOC. > There is a private interface that allows allocation of privileges using > modctl; we do not Intend to expose this interface other than through > the driver framework. > > Privileges are not intended for allocating and checking in applications; > conveying what privileges applications have through ucred is solely intended > to allow daemons to make informed decisions on what privileges their > clients have so they can use the appriopriate privileges on their behalf. So how then do daemons add the privileges that they interpret on behalf of their clients? For example how does XSun add privileges such as win_dac_read, win_dac_write, win_selection? How would a daemon such as the label server add sys_trans_label? In later discussions about the review and from some discussion in the review, it seemed like a library interface similar to Trusted Solaris: char *get_priv_text(const priv_t priv_id); Returns a pointer to the statically allocated, null- terminated privilege description text specified by priv_id. would be useful/necessary to support a GUI for associating privileges with user_attr and exec_attr entries as well as for a CLI to describe privileges. Gary.. From sacadmin Mon Oct 28 23:32:28 2002 To: Gary Winiger cc: calum.mackay@sun.com, Gary.Winiger@sun.com, Andrew.Tucker@sun.com, psarc-record@sac.eng.sun.com, glenn.faden@sun.com Subject: Re: 2002/188 gw-25 & gw-26 Date: Tue, 29 Oct 2002 08:28:08 +0100 From: Casper Dik Content-Length: 8609 >gw-25 To add more privs than pre-reserved seems to require a kernel > recompile. How many spare privileges will there be? Will that > be enough for Trusted Solaris? The current privileeg set has 40 privileges defined; since we round up to the nearest multiple of 32 we get 64 privileges, so there are 24 spare privileges. The build process guarantees a minimum of 10 slots. This will probably not be sufficient for Trusted Solaris but I do not see how that matters; the privilege system is defined such that it can grow by changing a tiny portion of the kernel (5 files) which can easily be isolated. > So how then do daemons add the privileges that they interpret on > behalf of their clients? For example how does XSun add privileges > such as win_dac_read, win_dac_write, win_selection? How would a > daemon such as the label server add sys_trans_label? At this time they do not; the project team realizes that some work will need to be done to support Trusted Solaris on top of 2002/188. > > char *get_priv_text(const priv_t priv_id); > Returns a pointer to the statically allocated, null- > terminated privilege description text specified by > priv_id. > > would be useful/necessary to support a GUI for associating privileges > with user_attr and exec_attr entries as well as for a CLI to describe > privileges. I've added a function "priv_gettext()" which does precsiely that and allows for things such as: $ ppriv -v -l file_chown Allows a process to change a file's owner user ID. Allows a process to change a file's group ID to one other than the process' effective group ID or one of the process' supplemental group IDs. file_chown_self Allows a process to give away its files; a process with this privilege will run as if {_POSIX_CHOWN_RESTRICTED} is not in effect. file_dac_execute Allows a process to execute an executable file whose permission bits or ACL do not allow the process execute permission. file_dac_read Allows a process to read a file or directory whose permission bits or ACL do not allow the process read permission. file_dac_search Allows a process to search a directory whose permission bits or ACL do not allow the process search permission. file_dac_write Allows a process to write a file or directory whose permission bits or ACL do not allow the process write permission. In order to write files owned by uid 0 in the absence of an effective uid of 0 ALL privileges are required. file_link_any Allows a process to create hardlinks to files owned by a uid different from the process' effective uid. file_owner Allows a process which is not the owner of a file to modify that file's access and modification times. Allows a process which is not the owner of a directory to modify that directory's access and modification times. Allows a process which is not the owner of a file or directory to remove or rename a file or directory whose parent directory has the ``save text image after execution'' (sticky) bit set. Allows a process which is not the owner of a file to mount a ``namefs'' upon that file. (Does not apply to setting access permission bits or ACLs.) file_setdac Allows a process which is not the owner of a file or directory to modify that file's or directory's permission bits or ACL except for the set-uid and set-gid bits. file_setid Allows a process to change the ownership of a file or write to a file without the set-user-ID and set-group-ID bits being cleared. Allows a process to set the set-group-ID bit on a file or directory whose group is not the process' effective group or one of the process' supplemental groups. Allows a process to set the set-user-ID bit on a file with different ownership in the presence of PRIV_FILE_SETDAC. Additional restrictions apply when creating or modifying a set-uid 0 file. ipc_dac_read Allows a process to read a System V IPC Message Queue, Semaphore Set, or Shared Memory Segment whose permission bits do not allow the process read permission. ipc_dac_write Allows a process to write a System V IPC Message Queue, Semaphore Set, or Shared Memory Segment whose permission bits do not allow the process write permission. ipc_owner Allows a process which is not the owner of a System V IPC Message Queue, Semaphore Set, or Shared Memory Segment to remove, change ownership of, or change permission bits of the Message Queue, Semaphore Set, or Shared Memory Segment. net_privaddr Allows a process to bind to a privileged port number. The privilege port numbers are 1-1023 (the traditional UNIX privileged ports) as well as those ports marked as "udp/tcp_extra_priv_ports" with the exception of the ports reserved for use by NFS. net_rawaccess Allows a process to have direct access to the network layer. proc_chroot Allows a process to change its root directory. proc_clock_highres Allows a process to use high resolution timers. proc_audit Allows a process to generate audit records. Allows a process to get its own audit pre-selection information. proc_exec Allows a process to call execve(). proc_fork Allows a process to call fork()/fork1()/vfork() proc_lock_memory Allows a process to lock pages in physical memory. proc_owner Allows a process to send signals to other processes, inspect and modify process state to other processes regardless of ownership. When modifying another process, additional restrictions apply: the effective privilege set of the attaching process must be a superset of the target process' effective, permitted and inheritable sets; the limit set must be a superset of the target's limit set; if the target process has any uid set to 0 all privilege must be asserted unless the effective uid is 0. Allows a process to bind arbitrary processes to CPUs. proc_priocntl Allows a process to elevate its priority above its current level. Allows a process to change its scheduling class to any scheduling class, including the RT class. proc_session Allows a process to send signals or trace processes outside its session. proc_setid Allows a process to set its uids at will. Assuming uid 0 requires all privileges to be asserted. proc_taskid Allows a process to assign a new task ID to the calling process. sys_acct Allows a process to enable and disable and manage accounting through acct(2) and exacctsys(2). sys_audit Allows a process to start the (kernel) audit daemon. Allows a process to view and set audit state (audit user ID, audit terminal ID, audit sessions ID, audit pre-selection mask). Allows a process to turn off and on auditing. Allows a process to configure the audit parameters (cache and queue sizes, event to class mappings, policy options). sys_config Allows a process to perform various system configuration tasks. Allows filesystem specific administrative procedures, such as filesystem configuration ioctls, quota calls, creation/deletion of snapshots, manipulating the PCFS bootsector. sys_devices Allows a process to create device special files. Allows a process to successfully call a kernel module that calls the kernel drv_priv(9F) function to check for allowed access. Allows a process to open the real console device directly. sys_ipc_config Allows a process to increase the size of a System V IPC Message Queue buffer. sys_linkdir Allows a process to unlink and link directories. sys_mount Allows a process to mount and unmount filesystems which would otherwise be restricted (i.e., most filesystems except namefs) Allows a process to add and remove swap devices. sys_net_config Allows a process to configure a system's network interfaces and routes. Allows a process to configure network parameters using ndd. Allows a process access to otherwise restricted information using ndd. sys_nfs Allows a process to perform Sun private NFS specific system calls. Allows a process to bind to bind to NFS reserved ports: ports 2049 (nfs) and port 4045 (lockd). sys_pset Allows a process to create and delete processor sets, assign CPUs to processor sets and override the PSET_NOESCAPE property. sys_resource Allows a process to exceeds the resource limits imposed on it by setrlimit(2) and setrctl(2). sys_suser_compat Allows a process to successfully call a third party loadable module that calls the kernel suser() function to check for allowed access. This privilege exists only for third party loadable module compatibility and is not used by Solaris proper. sys_time Allows a process to manipulate system time using any of the appropriate system calls: stime, adjtime, ntp_adjtime. From sacadmin Tue Oct 29 06:24:13 2002 To: Stephen Hahn cc: Richard McDougall , Calum Mackay , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: (PSARC) Re: 2002/188 rmc-6 integration with Project framework Date: Tue, 29 Oct 2002 15:19:54 +0100 From: Casper Dik Content-Length: 470 > I admit to being a little confused by this suggestion. (Why would a > task have privileges?) Casper sent me a message proposing the > integration of privileges with projects, which I (tardily?) just > replied to. Considering the opposition/confusions/etc from the "projects" team, could we just lay this to rest for now and not implement this? After all, most of this can now be achieved using: pfexec -P newtask -p realtime ..... Capser From sacadmin Tue Oct 29 07:00:18 2002 to: Richard McDougall , Calum Mackay , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: (PSARC) Re: 2002/188 rmc-5 truss output Date: Tue, 29 Oct 2002 15:55:56 +0100 From: Casper Dik Content-Length: 1272 rmc-5 The truss command will be the first place an administrator is likely to go to debug a privilege issue. Can we enhance truss to understand and print privilege debugging information at the time of a system call? Would this be sufficient information: truss -t so_socket /tmp/ping localhost so_socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP, "", 4) = 5 so_socket(PF_INET6, SOCK_RAW, IPPROTO_ICMPV6, "", 4) Err#13 EACCES [net_rawaccess] truss -t open cat /etc/shadow open64("/etc/shadow", O_RDONLY) Err#13 EACCES [file_dac_read] Communicating this information is fairly tricky so extending this much further will not be easy. The information is created fairly deep down in the kernel inards, some times holding pidlock, p_lock or other locks, so we can't do much other than updating lockfree thread/lwp private data structures which we can then safely inspect only in processes stopped in SYSEXIT. The extension exists of a new field in lwpstatus, errpriv, which is taken from the slack that still exists in the structure. Other implications are making three more manifest constants visible: PRIV_ALL (indicating all privileges were needed) PRIV_MULTIPLE (more than one additional privilege was needed) PRIV_NONE (no privileges needed) Casper From sacadmin Tue Oct 29 15:48:58 2002 Date: Tue, 29 Oct 2002 13:19:13 -0800 From: Richard McDougall User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Casper Dik CC: Richard McDougall , Calum Mackay , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: (PSARC) Re: 2002/188 rmc-5 truss output Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1526 Thanks Casper - this is sufficient for first cause analysis. I assume the truss man page will describe what this means and where to look for further information? Richard. Casper Dik wrote: > rmc-5 The truss command will be the first place an administrator > is likely to go to debug a privilege issue. Can we enhance > truss to understand and print privilege debugging > information at the time of a system call? > > > Would this be sufficient information: > > truss -t so_socket /tmp/ping localhost > so_socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP, "", 4) = 5 > so_socket(PF_INET6, SOCK_RAW, IPPROTO_ICMPV6, "", 4) Err#13 EACCES [net_rawaccess] > > truss -t open cat /etc/shadow > open64("/etc/shadow", O_RDONLY) Err#13 EACCES [file_dac_read] > > > Communicating this information is fairly tricky so extending this much > further will not be easy. The information is created fairly deep down > in the kernel inards, some times holding pidlock, p_lock or other > locks, so we can't do much other than updating lockfree thread/lwp > private data structures which we can then safely inspect only > in processes stopped in SYSEXIT. > > The extension exists of a new field in lwpstatus, errpriv, which is > taken from the slack that still exists in the structure. > > Other implications are making three more manifest constants visible: > > PRIV_ALL (indicating all privileges were needed) > PRIV_MULTIPLE (more than one additional privilege was needed) > PRIV_NONE (no privileges needed) > > Casper From sacadmin Tue Oct 29 15:53:19 2002 To: Richard McDougall cc: Calum Mackay , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: (PSARC) Re: 2002/188 rmc-5 truss output Date: Wed, 30 Oct 2002 00:48:58 +0100 From: Casper Dik Content-Length: 306 > >Thanks Casper - this is sufficient for first cause analysis. I assume the truss > man page will describe what this means and where to look for further information? The complete description of truss is fairly short (2 paragraphs), it will be ammended to include the privileges information. Casper From sacadmin Mon Nov 4 16:47:47 2002 Date: Mon, 04 Nov 2002 16:44:02 -0800 From: Richard McDougall User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hahn CC: Richard McDougall , Casper Dik , Calum Mackay , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: (PSARC) Re: 2002/188 rmc-6 integration with Project framework Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 3712 I'd like to remove "projects" from the problem definition I was exploring. Simply stated, all I was looking for was a way to assign a default least privilege to a workload, rather than any specific user in the same way we do so with resource assignment. I.e. if I want to start a collection of processes given a pre-defined set of privileges, can I do so using a preconfigured named priviledge set? Given that we use projects to do so for resources, it seemed that the "named set" mechanism already exists. Can you suggest what the best way of doing so might be? Thanks, Richard. Hahn wrote: > On Mon, Oct 28, 2002 at 11:34:54AM -0800, Richard McDougall wrote: > > >Yes, this seems to meet my concerns. I'd like to solicit the actual naming to > >Stephen Hahn, who is more or less responsible for the projects namespace as I > >understand. > > > > > >>>Unfortunately, projects are not well integrated with the Solaris > >>>authentication framework; before that issue is addressed open > >>>bugs on PAM abuse by projects need to be fixed. But this appears > >>>to be pending on some further PAM work as well. > >>> > >>>It certainly seems logical to assign certain to projects and we > >>>will be happy to implement an RFE to that effect after the PAM > >>>issues have been addressed. > >> > >>It turns out that we can make this work with the current PAM projec > >>implementation. (Just like "setproject()" just happens to work > >>with dtlogin and others at this time). > >> > >>Would the followign satisfy you: > >> > >> - setproject() is enhanced to understand an additional keyword. > >> > >> my current one is "privileges=" but that doesn't seem > >> to fit the "entiry.control" model: > >> > >> entity.control=(privilege,value,action,action,...),... > >> > >> I'm open for suggestions. > >> > >> privileges > >> > >> process.privileges (both seem to conflict with rctls) > >> task.privileges > >> > >> user.privileges > >> > >>$ ppriv -v $$ > >>2967: sh > >>flags = 0x0 > >> E: basic > >> I: basic > >> P: basic > >> L: all > >>$ newtask -p realtime (*) > >>$ ppriv -v $$ > >>3255: /bin/sh > >>flags = 0x0 > >> E: basic,proc_priocntl > >> I: basic,proc_priocntl > >> P: basic,proc_priocntl > >> L: all > >>$ > >> > >>(*) where realtime is a project defined to use realtime privileges. > > > I admit to being a little confused by this suggestion. (Why would a > task have privileges?) Casper sent me a message proposing the > integration of privileges with projects, which I (tardily?) just > replied to. > > As I understand things, this is proposing that sets of users, who may > have had different privilege sets by default, would lose such > privileges when they moved their process to a different project via > newtask(1). This doesn't sound very useful; moreover, it seems to be > a false unification: the projects offer different resource > capabilities in a quantitative sense, but do not affect privilege > generally in any way. Why do these two behaviours need to be > combined? (What do we gain by tying the two subsystems together?) > > - Stephen > > * In fact, I can think of a number of scenarios where mistakes in the > /etc/project file would cause difficulties in constructing a desired > least privileges scenario: any modification of the default or system > project privileges, for instance. > > * Either of "privileges" or "project.privileges" is fine. There > shouldn't be anything called "user." in a project entry. > "process.privileges" may be the most accurate, however. (I'm still > lost on "task.privileges", but that could just be me...) > From sacadmin Tue Nov 5 09:13:22 2002 To: Richard McDougall cc: Stephen Hahn , Calum Mackay , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: (PSARC) Re: 2002/188 rmc-6 integration with Project framework Date: Tue, 05 Nov 2002 18:08:59 +0100 From: Casper Dik Content-Length: 966 >I'd like to remove "projects" from the problem definition I was exploring. >Simply stated, all I was looking for was a way to assign a default least >privilege to a workload, rather than any specific user in the same way we do so >with resource assignment. I.e. if I want to start a collection of processes >given a pre-defined set of privileges, can I do so using a preconfigured named >priviledge set? Given that we use projects to do so for resources, it seemed >that the "named set" mechanism already exists. Can you suggest what the best way >of doing so might be? The easiest way of doing so would be assigning the privileges to a role and have that role run "pfexec -P all cmd" (which gives an intersection of "all" and "maxpriv" for that particular user/role.) Even though there's one named set, there's no generic "named set" mecchanism; off hand, I can't think of any particular set of priorities you would need to run a workload with. Casper From sacadmin Fri Nov 15 06:21:25 2002 To: Richard McDougall cc: Stephen Hahn , Calum Mackay , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: (PSARC) Re: 2002/188 rmc-6 integration with Project framework Date: Fri, 15 Nov 2002 15:21:23 +0100 From: Casper Dik Content-Length: 1219 > >I'd like to remove "projects" from the problem definition I was exploring. >Simply stated, all I was looking for was a way to assign a default least >privilege to a workload, rather than any specific user in the same way we do so >with resource assignment. I.e. if I want to start a collection of processes >given a pre-defined set of privileges, can I do so using a preconfigured named >priviledge set? Given that we use projects to do so for resources, it seemed >that the "named set" mechanism already exists. Can you suggest what the best way >of doing so might be? We've been talking a bit more about granting privileges through "pfexec"; we now have the following proposal on the table: we keep limitpriv, defaultpriv (which are set on login/su/etc) we remove maxpriv and replace it with "profile based privileges". To default a certain set of privilege one defines, e.g., the following in /etc/security/prof_attr Full Privilege:::User with all system privileges:privs=all Real Time:::User with real time privileges:privs=proc_priocntl,sys_cpu_config A user can then be granted one or more profiles: casper:profiles=Real Time would this satisfy your privilege grouping mechanism? Casper From sacadmin Mon Nov 18 10:57:56 2002 Date: Mon, 18 Nov 2002 10:51:07 -0800 From: Richard McDougall User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Casper Dik CC: Richard McDougall , Stephen Hahn , Calum Mackay , Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: (PSARC) Re: 2002/188 rmc-6 integration with Project framework Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1395 Yes, this looks like a good solution to the problem, and addresses stephen's concerns. Thanks, Richard. Casper Dik wrote: > >I'd like to remove "projects" from the problem definition I was exploring. > >Simply stated, all I was looking for was a way to assign a default least > >privilege to a workload, rather than any specific user in the same way we do so > >with resource assignment. I.e. if I want to start a collection of processes > >given a pre-defined set of privileges, can I do so using a preconfigured named > >priviledge set? Given that we use projects to do so for resources, it seemed > >that the "named set" mechanism already exists. Can you suggest what the best way > >of doing so might be? > > > > We've been talking a bit more about granting privileges through "pfexec"; > we now have the following proposal on the table: > > we keep limitpriv, defaultpriv (which are set on login/su/etc) > > we remove maxpriv and replace it with "profile based privileges". > > > To default a certain set of privilege one defines, e.g., the following > in /etc/security/prof_attr > > Full Privilege:::User with all system privileges:privs=all > Real Time:::User with real time privileges:privs=proc_priocntl,sys_cpu_config > > > A user can then be granted one or more profiles: > > casper:profiles=Real Time > > would this satisfy your privilege grouping mechanism? > > Casper From sacadmin Fri Nov 22 07:40:37 2002 To: Calum Mackay cc: Andrew Tucker , psarc-record@sac.eng.sun.com Subject: Re: PSARC 2002/188 commitment review MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <15757.1037979626.0@holland> Date: Fri, 22 Nov 2002 16:40:33 +0100 From: Casper Dik Content-Length: 28988 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15757.1037979626.1@holland> >Hi Casper, how's you? > >Hope you enjoyed the review today :) > >Looks like we have a few issues to work through; I will try to >coordinate all this so you know what you need to respond to, and all the >queries are resolved. > >For starters: would you please prepare some answers for Gary Winiger's >issues (gw-*), and let Gary and I know if you're unclear as to what he's >referring? I just like to know where I am so attached find the list of changes and the list of responses to the issues raised at commitment ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15757.1037979626.2@holland> Content-Description: changes The following is a summary of the changes made as a result of the commitment review and following discussions: - Device policy: - /sbin/devpolicy was removed as a separate command; its functionaility was incoporated in devfsadm - device_policy(4) and extra_privs(4) were made Project Private the extra_privs(4) syntax was changed and privileges defined in it are now more tightly coupled with drivers. - update_drv/add_drv/rem_drv are now the only supported interfaces to edit privilege specific information in device_policy(4) and extra_privs(4) - Assigning privileges to users/RBAC. - the maxpriv user_attr entry, PRIV_MAX policy.conf entry have been removed - a new /etc/security/prof_attr keyword was added: "privs=". this allows grouping of privileges in profiles, e.g., an "Database" (allow memory locking) or Real TIme (priocntl, high resolution timers) - the working of the "pfexec -P" command was changed to merge the privileges from a user's profile and not obtain them from user_attr. (A user gets to use the union of all privileges defined in all profiles he can use) - the code now falls back to "suser" rather than converting everything to "solaris". New entries which use privileges are defined as "solaris" entries. This allows exec_attr to be shared using name services between old and new systems - privileges - PRIV_SYS_PSET - renamed to PRIV_SYS_CPU_CONFIG - PRIV_SYS_CPU_CONFIG - takes CPU configuration privileges from SYS_CONFIG - Kernel interfaces - crgetref() was added for NFS - crnetadjust() was added privately for NFS - supgroupmember() - checks member ship only against the sup. groups, not the effective gid. [needed for exec] - lwpstatis:pr_errpriv - last failed privilege in system call execution - new aux vector: AT_SUN_AUXFLAGS values: AF_SUN_SETUGID - Userland interfaces: - /etc/security/priv_names New file; maps privileges to descriptive text as found in privileges(5); localized versions should exist. - char *priv_gettext(const char *priv) Returns privilege descriptive text from priv_names [localized] - ucred_t type changed to "struct ucred_s" - priv_set_t type changed (no longer void) - ucred_* functions now take a const ucred_t * argument (except free, of course) - Utility changes. - ppriv -l - list all privileges - ppriv -l -v [priv ...] - list privileges + descriptive text. - truss - output last failed privilege in error message - Runtime linker: - use AT_SUN_AUXFLAGS ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15757.1037979626.3@holland> Content-Description: issues2.respone PSARC 2002/188 Privileges for Solaris Commitment review 16 October 2002 tcm-4 I'm still confused about how the set of privileges can evolve. Is the Basic Priv scheme equivalent to haveing priviledges entitled Permits all the actions not covered by any other priviledge as of version N permanently for all N where any program is entitled to the one for the version it was built against No - new functionality may introduce new privileges which process will not have unless they require all privileges. Basic privileges allow changing current unprivileged operations to require a basic privilege. The version of the privilege specification against which a process is compiled is not recorded; this would go against the principle that the application code is independent of the kernel interfaces and privilege definitions and would require ISVs to make code changes when they recompile for a new release. agt-7 If one of the goals is to allow deployment of realtime applications without PRIV_SYS_CONFIG, you should add a separate privilege for the p_online functionality (or add it to PRIV_SYS_PSET; this is commonly used to block interrupts to selected CPUs. Answer: we have resolved this issue by defining PRIV_SYS_CPU_CONFIG; it takes the p_online() parts of sys_config and replaces sys_pset. agt-8 3.5: I'm not sure I understand the requirement of full privileges for controlling or modifying uid 0 things. Why is this necessary if the controlling process is euid 0, and the controlled process has a limit set that is a subset of that of the controlling process? If a process has euid 0 it can modify any configuration file, include /etc/passwd, /etc/shadow, /etc/user_attr. The document said so, but the wording could be better (and was fixed). agt-9 4.3: What are the compatibility and performance implications of the dblk_t change? Sounds like at least the behavior of socket and bind may change. Performance implications: the project is currently undergoing Perfpit tests, this is not a PSARC issue. Compatibility changes: the credential at bind time is now in force. This fixes a security hole; the credential at socket time is now ignored. This gives the original 4.x BSD socket behaviour. Changes in dblk type: the dblk is opaque; we're not touching or moving the public fields. An existing TLI security hole is plugged. agt-10 4.11: I assume the 660 permissions on /dev/ip are there for a reason, do we know the implications of taking away access for group sys? Who is currently taking advantage of this? "netstat" is taking advantage of this. I believe group sys access to /dev/ip is a security hole. We identified two more public domain tools that use the Solaris MIB; one a perl module which opens a specific device (the sample code uses /dev/tcp); I have communicated with the auther and have given him the better sequence: /dev/arp, push tcp, push udp A C module was found and the author determine he was in group sys so he never noticed the restriction; his code was changed to use /dev/arp and different sequence of I_PUSH modules as well. We have found no reference of the use of /dev/ip for obtaining kernel MIBs or the fact that you need group "sys". We also found one more security hole in the IP stack; this time in the routing sockets. The new dblk frame work allows for easy fixing. agt-11 Any other potentially incompatible changes to device permissions planned? The permissions of a number of mode 600 devices is relaxed to mode 666 in order to properly support privileges for networking. Another incompatbile change is that chmod 666 /dev/*mem no longer works; you will also need to update the device policy in that case. agt-12 I'm not clear on the purpose of extra_privs(4). As a result of PSARC discussions, we have made both extra_privs(4) and device_policy(4) undocumented; the extra_privs(4) file is now used only for privileges associated with devices, using a : syntax; privileges are only loaded from that file is the associated major device is known to the kernel. The privilege is removed when rem_drv is called (or update_drv) The rationale for having these in a seperate file is two fold: - allows privileges to be known to the kernel prior to a device being loaded. (This is useful when a daemon that is associated with a device starts before the device is opened and wants to enable the device specific privilege prior to opening the device; but it's not until the open() that the device driver is loaded and the privilege allocated) - guards against typos on the add_drv/update_drv command line when using exising privileges (clearly add_drv -P could still cause a typo) agt-13 The answer to gw-9 (inception) talks about allowing customers to define privileges, but I don't see any interfaces for supporting that. Did I miss them? extra_privs; priv_getbyname(..., PRIV_ALLOC) [inside the kernel] In its initial release, we are not making a user mode privilege allocation interface public except through the "add_drv/update_drv -P" option. agt-14 Why make the format of device_policy public? If the *_drv utilities should be used for updates, why allow "vi" access as well? It will not be documented. agt-15 I don't understand the purpose of the -I flag to devpolicy(1M). Is this just to push the file into the kernel on boot? (If so, see agt-16.) Yes. but see agt-16 agt-16 Why isn't the device_policy file managed by devfsadm, like other device configuration files? To resolve this issue, the devpolicy(1m) command was removed and its functionality incorporated into devfsadm. agt-17 The -p option to add_drv should take multiple comma-separated policies (like -m) since a single driver can have multiple policies. The policies are white space separated as in "example 1" in add_drv(1m). The parser can tell "foo=bar" and "minorname" apart so it can find where tokens end and a new minor name starts a new policy. Other tokens where considered but most are valid in device names or privilege set specifications. Note that the add_drv command fails to set minor permissions for devices that contain a ","; on my desktop, 1118 minor names have a ",", 234 do not. The project team believes that a "," seperator is wrong for "-m" as well. jdc-1 What happens with kill(2)? One of the hidden assumptions of a setuid program is that no ordinary user can send it a signal. A process that has instead some acquired privileges seems to lack that protection. I see a privilege to control someone sending a signal, but how do I (as the person converting a setuid root application to a PA application) prevent reception from an untrusted user? The restriction on sending signals are not as strict as those on modifying processes; set-uid processes have some protection but as long as they run on a terminal or don't change effective, real and saved uid, they can still be killed. [ Because of the lack of real world examples of this case, this issue is considered resolved ] jdc-2 Nit: using 'void' for ucred_t disables some lint checks; suggest blind structure tag instead ('struct ucred_s; typedef struct ucred_s ucred_t;'). Or even a typedef that is itself a pointer so that you have 'uid_t ucred_geteuid(ucred_t);'. (The latter, I think, encourages good developer hygiene.) This nit was resolved by changing the typedef to "struct ucred_s"; similarly, priv_set_t is no longer defined a a "void". jdc-3 Nit: (response to inception gw-27) 'Evolving' implies 'Public'. jdc-4 Nit: 4.4: private details aren't Unstable unless we're telling customers about them, so secpolicy* is (possibly) Consolidation Private for now. (And should be in the tables.) It is consolidation private. It was added to the tables. jdc-5 6.2: Type of 'Private' for priv_impl.h (and others)? Consolidation or Project? Project. rmc-1 Rationale for overloading EPERM at the expense of delivering cryptic error messages to end users. Is there a compatible way to extend the error namespace or deliver more meaningful errors via perror()? No; error numbers and messages are defined in the standard; we made the occasional error in converting the code (EACCES for EPERM and such); this was immediately flagged by standards conformance checks. rmc-2 Are we adding an ISM privilege? Since this is equivalent to an uncontrolled mlock(), we could conceivably add another privilege or enhance ISM to use PRIV_PROC_LOCK_MEMORY. This could be a basic privilege but we are not considering it at this time. Such change should certainly be made if the standard shared memory restrictions that require /etc/system changes are removed. rmc-3 Should ppriv allow the system administrator to list the full set of privilege options that can be applied to a process? We have now added the command: ppriv -l ppriv -l -v (list verbosely) the latter build on a new interface: char *priv_gettext(const char *priv); which returns a *localized* string describing the privilege. rmc-4 How can I write an administration application that is aware of the privilege options that can be applied, and is able to adopt and expanded set without recompiling the application? I don't set how the namespace is dynamically discoverable... See the example in priv_names(3c) Privileges start and 0 and have a contiguous name space; getting all privileges is done through: for (i = 0; (str = priv_getbynum(i)) != NULL; i++) ; rmc-5 The truss command will be the first place an administrator is likely to go to debug a privilege issue. Can we enhance truss to understand and print privilege debugging information at the time of a system call? Privilege manipulations will likely deny truss further control of the process; generally truss can be used to determine EACCES/EPERM messages; the privilege debugging output will be in lockstep with the system call return. However, being sensitive to this point, we have changed truss and the /proc interfaces as follows: the lwpstatus structure was expanded with the field "pr_badpriv" when a process is subjected to syscall tracing, this field will be set to PRIV_NONE on syscall entry and in the privilege error code it will be set to the misising privilege which can also be PRIV_ALL (privilege escalation prevention) or PRIV_MULTIPLE (device policy). The truss output looks like: open64("/etc/shadow", O_RDONLY) Err#13 EACCES [file_dac_read] and the truss manual page is modified to document this fact. gw-1 It still seems to me that processes with privilege should be restricted to the "secure" libraries. I don't see that this proposal does so. What am I missing? The question is best answered with a question: Is root restricted to using secure libraries? The restriction is enforced when there's a transition of privilege level from low to high; when no transition takes place, programs are at liberty to load libraries. The implementation of this is using issetugid() which is extended to mean "a transition to more privileges took place". A new linker aux field is introduced, AT_SUN_AUXFLAGS and we define one bit of this flag word, AF_SUN_SETUGID. It is used by the linker to determine "secure mode" without having to shadow algorithms inside the kernel. gw-2 Missed the point of boot, inetd, allocate, cron rights profiles. Noted for a future implementation. In the few daemons we have examined we found that the typical use is not but more one of ; a rights profiles is primarily usable for privileges which are permanent. gw-3 prochasprocperm is not documented. Maybe it should be in ddi_cred(9). Neither are any of the other kernel private functions. I will document them in the spec. gw-4 How will programmers know to use sec_policy* or add new ones? How will they know to use privileges in apps? For now, these are consolidation private interfaces. They know which privileges applications need by studying manual pages where these will be documented. gw-5 3.1 Page 15 last paragraph, is there a difference between basic and default privileges? The default privilege can include file_chown_self; basic does not include file_chown_self gw-6 forced privilege emulation? What's the proposal? Set-uid root. None other. gw-7 How does a process become pa in the presence of inheritable privs (page 18)? What are those privileges? Left over from previous version. It does not become PA. The sentence was removed. gw-8 3.3.3 last para (-1). Note with allowed privs the idea is to pass privs around non priv apps from grandparent to grandchild across a parent which cannot use any privs. How will this restriction work in that light? The process that cannot use privileges will not be able to set LD_* variables that affect the child process that runs with more privileges. gw-9 States: the prototype's privileges are listed in privileges(5). What are the proposed privileges? Are they the same as the prototype? Yes. gw-10 Taxonomy of /etc/system variables. "Evolving" gw-11 Seems hard to have daemons run as user daemon if they will support diskless. How will it be determined which daemons can run without uid == 0? (3.5 and 3.8) There is no difference between diskless and ordinary operation except when the user runs as a non uid 0 uid *and* requires any of the file* privileges. None of the daemons that no longer run as uid 0 require these privileges. So the way to determine whether a daemon can run safely with a uid other than 0 is defined as "needs any of the file* privs". gw-12 Will QFS be supported? QFS will work but will use uid 0; it should be converted to use the new interfaces. We have written a document which explains how to convert a filesystem to privileges. The changes we made will cause filesystem to fail to compile because of the credential hiding employed. gw-13 What does it mean for sys_config to be evolving ans sys_suser_compat to be obsolete? Where is this noted in the public taxonomy? The only reason why sys_suser_compat is obsolete is that the suser() function is obsolete as noted in the drv_priv() manual page. The privilege is self is stable but will gain less use over time. gw-14 user_attr(4) can suser and solaris co-exist? When is one selected over the other? The library will prefer "solaris" but will fall back to "suser" New "solaris" entries are added when they use privileges; new entries which do not use privilege can still use "suser" which allows them to be seen by systems running older releases. gw-15 Will the UIs enforce defaultpriv <= limitpriv; maxpriv <= limitpriv? Yes. (maxpriv was dropped in the spec in favour of profile based privileges, see rmc-6 gw-16 How will it be made safe for programs like su, dtsession if the user has a reduced limit set. It seems I could lockscreen and never be able to get out of lockscreen. I'm very concerned that limitpriv will be a call generator. The use of limitpriv is already documented as possibly having unintended side effects; users can get into the same bind using ppriv(1) or setppriv(2) directly. A program like "su" will likely fail in pam_setcred(). In the two years left for Solaris 10 we will undertake to study privileged applications and determine which privileges they require; applications will then be changed to enforce this on startup, also limiting the privileges actually used by those applications. In future, when the filesystem supports forced privileges, an application will fail to run if its forced set is not a subset of the limit set. gw-17 I'd prefer device_policy(4) be project private. There are CLIs to administer it. It is classified as unstable. Why even expose it as an administrative interface? It's intended to be project private; the documentation is provided to allow guarding against file corruption. gw-18 Why is extra_privs(4) needed? It seems to me that when device_policy gets loaded into the kernel, new privileges listed there could be defined. Extra_privs is Project Private. Only privileges attached to devices are allowed. For the reasons of its existance see agt-12 gw-19 I don't understand file_setdac relative to file_setid. Just changing the file permissions is of a different order than allowing the creation of set-uid executables. This was copied directly from TS. gw-20 proc_set_id seems to be missing: Allows a process to set the process group of a controlling terminal to one not in the process' process group. Allows a process to set the window size on a terminal not in its session. How are these controlled? These always return EPERM, even for privileged processes in Solaris; there doesn't appear to be a reason to change this. gw-21 sys_devices seems incomplete: Allows a process to create device special files. Allows a process to use mknod(2) to create directory and regular files. Allows a process to revoke all access to a device special file. Allows a process to reassign a controlling terminal from one process to another. Allows a process to open a terminal already exclusively opened. Allows a process to revoke access to its controlling terminal. Allows a process to enable or disable keyboard abort processing. Allows a process to map frame buffer devices into its address space. Allows a process to enable or disable a disk's write-check capability. Allows a process to load a kernel loadable driver. Allows a process to control the Floating Point Accelerator. Allows a process to configure autopush STREAMS modules. Allows a process to configure the device driver policy table. Allows a process to successfully call a third party loadable module that calls DDI drv_priv. Some of these are sys_config (abort enabling/disabling does not feel at hoem under devices) Configuring the device driver policy table requires all privileges. I don't think we still have supported floating point accelerators; there are no restrictions on mapping framebuffers as there are no such restrictions in Solaris proper other than the fact that the DAC attributes are changes to reflect the user using the console. So the entry is complete. gw-22 sys_fs_config, sys_max_proc, sys_min_free seem to be missing. How are their functions restricted. Name sys_fs_config Allows a process to manipulate filesystem locks. Allows a process to set/clear the automatic update (delayed I/O) state of a filesystem. Allows a process to get meta disk allocation information. Allows a pro- cess to open a specified inode in a filesystem. Allows a process to set the last access time of a file system object. Name sys_maxproc Allows a process to create processes when the maximum number of processes for this process' owning user is exceeded. Allows a process to create the last avail- able process in the system. Name sys_minfree Allows a process to write to a filesystem whose avail- able storage space is below the minimum allowed. These function do not appear to warrant their own privileges so they're lumped in with other privileges, mostly sys_resources and sys_config. gw-23 sys_mount seems incomplete: Allows a process to determine the users of a filesystem. It does not give such access. That operation is not restricted in Solaris. gw-24 sys_net_config and sys_nfs seem incomplete: Name sys_net_config Allows a process to configure a machine's network interfaces and routes. Allows a process to set a machine's host and domain names. Allows a process to set a machine's kerberos realm. Allows a process to load and unload host type, accreditation, and default information. Allows a process direct access to network devices. Allows a process to set endpoint names. Allows a process to use the rpcmod STREAMS module. Because part of those exist only in trusted and some are under "sys_config"; also missing is the popping of STREAMS anchors. Direct access is under "net_rawaccess" which seems to be a more logical location. Name sys_nfs Allows a process to start a kernel NFS daemon. Allows a process to start and stop a kernel NFS lock manager daemon. Allows a process to export directories for use by NFS clients. Allows a process to retrieve the NFS file handle for a path name. Allows a process to revoke NFS RPC credentials for a client it does not own. Since these are all kernel private interfaces, I've changed this description to: Allows a process to perform Sun private NFS specific system calls. Allows a process to bind to bind to NFS reserved ports: ports 2049 (nfs) and port 4045 (lockd). gw-25 To add more privs than pre-reserved seems to require a kernel recompile. How many spare privileges will there be? Will that be enough for Trusted Solaris? The are currently 40 privileges with room for 24 more. This might not be sufficient for Trusted Solaris. The parts of the kernel that need to be recompiled when growing privilege set sizes are limited to around 5 kernel source files; a project to make the Solaris kernel "Trusted Solaris Ready" would likely put these into a separate kernel module. gw-26 gw-9 from inception, how do daemons add privileges? Equivalent of priv_getbyname(9F) PRIV_ALLOC. At this time, the project does not support adding privileges by user processes though a Project Private interface to do so exist. (modctl(MODALLOCPRIV)) White Board Issues - gcs-1. forced priv via setgid - used in initial delivery Page 17: You talk about using setgid bit as a way of forcing privileges for an application. Are you going to deliver any applications that advantage of that? If so, what are the compatibility impact? We will not deliver SGID/PRIV emulation. ---------------------------------------------------------------------------- gcs-2. NOCD: explain You talk about NOCD being applied to a process. What is that? The NOCD flag takes it name from "no core dumps allowed"; initially, coredumps weren't allowed if ruid != euid or rgid != egid. But it was soon discovered that we really needed to remember whether that was ever the case in the past or even whether the process performed any uid changes; so NOCD was added as a flag to the kernel to indicate "the uids/gids mismatched at one time; the process changed uids at one time". This flag was then also used by the /proc interface to disallow attaching to processes with the flag set. We extend the meaning of NOCD to indicate "privileges were lowered". We have added the explanation in a footnote. ---------------------------------------------------------------------------- gcs-3. sysconf for priv.config You talk about interfaces for figuring out what the privileged configuration is. Should that really be a sysconf thing rather than a separate set of system calls? perhaps, but sysconfig() can only return a long int; a far cry from the amount of information we need to deliver. ---------------------------------------------------------------------------- gcs-4. nit: (p28) taxonomy for cred_t We have changed the wording somewhat. ---------------------------------------------------------------------------- gcs-5. dblk change: ramifications beyond sockets There have been many dblk changes in the past that did not require change elsewhere; this is no different. The extra information is carried around but not used. (This issue was considered resolved after code inspection) ---------------------------------------------------------------------------- gcs-6. NIT: priv_debug in i/F table (/etc/system) priv_debug as an /etc/system variable ought to be in your interface taxonomy. Added as Unstable ---------------------------------------------------------------------------- gcs-7. NIT: devpolicy in /sbin In your manpage for devpolicy you show it being in /sbin instead of /usr/sbin. Is that deliberate? If so, please explain. It should have been /sbin as it is needed on boot directly. it has now been removed. per agt-16 ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- rmc-6. integration with projects Is this integrated with projects only so one reference to a project? Can I set a default set of privileges that all of the processes and projects would be able to get so that if I'm trying to set it across an entire application or work load I don't have to do something else? Is that possible? After some discussion, the real issue appeared to be "logical grouping" of privileges. Other input suggested that "maxpriv" as a user attribute was not a tenable solution. The solution for these two problems is to add a "privs=" attribute to profiles. This allows users to have, e.g., the "Real Time" profile which would allow them to obtain the privileges for Real Time use on the system through pfexec. ------- =_aaaaaaaaaa0-- From sacadmin Fri Jan 3 08:18:44 2003 To: psarc@sac.eng.sun.com Subject: 2002/188 Least privilege Cc: least-priv@sun.com X-Phone: +31 33 4515283 (x15283) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <2232.1041610687.0@holland> Date: Fri, 03 Jan 2003 17:18:15 +0100 From: Casper Dik Content-Length: 30441 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2232.1041610687.1@holland> Happy New Year to all, Responses to the issues raised at commitment. Previously send to psarc-record by mistake in November; this is a slightly updated version (incorporating some minor changes as a result of the ongoing code review) A new version of the big document is forthcoming next week; I will try to make a changebar version of the document, but it will not be complete as all LaTeX change bar tools appear to have considerable trouble with the interface tables and Verbatim inputs. The changebar'ed document will most likely have changebars on the ordinary text; no changebars on the tables and changebars included in the Verbatim input text files themselves (i.e., a different changebar format for the documents in the appendix and boxes) ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2232.1041610687.2@holland> Content-Description: changes The following is a summary of the changes made as a result of the commitment review and following discussions: - Device policy: - /sbin/devpolicy was removed as a separate command; its functionaility was incoporated in devfsadm - device_policy(4) and extra_privs(4) were made Project Private the extra_privs(4) syntax was changed and privileges defined in it are now more tightly coupled with drivers. - update_drv/add_drv/rem_drv are now the only supported interfaces to edit privilege specific information in device_policy(4) and extra_privs(4) - Assigning privileges to users/RBAC. - the maxpriv user_attr entry, PRIV_MAX policy.conf entry have been removed - a new /etc/security/prof_attr keyword was added: "privs=". this allows grouping of privileges in profiles, e.g., an "Database" (allow memory locking) or Real TIme (priocntl, high resolution timers) - the working of the "pfexec -P" command was changed to merge the privileges from a user's profile and not obtain them from user_attr. (A user gets to use the union of all privileges defined in all profiles he can use) - the code now falls back to "suser" rather than converting everything to "solaris". New entries which use privileges are defined as "solaris" entries. This allows exec_attr to be shared using name services between old and new systems - privileges - PRIV_SYS_PSET - renamed to PRIV_SYS_CPU_CONFIG - PRIV_SYS_CPU_CONFIG - takes CPU configuration privileges from SYS_CONFIG - Kernel interfaces - crgetref() was added for NFS - crnetadjust() was added privately for NFS - supgroupmember() - checks member ship only against the sup. groups, not the effective gid. [needed for exec] - lwpstatis:pr_errpriv - last failed privilege in system call execution - new aux vector: AT_SUN_AUXFLAGS values: AF_SUN_SETUGID - dblk_t layout was changed as result of the code review: - the unused db_ftflw was reused for db_credp - the undocumented fields were changed to recover the slack in the structure; net result was a 8 byte smaller structure (bot 32 and 64 bits) DB_CRED() new macro DB_CREDDEF() new macro - new streams functions: allocb_cred (allocate with a cred argument) allocb_tmpl (allocate with an mblk template argument) mblk_setcred() - Userland interfaces: - /etc/security/priv_names New file; maps privileges to descriptive text as found in privileges(5); localized versions should exist. - char *priv_gettext(const char *priv) Returns privilege descriptive text from priv_names [localized] - ucred_t type changed to "struct ucred_s" - priv_set_t type changed (no longer void) - ucred_* functions now take a const ucred_t * argument (except free, of course) - __priv_bracket()/__priv_reqinquish helper functions for __init_suid_priv(); make privilege bracketing *much* simpler especially for rcmd(3socket) programs which get this for free through libsocket. - Utility changes. - ppriv -l - list all privileges - ppriv -l -v [priv ...] - list privileges + descriptive text. - truss - output last failed privilege in error message - Runtime linker: - use AT_SUN_AUXFLAGS ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2232.1041610687.3@holland> Content-Description: issues2.respone PSARC 2002/188 Privileges for Solaris Commitment review 16 October 2002 tcm-4 I'm still confused about how the set of privileges can evolve. Is the Basic Priv scheme equivalent to haveing priviledges entitled Permits all the actions not covered by any other priviledge as of version N permanently for all N where any program is entitled to the one for the version it was built against No - new functionality may introduce new privileges which process will not have unless they require all privileges. Basic privileges allow changing current unprivileged operations to require a basic privilege. The version of the privilege specification against which a process is compiled is not recorded; this would go against the principle that the application code is independent of the kernel interfaces and privilege definitions and would require ISVs to make code changes when they recompile for a new release. agt-7 If one of the goals is to allow deployment of realtime applications without PRIV_SYS_CONFIG, you should add a separate privilege for the p_online functionality (or add it to PRIV_SYS_PSET; this is commonly used to block interrupts to selected CPUs. Answer: we have resolved this issue by defining PRIV_SYS_CPU_CONFIG; it takes the p_online() parts of sys_config and replaces sys_pset. agt-8 3.5: I'm not sure I understand the requirement of full privileges for controlling or modifying uid 0 things. Why is this necessary if the controlling process is euid 0, and the controlled process has a limit set that is a subset of that of the controlling process? If a process has euid 0 it can modify any configuration file, include /etc/passwd, /etc/shadow, /etc/user_attr. The document said so, but the wording could be better (and was fixed). agt-9 4.3: What are the compatibility and performance implications of the dblk_t change? Sounds like at least the behavior of socket and bind may change. Performance implications: the project is currently undergoing Perfpit tests, this is not a PSARC issue. Compatibility changes: the credential at bind time is now in force. This fixes a security hole; the credential at socket time is now ignored. This gives the original 4.x BSD socket behaviour. Changes in dblk type: the dblk is opaque; we're not touching or moving the public fields. An existing TLI security hole is plugged. agt-10 4.11: I assume the 660 permissions on /dev/ip are there for a reason, do we know the implications of taking away access for group sys? Who is currently taking advantage of this? "netstat" is taking advantage of this. I believe group sys access to /dev/ip is a security hole. We identified two more public domain tools that use the Solaris MIB; one a perl module which opens a specific device (the sample code uses /dev/tcp); I have communicated with the auther and have given him the better sequence: /dev/arp, push tcp, push udp A C module was found and the author determine he was in group sys so he never noticed the restriction; his code was changed to use /dev/arp and different sequence of I_PUSH modules as well. We have found no reference of the use of /dev/ip for obtaining kernel MIBs or the fact that you need group "sys". We also found one more security hole in the IP stack; this time in the routing sockets. The new dblk frame work allows for easy fixing. agt-11 Any other potentially incompatible changes to device permissions planned? The permissions of a number of mode 600 devices is relaxed to mode 666 in order to properly support privileges for networking. Another incompatbile change is that chmod 666 /dev/*mem no longer works; you will also need to update the device policy in that case. agt-12 I'm not clear on the purpose of extra_privs(4). As a result of PSARC discussions, we have made both extra_privs(4) and device_policy(4) undocumented; the extra_privs(4) file is now used only for privileges associated with devices, using a : syntax; privileges are only loaded from that file is the associated major device is known to the kernel. The privilege is removed when rem_drv is called (or update_drv) The rationale for having these in a seperate file is two fold: - allows privileges to be known to the kernel prior to a device being loaded. (This is useful when a daemon that is associated with a device starts before the device is opened and wants to enable the device specific privilege prior to opening the device; but it's not until the open() that the device driver is loaded and the privilege allocated) - guards against typos on the add_drv/update_drv command line when using exising privileges (clearly add_drv -P could still cause a typo) agt-13 The answer to gw-9 (inception) talks about allowing customers to define privileges, but I don't see any interfaces for supporting that. Did I miss them? extra_privs; priv_getbyname(..., PRIV_ALLOC) [inside the kernel] In its initial release, we are not making a user mode privilege allocation interface public except through the "add_drv/update_drv -P" option. agt-14 Why make the format of device_policy public? If the *_drv utilities should be used for updates, why allow "vi" access as well? It will not be documented. agt-15 I don't understand the purpose of the -I flag to devpolicy(1M). Is this just to push the file into the kernel on boot? (If so, see agt-16.) Yes. but see agt-16 agt-16 Why isn't the device_policy file managed by devfsadm, like other device configuration files? To resolve this issue, the devpolicy(1m) command was removed and its functionality incorporated into devfsadm. agt-17 The -p option to add_drv should take multiple comma-separated policies (like -m) since a single driver can have multiple policies. The policies are white space separated as in "example 1" in add_drv(1m). The parser can tell "foo=bar" and "minorname" apart so it can find where tokens end and a new minor name starts a new policy. Other tokens where considered but most are valid in device names or privilege set specifications. Note that the add_drv command fails to set minor permissions for devices that contain a ","; on my desktop, 1118 minor names have a ",", 234 do not. The project team believes that a "," seperator is wrong for "-m" as well. jdc-1 What happens with kill(2)? One of the hidden assumptions of a setuid program is that no ordinary user can send it a signal. A process that has instead some acquired privileges seems to lack that protection. I see a privilege to control someone sending a signal, but how do I (as the person converting a setuid root application to a PA application) prevent reception from an untrusted user? The restriction on sending signals are not as strict as those on modifying processes; set-uid processes have some protection but as long as they run on a terminal or don't change effective, real and saved uid, they can still be killed. [ Because of the lack of real world examples of this case, this issue is considered resolved ] jdc-2 Nit: using 'void' for ucred_t disables some lint checks; suggest blind structure tag instead ('struct ucred_s; typedef struct ucred_s ucred_t;'). Or even a typedef that is itself a pointer so that you have 'uid_t ucred_geteuid(ucred_t);'. (The latter, I think, encourages good developer hygiene.) This nit was resolved by changing the typedef to "struct ucred_s"; similarly, priv_set_t is no longer defined a a "void". jdc-3 Nit: (response to inception gw-27) 'Evolving' implies 'Public'. jdc-4 Nit: 4.4: private details aren't Unstable unless we're telling customers about them, so secpolicy* is (possibly) Consolidation Private for now. (And should be in the tables.) It is consolidation private. It was added to the tables. jdc-5 6.2: Type of 'Private' for priv_impl.h (and others)? Consolidation or Project? Project. rmc-1 Rationale for overloading EPERM at the expense of delivering cryptic error messages to end users. Is there a compatible way to extend the error namespace or deliver more meaningful errors via perror()? No; error numbers and messages are defined in the standard; we made the occasional error in converting the code (EACCES for EPERM and such); this was immediately flagged by standards conformance checks. rmc-2 Are we adding an ISM privilege? Since this is equivalent to an uncontrolled mlock(), we could conceivably add another privilege or enhance ISM to use PRIV_PROC_LOCK_MEMORY. This could be a basic privilege but we are not considering it at this time. Such change should certainly be made if the standard shared memory restrictions that require /etc/system changes are removed. rmc-3 Should ppriv allow the system administrator to list the full set of privilege options that can be applied to a process? We have now added the command: ppriv -l ppriv -l -v (list verbosely) the latter builds on a new interface: char *priv_gettext(const char *priv); which returns a *localized* string describing the privilege. rmc-4 How can I write an administration application that is aware of the privilege options that can be applied, and is able to adopt and expanded set without recompiling the application? I don't set how the namespace is dynamically discoverable... See the example in priv_names(3c) Privileges start and 0 and have a contiguous name space; getting all privileges is done through: for (i = 0; (str = priv_getbynum(i)) != NULL; i++) ; rmc-5 The truss command will be the first place an administrator is likely to go to debug a privilege issue. Can we enhance truss to understand and print privilege debugging information at the time of a system call? Privilege manipulations will likely deny truss further control of the process; generally truss can be used to determine EACCES/EPERM messages; the privilege debugging output will be in lockstep with the system call return. However, being sensitive to this point, we have changed truss and the /proc interfaces as follows: the lwpstatus structure was expanded with the field "pr_badpriv" when a process is subjected to syscall tracing, this field will be set to PRIV_NONE on syscall entry and in the privilege error code it will be set to the misising privilege which can also be PRIV_ALL (privilege escalation prevention) or PRIV_MULTIPLE (device policy). The truss output is changed to look like: open64("/etc/shadow", O_RDONLY) Err#13 EACCES [file_dac_read] and the truss manual page is modified to document this fact. gw-1 It still seems to me that processes with privilege should be restricted to the "secure" libraries. I don't see that this proposal does so. What am I missing? The question is best answered with a question: Is root restricted to using secure libraries? The restriction is enforced when there's a transition of privilege level from low to high; when no transition takes place, programs are at liberty to load libraries. The implementation of this is using issetugid() which is extended to mean "a transition to more privileges took place". A new linker aux field is introduced, AT_SUN_AUXFLAGS and we define one bit of this flag word, AF_SUN_SETUGID. It is used by the linker to determine "secure mode" without having to shadow algorithms inside the kernel. (Inadvertendly ommitted from the PSARC case materials originally) gw-2 Missed the point of boot, inetd, allocate, cron rights profiles. Noted for a future implementation. In the few daemons we have examined we found that the typical use is not but more one of ; a rights profiles is primarily usable for privileges which are permanent. gw-3 prochasprocperm is not documented. Maybe it should be in ddi_cred(9). Neither are any of the other kernel private functions. I will document them in the spec. gw-4 How will programmers know to use sec_policy* or add new ones? How will they know to use privileges in apps? For now, these are consolidation private interfaces. They know which privileges applications need by studying manual pages where these will be documented. A separate document will be produced for filesystem authors. gw-5 3.1 Page 15 last paragraph, is there a difference between basic and default privileges? The default privilege can include file_chown_self; basic does not include file_chown_self gw-6 forced privilege emulation? What's the proposal? Set-uid root. None other. gw-7 How does a process become pa in the presence of inheritable privs (page 18)? What are those privileges? Left over from previous version. It does not become PA. The sentence was removed. gw-8 3.3.3 last para (-1). Note with allowed privs the idea is to pass privs around non priv apps from grandparent to grandchild across a parent which cannot use any privs. How will this restriction work in that light? The process that cannot use privileges will not be able to set LD_* variables that affect the child process that runs with more privileges. gw-9 States: the prototype's privileges are listed in privileges(5). What are the proposed privileges? Are they the same as the prototype? Yes. references to prototype have been edited out. gw-10 Taxonomy of /etc/system variables. "Unstable" gw-11 Seems hard to have daemons run as user daemon if they will support diskless. How will it be determined which daemons can run without uid == 0? (3.5 and 3.8) There is no difference between diskless and ordinary operation except when the user runs as a non uid 0 uid *and* requires any of the file* privileges. None of the daemons that no longer run as uid 0 require these privileges. So the way to determine whether a daemon can run safely with a uid other than 0 is defined as "needs any of the file* privs". gw-12 Will QFS be supported? QFS will work but will use uid 0; it should be converted to use the new interfaces. We have written a document which explains how to convert a filesystem to privileges. The changes we made will cause filesystem to fail to compile because of the credential hiding employed. gw-13 What does it mean for sys_config to be evolving ans sys_suser_compat to be obsolete? Where is this noted in the public taxonomy? The only reason why sys_suser_compat is obsolete is that the suser() function is obsolete as noted in the drv_priv() manual page. The privilege is self is stable but will gain less use over time. gw-14 user_attr(4) can suser and solaris co-exist? When is one selected over the other? The library will prefer "solaris" but will fall back to "suser" New "solaris" entries are added when they use privileges; new entries which do not use privilege can still use "suser" which allows them to be seen by systems running older releases. gw-15 Will the UIs enforce defaultpriv <= limitpriv; maxpriv <= limitpriv? Yes. (maxpriv was dropped in the spec in favour of profile based privileges, see rmc-6 gw-16 How will it be made safe for programs like su, dtsession if the user has a reduced limit set. It seems I could lockscreen and never be able to get out of lockscreen. I'm very concerned that limitpriv will be a call generator. The use of limitpriv is already documented as possibly having unintended side effects; users can get into the same bind using ppriv(1) or setppriv(2) directly. A program like "su" will fail in pam_setcred(). In the two years left for Solaris 10 we will undertake to study privileged applications and determine which privileges they require; applications will then be changed to enforce this on startup, also limiting the privileges actually used by those applications. In future, when the filesystem supports forced privileges, an application will fail to run if its forced set is not a subset of the limit set. gw-17 I'd prefer device_policy(4) be project private. There are CLIs to administer it. It is classified as unstable. Why even expose it as an administrative interface? It's intended to be project private; the documentation is provided for PSARC use only. gw-18 Why is extra_privs(4) needed? It seems to me that when device_policy gets loaded into the kernel, new privileges listed there could be defined. Extra_privs is Project Private. Only privileges attached to devices are allowed. For the reasons of its existance see agt-12 gw-19 I don't understand file_setdac relative to file_setid. Just changing the file permissions is of a different order than allowing the creation of set-uid executables. This was copied directly from TS. gw-20 proc_set_id seems to be missing: Allows a process to set the process group of a controlling terminal to one not in the process' process group. Allows a process to set the window size on a terminal not in its session. How are these controlled? These always return EPERM, even for privileged processes in Solaris; there doesn't appear to be a reason to change this. gw-21 sys_devices seems incomplete: Allows a process to create device special files. Allows a process to use mknod(2) to create directory and regular files. Allows a process to revoke all access to a device special file. Allows a process to reassign a controlling terminal from one process to another. Allows a process to open a terminal already exclusively opened. Allows a process to revoke access to its controlling terminal. Allows a process to enable or disable keyboard abort processing. Allows a process to map frame buffer devices into its address space. Allows a process to enable or disable a disk's write-check capability. Allows a process to load a kernel loadable driver. Allows a process to control the Floating Point Accelerator. Allows a process to configure autopush STREAMS modules. Allows a process to configure the device driver policy table. Allows a process to successfully call a third party loadable module that calls DDI drv_priv. Some of these are sys_config (abort enabling/disabling does not feel at home under devices) Configuring the device driver policy table requires all privileges. I don't think we still have supported floating point accelerators; there are no restrictions on mapping framebuffers as there are no such restrictions in Solaris proper other than the fact that the DAC attributes are changes to reflect the user using the console. So the entry is complete. gw-22 sys_fs_config, sys_max_proc, sys_min_free seem to be missing. How are their functions restricted. Name sys_fs_config Allows a process to manipulate filesystem locks. Allows a process to set/clear the automatic update (delayed I/O) state of a filesystem. Allows a process to get meta disk allocation information. Allows a pro- cess to open a specified inode in a filesystem. Allows a process to set the last access time of a file system object. Name sys_maxproc Allows a process to create processes when the maximum number of processes for this process' owning user is exceeded. Allows a process to create the last avail- able process in the system. Name sys_minfree Allows a process to write to a filesystem whose avail- able storage space is below the minimum allowed. These functions do not appear to warrant their own privileges so they're lumped in with other privileges, mostly sys_resources and sys_config. gw-23 sys_mount seems incomplete: Allows a process to determine the users of a filesystem. It does not give such access. That operation is not restricted in Solaris no basic privilege was defined for this operation at this time. gw-24 sys_net_config and sys_nfs seem incomplete: Name sys_net_config Allows a process to configure a machine's network interfaces and routes. Allows a process to set a machine's host and domain names. Allows a process to set a machine's kerberos realm. Allows a process to load and unload host type, accreditation, and default information. Allows a process direct access to network devices. Allows a process to set endpoint names. Allows a process to use the rpcmod STREAMS module. Because part of those exist only in trusted and some are under "sys_config"; also missing is the popping of STREAMS anchors. Direct access is under "net_rawaccess" which seems to be a more logical location. Name sys_nfs Allows a process to start a kernel NFS daemon. Allows a process to start and stop a kernel NFS lock manager daemon. Allows a process to export directories for use by NFS clients. Allows a process to retrieve the NFS file handle for a path name. Allows a process to revoke NFS RPC credentials for a client it does not own. Since these are all kernel private interfaces, we've changed this description to: Allows a process to perform Sun private NFS specific system calls. Allows a process to bind to bind to NFS reserved ports: ports 2049 (nfs) and port 4045 (lockd). gw-25 To add more privs than pre-reserved seems to require a kernel recompile. How many spare privileges will there be? Will that be enough for Trusted Solaris? The are currently 40 privileges with room for 24 more. This might not be sufficient for Trusted Solaris. The parts of the kernel that need to be recompiled when growing privilege set sizes are limited to around 5 kernel source files; a project to make the Solaris kernel "Trusted Solaris Ready" would likely put these into a separate kernel module. gw-26 gw-9 from inception, how do daemons add privileges? Equivalent of priv_getbyname(9F) PRIV_ALLOC. At this time, the project does not support adding privileges by user processes though a Project Private interface to do so exist. (modctl(MODALLOCPRIV)) White Board Issues - gcs-1. forced priv via setgid - used in initial delivery Page 17: You talk about using setgid bit as a way of forcing privileges for an application. Are you going to deliver any applications that advantage of that? If so, what are the compatibility impact? We will not deliver SGID/PRIV emulation. ---------------------------------------------------------------------------- gcs-2. NOCD: explain You talk about NOCD being applied to a process. What is that? The NOCD flag takes it name from "no core dumps allowed"; initially, coredumps weren't allowed if ruid != euid or rgid != egid. But it was soon discovered that we really needed to remember whether that was ever the case in the past or even whether the process performed any uid changes; so NOCD was added as a flag to the kernel to indicate "the uids/gids mismatched at one time; the process changed uids at one time". This flag was then also used by the /proc interface to disallow attaching to processes with the flag set. We extend the meaning of NOCD to indicate "privileges were lowered". We have added the explanation in a footnote. ---------------------------------------------------------------------------- gcs-3. sysconf for priv.config You talk about interfaces for figuring out what the privileged configuration is. Should that really be a sysconf thing rather than a separate set of system calls? perhaps, but sysconfig() can only return a long int; a far cry from the amount of information we need to deliver. If you mean "sysinfo()" then perhaps that is a better interface, but it has the following drawbacks; it returns a string, not an array of bytes it documents adding a NUL byte when count is not big enough the manual documents "257" bytes as a good guess for a buffer size; not enough for the privilege implementation ---------------------------------------------------------------------------- gcs-4. nit: (p28) taxonomy for cred_t We have changed the wording somewhat. ---------------------------------------------------------------------------- gcs-5. dblk change: ramifications beyond sockets There have been many dblk changes in the past that did not require change elsewhere; this is no different. The extra information is carried around but not used. (This issue was considered resolved after code inspection) ---------------------------------------------------------------------------- gcs-6. NIT: priv_debug in i/F table (/etc/system) priv_debug as an /etc/system variable ought to be in your interface taxonomy. Added as Unstable ---------------------------------------------------------------------------- gcs-7. NIT: devpolicy in /sbin In your manpage for devpolicy you show it being in /sbin instead of /usr/sbin. Is that deliberate? If so, please explain. It should have been /sbin as it is needed on boot directly. But it has now been removed per agt-16 ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- rmc-6. integration with projects Is this integrated with projects only so one reference to a project? Can I set a default set of privileges that all of the processes and projects would be able to get so that if I'm trying to set it across an entire application or work load I don't have to do something else? Is that possible? After some discussion, the real issue appeared to be "logical grouping" of privileges. Other input suggested that "maxpriv" as a user attribute was not a tenable solution. The solution for these two problems is to add a "privs=" attribute to profiles. This allows users to have, e.g., the "Real Time" profile which would allow them to obtain the privileges for Real Time use on the system through pfexec. ------- =_aaaaaaaaaa0-- From sacadmin Sun Feb 16 17:33:29 2003 Date: Sun, 16 Feb 2003 17:32:31 -0800 From: Andrew Tucker To: psarc@sac.eng.sun.com Cc: casper.dik@sun.com Subject: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Content-Length: 16541 Please review by February 25. The final version of the materials (in final.materials in the case directory) has some minor updates to address comments made at the last review: - crset*, crgetref, and allocb_cred are now Consolidation Private - spec includes a man page for allocb_tmpl - type of flags argument for priv_getbyname is now uint_t Postscript and HTML formats are in the case directory. +------------------------------------------------------------------------+ | Sun Microsystems Systems Architecture Committee | +----------+-------------------------------------------------------------+ | Subject |Least Privilege for Solaris | +----------+-------------------------------------------------------------+ |Submitted |Casper Dik | | by | | +----------+-------------------------------------------------------------+ | File |PSARC/2002/188/opinion.html | +----------+-------------------------------------------------------------+ | Date |January 15th, 2003 | +----------+-------------------------------------------------------------+ |Committee |Andrew Tucker, Ralph Campbell, James Carlson, Joseph | | |Kowalski, Richard McDougall, Terrence Miller, Glenn Skinner. | +----------+-------------------------------------------------------------+ | Steering |Solaris PAC | |Committee | | +----------+-------------------------------------------------------------+ 1. Summary This project adds support for fine-grained process privileges to Solaris. This allows processes to perform certain privileged operations, such as binding to a reserved port, without having full root privileges. It also allows the powers of root processes to be restricted to a subset of those normally available. 2. Decision & Precedence Information The project is approved as specified in reference [1], but as modified by the required technical changes listed in Appendix A. The project may be delivered in a minor release of Solaris. 3. Interfaces +------------------------------------------------------------------------+ | Interfaces Exported | +-------------------------------------------+--------------+-------------+ | Interface Name |Classification| Comment | +-------------------------------------------+--------------+-------------+ |/etc/security/extra_privs |Project |Additional | | |Private |privileges | +-------------------------------------------+--------------+-------------+ |/etc/security/device_policy |Project |Device | | |Private |privilege | | | |file | +-------------------------------------------+--------------+-------------+ |/etc/security/priv_names {LC_MESSAGES dir}/|Stable |Support files| |priv_names | |for | | | |priv_gettext | +-------------------------------------------+--------------+-------------+ |/usr/include/priv.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/include/ucred.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/include/sys/priv.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/include/sys/priv_names.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/include/sys/policy.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/bin/ppriv |Invocation: |Process | | |Evolving |privilege | | |Output: |utility | | |Unstable | | +-------------------------------------------+--------------+-------------+ |setppriv getppriv |Evolving |Functions to | | | |set/get | | | |privilege set| +-------------------------------------------+--------------+-------------+ |setpflags getpflags |Evolving |Functions to | | | |set/get | | | |process flags| +-------------------------------------------+--------------+-------------+ |priv_str_to_set priv_set_to_str |Evolving |Privilege | |priv_getbyname priv_getbynum | |name | |priv_getsetbyname priv_getsetbynum | |functions | |priv_gettext | | | +-------------------------------------------+--------------+-------------+ |priv_set priv_ineffect |Evolving |Functions to | | | |set/check | | | |privileges | +-------------------------------------------+--------------+-------------+ |priv_allocset priv_freeset priv_emptyset |Evolving |Privilege set| |priv_fillset priv_isemptyset priv_isfullset| |manipulation | |priv_isequalset priv_issubset | |functions | |priv_intersect priv_union priv_inverse | | | |priv_addset priv_copyset priv_delset | | | |priv_ismember | | | +-------------------------------------------+--------------+-------------+ |ucred_get ucred_free ucred_geteuid |Evolving |Credential | |ucred_getruid ucred_getsuid ucred_getegid | |access | |ucred_getrgid ucred_getsgid ucred_getgroups| |functions | |ucred_getprivset ucred_getpid | | | |ucred_getpflags | | | +-------------------------------------------+--------------+-------------+ |door_ucred(3DOOR) |Evolving |Returns door | | | |client | | | |credential | +-------------------------------------------+--------------+-------------+ |Privilege constants |Stable |See [1] for | | | |list | +-------------------------------------------+--------------+-------------+ |MODSETDEVPOLICY MODGETDEVPOLICY |Project |modctl | |MODALLOCPRIV |Private |subcommands | +-------------------------------------------+--------------+-------------+ |AUE_SETPPRIV AUE_MODDEVPLCY |Stable |New audit | |AUE_MODALLOCPRIV | |events | +-------------------------------------------+--------------+-------------+ |NT_PRPRIV NT_PRPRIVINFO |Stable |New ELF notes| +-------------------------------------------+--------------+-------------+ |AT_SUN_AUXFLAGS AT_SUN_SETUGID |Consolidation |New aux | | |Private |vector | | | |attributes | +-------------------------------------------+--------------+-------------+ |SYS_privsys |Consolidation |New system | | |Private |call entry | | | |point | +-------------------------------------------+--------------+-------------+ |PCSPRIV prpriv_t pr_errpriv |Stable |/proc | | | |privilege | | | |information | +-------------------------------------------+--------------+-------------+ |DB_CRED DB_CREDDEF |Consolidation |STREAMS | | |Private |macros | +-------------------------------------------+--------------+-------------+ |allocb_tmpl |Evolving |Kernel | | | |function to | | | |allocate mblk| | | |from template| +-------------------------------------------+--------------+-------------+ |allocb_cred allocb_cred_wait |Consolidation |Kernel | | |Private |function to | | | |allocate mblk| | | |with cred | +-------------------------------------------+--------------+-------------+ |crgetuid crgetruid crgetsuid crgetgid |Evolving |Kernel | |crgetrgid crgetsgid crgetgroups | |functions to | |crgetngroups | |access cred | | | |fields | +-------------------------------------------+--------------+-------------+ |crgetref |Consolidation |Kernel | | |Private |function to | | | |get cred ref | | | |count | +-------------------------------------------+--------------+-------------+ |crsetuid crsetruid crsetsuid crsetgid |Consolidation |Kernel | |crsetrgid crsetsgid crsetgroups |Private |functions to | |crsetngroups | |set cred | | | |fields | +-------------------------------------------+--------------+-------------+ |mblk_setcred |Consolidation |Kernel | | |Private |function to | | | |set cred in | | | |mblk | +-------------------------------------------+--------------+-------------+ |priv_getbyname |Evolving |Kernel | | | |function to | | | |lookup | | | |privilege | | | |names | +-------------------------------------------+--------------+-------------+ |priv_policy priv_policy_only |Evolving |Kernel | |priv_policy_choice | |functions to | | | |report | | | |privileges | +-------------------------------------------+--------------+-------------+ |secpolicy functions |Consolidation |Kernel | | |Private |functions to | | | |check | | | |security | | | |policies | +-------------------------------------------+--------------+-------------+ |priv_debug |Unstable |/etc/system | | | |variable | +-------------------------------------------+--------------+-------------+ 4. Opinion 4.1 Device Privileges A substantial amount of time was spent discussing how the privileges should affect the access model for devices. Previously, access to privileged operations through devices was restricted by the permission bits on the device node. The introduction of privileges makes this approach seem inadequate, since it continues to associate the ability to perform privileged operations with specific user and group ids rather than with a process-specific privileges. The project team proposed a new device policy file, which allows administrators to define privileges required to access a particular device. This restriction is in addition to the device node permissions. The committee had some concerns about the lack of visibility of the privilege restrictions (the fact that they are not reflected in the device node itself), the completeness of such an approach, the inability to assign distinct privileges to separate device instances with the same minor number, and the lack of clear direction regarding when to use privileges instead of (or in addition to) file permissions. Although this prompted some extended discussion during the review, in the end the committee accepted the proposal given the current technical constraints. The committee was also concerned about the possibility that the change in the permissions model (the imposition of additional restrictions beyond those indicated by the file permissions) would surprise and confuse administrators. This resulted in the TCR listed in Appendix A, requiring the project team to mention this change in the release notes of the Solaris release in which it integrates. 4.2 Visibility of Privilege Restrictions One of the concerns regarding applying privileges to devices is the fact that the privilege restriction isn't visible as an attribute of the device node. Members of the committee suggested that a project to make such visibility possible should be considered for the future. 4.3 Privilege Escalation Prevention The project proposes measures to prevent "privilege escalation", where a process with a subset of privileges is able to gain additional privileges by exercising its privileges. While the project team identified and addressed certain scenarios that allow such escalation, some committee members were concerned that this might not be a comprehensive list. The project team responded that they had attempted to discover all such cases, but that due to the complex interactions in the Solaris kernel others might be possible. As with other security issues, these problems would be fixed when identified. The committee accepted this rationale. 4.4 Distinction between Privileges and Authorizations The similarities between privileges and the authorizations introduced by the Role Based Access Control project [2] prompted some discussion. The project team explained that privileges represent basic system privileges enforced by the kernel, while authorizations represent higher-level capabilities defined by applications. 5. Minority Opinion(s) None. 6. Advisory Information The Solaris PAC is advised to fund a project to improve the visibility of privileges required for device access. Appendices Appendix A: Technical Changes Required 1. Add notice of change to device permissions model to the Solaris release notes. Appendix B: Technical Changes Advised None. Appendix C: Reference Material Unless otherwise stated, path names are relative to the case directory (PSARC/2002/188). 1. final.materials/priv.pdf Design document 2. ../../1997/332/opinion.ps Execution Profiles for Restricted Environments From sacadmin Tue Feb 18 12:47:53 2003 Date: Tue, 18 Feb 2003 12:46:55 -0800 (PST) From: Tim Marsland To: psarc@sac.eng.sun.com, tucker@trinity.eng.sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Cc: casper.dik@sun.com Content-Length: 5112 | 4.1 Device Privileges | | A substantial amount of time was spent discussing how the privileges | should affect the access model for devices. Previously, access to | privileged operations through devices was restricted by the permission | bits on the device node. The introduction of privileges makes this | approach seem inadequate, since it continues to associate the ability to | perform privileged operations with specific user and group ids rather than | with a process-specific privileges. | | The project team proposed a new device policy file, which allows | administrators to define privileges required to access a particular | device. This restriction is in addition to the device node permissions. | The committee had some concerns about the lack of visibility of the | privilege restrictions (the fact that they are not reflected in the device | node itself), the completeness of such an approach, the inability to | assign distinct privileges to separate device instances with the same | minor number, and the lack of clear direction regarding when to use | privileges instead of (or in addition to) file permissions. Although this | prompted some extended discussion during the review, in the end the | committee accepted the proposal given the current technical constraints. Since everyone seems uncomfortable with this approach, perhaps there should be some notes in the opinions about a direction to be explored in lifting the current set of technical constraints? Or even just advice to the SC to create a project to ease them? Presumably we're talking about extended attributes again - say that. Otherwise, I don't see how this will ever be solved. I'm reminded of what an engineer said to me early at my career at Sun (paraphrased) "You get one chance to do it right in the first place, and thousands of opportunities to explain how-it-should- really-work-if-only-we'd-found-the-time, for the next several years". | The committee was also concerned about the possibility that the change in | the permissions model (the imposition of additional restrictions beyond | those indicated by the file permissions) would surprise and confuse | administrators. This resulted in the TCR listed in Appendix A, requiring | the project team to mention this change in the release notes of the | Solaris release in which it integrates. Sounds like it would confuse support people and system architects and developers too :) Which is all a good illustration that we're creating a wart that may become a mess here i.e. "warning: system doesn't follow principle of least surprise." (Yes, I know you can already create more complicated-than-file-permission security policies with drv_priv(), but I don't know of any of them that aren't problematic today mostly because of the violation of least surprise, though at least that's a violation that the Unix world has lived with for at least a decade. I'm not sure that moving some of the problems into a file is helping vs. the next order of confusion it causes :). Presumably, we'll have to put something about the file in the infamous release notes that few ever read (how about the admin guide, or a manpage): |/etc/security/device_policy |Project |Device | | |Private |privilege | | | |file | But we need to tell administrators about it, because we're worried that people (or driver developers, or home-made security-enhancement kits :) will start to add things to it? Is Project Private really the right level here? Is there a follow-on phase of this project planning to eliminate and/or change it, or is it really Consolidation Private? Or if we're going to start using it for drivers for security products is it Sun Private? Or if we're going to expect administrators to begin to rely on its contents, is it really Unstable? | 4.2 Visibility of Privilege Restrictions | | One of the concerns regarding applying privileges to devices is the fact | that the privilege restriction isn't visible as an attribute of the device | node. Members of the committee suggested that a project to make such | visibility possible should be considered for the future. Yeah, like that, but probably a bit more detail, and a bit more formal .. and perhaps a suggestion to the SC as much as to the project team. Finally (though I hesitate to suggest it vs. the effort that should be applied to the extended attributes project), was a device privilege utility analogous to 'getfacl' considered, to allow the security policies applicable to a device node to be examined? And maybe a 'set'-style command too, rather than only having this happen at add_drv time (hmm .. maybe the add_drv part got dropped, since the interface table doesn't mention anything about add_drv being extended ...) If you did that, I might be more convinced that the /etc/security/device_policy and the ambiguously named /etc/security/extra_privs file were just part of the implementation, rather than something to examine/administer. tim From sacadmin Tue Feb 18 13:06:04 2003 To: Tim Marsland cc: psarc@sac.eng.sun.com, tucker@trinity.eng.sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Date: Tue, 18 Feb 2003 22:05:02 +0100 From: Casper Dik Content-Length: 1799 >Since everyone seems uncomfortable with this approach, perhaps there >should be some notes in the opinions about a direction to be explored >in lifting the current set of technical constraints? Or even just >advice to the SC to create a project to ease them? Presumably we're >talking about extended attributes again - say that. We've discussed the issue at length and while the current syntax allows for specific monir numbers rather than just minor names, my most recent discussion with Shudong Zhou resulted in us looking at the device full pathnames; I believe this is the probably the proper solution but we agreed to formulate this as an RFE. >Finally (though I hesitate to suggest it vs. the effort that should be >applied to the extended attributes project), was a device privilege >utility analogous to 'getfacl' considered, to allow the security >policies applicable to a device node to be examined? And maybe a >'set'-style command too, rather than only having this happen at add_drv >time (hmm .. maybe the add_drv part got dropped, since the interface >table doesn't mention anything about add_drv being extended ...) If >you did that, I might be more convinced that the >/etc/security/device_policy and the ambiguously named >/etc/security/extra_privs file were just part of the implementation, >rather than something to examine/administer. A setfacl/getfacl type of approach was considered but cannot be implemented at this time because of lack of persistance in devfs and lack of a "system" file attribute space. update_drv allows setting of configured devices. The device policy model is not one I am particularly proud of but it is needed to solve several issues: networking privileges vs /dev/ip /dev/hme etc special device protection: /dev/kmem, /dev/disk Casper From sacadmin Tue Feb 18 13:29:05 2003 Date: Tue, 18 Feb 2003 13:28:07 -0800 (PST) From: Shudong Zhou Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris To: tpm@lp64.eng.sun.com, Casper.Dik@sun.com Cc: psarc@sac.eng.sun.com, tucker@trinity.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: IgwX0UDcaa2RvBJVinnFKw== Content-Length: 367 I echo Tim's concern. In fact, I'd like to write a minority opinion if it is possible to do so for an intern. Shudong > A setfacl/getfacl type of approach was considered but cannot > be implemented at this time because of lack of persistance in > devfs and lack of a "system" file attribute space. > devfs does support acl as long as the backing ufs supports it. From sacadmin Tue Feb 18 13:48:57 2003 To: Shudong Zhou cc: tpm@lp64.eng.sun.com, psarc@sac.eng.sun.com, tucker@trinity.eng.sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Date: Tue, 18 Feb 2003 22:47:54 +0100 From: Casper Dik Content-Length: 430 >I echo Tim's concern. In fact, I'd like to write a minority opinion >if it is possible to do so for an intern. > >Shudong > >> A setfacl/getfacl type of approach was considered but cannot >> be implemented at this time because of lack of persistance in >> devfs and lack of a "system" file attribute space. >> >devfs does support acl as long as the backing ufs supports it. But not attributes, I'm sure I tested that. Casper From sacadmin Tue Feb 18 13:52:07 2003 Date: Tue, 18 Feb 2003 13:51:08 -0800 (PST) From: Tim Marsland To: tpm@lp64.eng.sun.com, Casper.Dik@Sun.COM Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Cc: psarc@sac.eng.sun.com, tucker@trinity.eng.sun.com Content-Length: 1107 | A setfacl/getfacl type of approach was considered but cannot | be implemented at this time because of lack of persistance in | devfs and lack of a "system" file attribute space. setdevpriv/getdevpriv [hopefully less confusing names] can be based upon your existing databases i.e. for now, they can just be commands that mostly manipulate your files; they don't require any other mechanism to come into existence yet. The point is that they let you hide the implementation of the persistence mechanism so you can (less painfully) change it later. | update_drv allows setting of configured devices. Urk, but probably ok. But I still don't know how I find out about the net effect of the information in all the files and the filesystem, vs. just trying out the operation and seeing what happens (ick). | The device policy model is not one I am particularly proud of but it | is needed to solve several issues: | | networking privileges vs /dev/ip /dev/hme etc | | special device protection: /dev/kmem, /dev/disk If I thought it was easy to do without, I'd have suggested that, don't worry. tim From sacadmin Tue Feb 18 13:53:05 2003 Date: Tue, 18 Feb 2003 13:52:04 -0800 From: Jordan Brown X-Accept-Language: en-US MIME-Version: 1.0 To: Casper Dik , psarc@sac.eng.sun.com Subject: 2002/188 Least Privilege - device access Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 649 I hesitate to jump into this because I haven't been following it, but... It's important to remember that there are two places where device access needs to be "controlled": 1. There needs to be a way to control access to a particular device. 2. There needs to be a way to set the default access for devices of a particular class. Today, these two are expressed via file permissions and /etc/minor_perm. /etc/minor_perm says what the defaults are when a device is first added, and file permissions allow the administrator to arbitrarily change the access rules. Any device access scheme should probably continue to support both of these modes. From what little I know, it seems like the right answer, at least for simple access questions (whether you can open the device, not whether you can issue a particular ioctl), would be to extend ACLs (perhaps using extended attributes) to allow specifying access rules like "must have the FOO privilege to open this device", and to extend /etc/minor_perms to be able to set that sort of access rule. Of course, once you do this you probably find that the same principle applies cleanly to any type of file, not just devices. I'll shut up now, since if I go any further I'll find myself back on the "privileges and RBAC authorizations are the same thing" topic, and that horse is dead. From sacadmin Tue Feb 18 14:09:12 2003 To: Jordan Brown cc: psarc@sac.eng.sun.com Subject: Re: 2002/188 Least Privilege - device access Date: Tue, 18 Feb 2003 23:08:12 +0100 From: Casper Dik Content-Length: 1452 >I hesitate to jump into this because I haven't been following it, but... > >It's important to remember that there are two places where device access >needs to be "controlled": > >1. There needs to be a way to control access to a particular device. >2. There needs to be a way to set the default access for devices of a >particular class. > >Today, these two are expressed via file permissions and >/etc/minor_perm. /etc/minor_perm says what the defaults are when a >device is first added, and file permissions allow the administrator to >arbitrarily change the access rules. > >Any device access scheme should probably continue to support both of >these modes. I agree. >From what little I know, it seems like the right answer, at least for >simple access questions (whether you can open the device, not whether >you can issue a particular ioctl), would be to extend ACLs (perhaps >using extended attributes) to allow specifying access rules like "must >have the FOO privilege to open this device", and to extend >/etc/minor_perms to be able to set that sort of access rule. Of course, >once you do this you probably find that the same principle applies >cleanly to any type of file, not just devices. Interesting suggestion; I seem to remember one other implementation problem: some of the device opens go through spec_open() but not through devfs_open, hence the interposition in spec_open with device policy and not in device_open. Casper From sacadmin Wed Feb 19 09:59:49 2003 Date: Wed, 19 Feb 2003 09:58:50 -0800 From: Andrew Tucker To: casper.dik@sun.com Cc: psarc@sac.eng.sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Content-Length: 1069 On Tue, Feb 18, 2003 at 01:51:08PM -0800, Tim Marsland wrote: > | update_drv allows setting of configured devices. > > Urk, but probably ok. But I still don't know how I find out about the > net effect of the information in all the files and the filesystem, vs. > just trying out the operation and seeing what happens (ick). This does seem to represent a significant hole in the proposal (one that I at least missed previously). Any configuration property should be discoverable through public interfaces; we don't want to force customers (or tools like Explorer) to parse nominally private configuration files to see how a system is configured. There should be a public interface for determining the (configurable) privilege restrictions on a device. add_drv/update_drv provides a way to set the properties, but not to retrieve the current settings. This is separate from the issue of whether there should be a programmatic interface for retrieving this information from the device node; as Tim mentioned, the above issue could be addressed by a utility. Andy From sacadmin Wed Feb 19 10:14:56 2003 To: Andrew Tucker cc: psarc@sac.eng.sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Date: Wed, 19 Feb 2003 19:13:56 +0100 From: Casper Dik Content-Length: 407 >This is separate from the issue of whether there should be a >programmatic interface for retrieving this information from the >device node; as Tim mentioned, the above issue could be addressed >by a utility. This code was dropped when devpolicy(1m) was removed; I was planning to add the functionaility to "devfsadm" but appear to have forgotten. "devfsadm -P"? dump current the device policy. Casper From sacadmin Wed Feb 19 12:20:50 2003 Date: Wed, 19 Feb 2003 12:19:35 -0800 (PST) From: John Danielson Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris To: psarc@sac.eng.sun.com, Casper.Dik@sun.com Cc: gk@on10.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vybbIEftNclMULeVt9o+4Q== Content-Length: 1165 >To: Andrew Tucker >cc: psarc@sac.eng.sun.com >Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris >Date: Wed, 19 Feb 2003 19:13:56 +0100 >From: Casper Dik > > >>This is separate from the issue of whether there should be a >>programmatic interface for retrieving this information from the >>device node; as Tim mentioned, the above issue could be addressed >>by a utility. > >This code was dropped when devpolicy(1m) was removed; I >was planning to add the functionaility to "devfsadm" but >appear to have forgotten. > > "devfsadm -P"? dump current the device policy. > >Casper This project was reviewed at C-team yesterday for integration into s10 and was approved pending AI resolution - this outstanding PSARC discussion was mentioned at the end of the review but the project team felt that there was little risk in moving forward with the integration. It now seems however that there is concern that this gap in the project is more significant than first believed. Putting on my PSARC hat I would like to see this issue resolved prior to the project integrating into s10. - john From sacadmin Wed Feb 19 12:41:41 2003 To: John Danielson cc: psarc@sac.eng.sun.com, gk@on10.eng.sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Date: Wed, 19 Feb 2003 21:40:39 +0100 From: Casper Dik Content-Length: 967 >This project was reviewed at C-team yesterday for integration into s10 >and was approved pending AI resolution - this outstanding PSARC discussion was >mentioned at the end of the review but the project team felt that there >was little risk in moving forward with the integration. > >It now seems however that there is concern that this gap in the project >is more significant than first believed. Putting on my PSARC hat I would >like to see this issue resolved prior to the project integrating into >s10. This was not the issue discussed in the C-team yesterday; it's a different issue altogether. I think it's time to draw a line in the sand; it cannot be the case that new requirement pop up *AFTER* initial PSARC approval; surely this procedures exist not only for getting a decent architecture but also to arrive at a point where the I-team can be sure it is done with the project architecture and can move forward without reopening the ARC case? Casper From sacadmin Wed Feb 19 12:51:47 2003 Date: Wed, 19 Feb 2003 12:50:32 -0800 (PST) From: John Danielson Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris To: Casper.Dik@Sun.COM Cc: psarc@sac.eng.sun.com, gk@on10.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: B2yusYxxeSQeQyfWiJg6PQ== Content-Length: 1320 > >>This project was reviewed at C-team yesterday for integration into s10 >>and was approved pending AI resolution - this outstanding PSARC discussion was >>mentioned at the end of the review but the project team felt that there >>was little risk in moving forward with the integration. >> >>It now seems however that there is concern that this gap in the project >>is more significant than first believed. Putting on my PSARC hat I would >>like to see this issue resolved prior to the project integrating into >>s10. > >This was not the issue discussed in the C-team yesterday; it's a different >issue altogether. > >I think it's time to draw a line in the sand; it cannot be the case >that new requirement pop up *AFTER* initial PSARC approval; surely >this procedures exist not only for getting a decent architecture but >also to arrive at a point where the I-team can be sure it is done >with the project architecture and can move forward without reopening >the ARC case? > >Casper At the end of the review I pointed out "there was a recent discussion on the PSARC opinion" - which is this e-mail thread. And since I was the one who asked the question at the review I think I do know what the issue was :-). All I am asking for is a clear mandate from PSARC that nothing was overlooked. cheers, - john From sacadmin Wed Feb 19 12:55:43 2003 Date: Wed, 19 Feb 2003 12:57:22 -0800 (PST) From: "Joseph E. Kowalski III" Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris To: jhd@stickit.eng.sun.com, Casper.Dik@sun.com Cc: psarc@sac.eng.sun.com, gk@on10.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: nL1i8Wbw52W7BmXhjCaitg== Content-Length: 1262 > I think it's time to draw a line in the sand; it cannot be the case > that new requirement pop up *AFTER* initial PSARC approval; surely > this procedures exist not only for getting a decent architecture but > also to arrive at a point where the I-team can be sure it is done > with the project architecture and can move forward without reopening > the ARC case? That would be nice, if we were infallible. If the C-team review points out a major oversight on the part of the ARC, then its in everyone's best interest (even the project team) to get a proper resolution. I know this sounds like double jeprody. If its just nits that the C-team has found, then yea, we should all just let it go, or at most file a bug against the nit. Is this above or below that line? I don't know because I've not followed this discussion closely enough. Andy,... you seem to be the most senior, active ARC member who chimed in on this (and even said "This does seem to represent a significant hole in the proposal..."). Could you make the call on this? My **guess** is that the C-team should allow this to integrate and that Casper (et.al.) follow-up with an enhancement (in the next couple of months) to address this deficiency. Your miliage may vary.... - jek3 From sacadmin Wed Feb 19 12:57:06 2003 Date: Wed, 19 Feb 2003 20:55:46 +0000 From: Alan Burlison User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2.1) Gecko/20021206 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Casper Dik CC: John Danielson , psarc@sac.eng.sun.com, gk@on10.eng.sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1162 Casper Dik wrote: >>This project was reviewed at C-team yesterday for integration into s10 >>and was approved pending AI resolution - this outstanding PSARC discussion was >>mentioned at the end of the review but the project team felt that there >>was little risk in moving forward with the integration. >> >>It now seems however that there is concern that this gap in the project >>is more significant than first believed. Putting on my PSARC hat I would >>like to see this issue resolved prior to the project integrating into >>s10. > > This was not the issue discussed in the C-team yesterday; it's a different > issue altogether. > > I think it's time to draw a line in the sand; it cannot be the case > that new requirement pop up *AFTER* initial PSARC approval; surely > this procedures exist not only for getting a decent architecture but > also to arrive at a point where the I-team can be sure it is done > with the project architecture and can move forward without reopening > the ARC case? It is not unknown for the cteam to send projects back to PSARC, it has already happened on more than one occasion in this release. -- Alan Burlison -- From sacadmin Wed Feb 19 13:04:11 2003 Date: Wed, 19 Feb 2003 13:05:49 -0800 (PST) From: "Joseph E. Kowalski III" Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris To: jhd@stickit.eng.sun.com, Casper.Dik@sun.com, Joseph.Kowalski@eng.sun.com Cc: psarc@sac.eng.sun.com, gk@on10.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NcIemnHmxJdqCS1NnmFrLw== Content-Length: 361 > Andy,... you seem to be the most senior, active ARC member who chimed in > on this (and even said "This does seem to represent a significant hole in > the proposal..."). Could you make the call on this? I was going to follow-up an suggest that the case owner should make this call. That turns out to be Andy in this case anyway, so no matter.... - jek3 From sacadmin Wed Feb 19 13:50:04 2003 Date: Wed, 19 Feb 2003 13:49:06 -0800 From: Andrew Tucker To: "Joseph E. Kowalski III" Cc: jhd@stickit.eng.sun.com, Casper.Dik@sun.com, psarc@sac.eng.sun.com, gk@on10.eng.sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Content-Length: 1386 On Wed, Feb 19, 2003 at 12:57:22PM -0800, Joseph E. Kowalski III wrote: > > I think it's time to draw a line in the sand; it cannot be the case > > that new requirement pop up *AFTER* initial PSARC approval; surely > > this procedures exist not only for getting a decent architecture but > > also to arrive at a point where the I-team can be sure it is done > > with the project architecture and can move forward without reopening > > the ARC case? > > That would be nice, if we were infallible. > > If the C-team review points out a major oversight on the part of the ARC, > then its in everyone's best interest (even the project team) to get a > proper resolution. I know this sounds like double jeprody. > > If its just nits that the C-team has found, then yea, we should all just > let it go, or at most file a bug against the nit. > > Is this above or below that line? I don't know because I've not followed > this discussion closely enough. Note that in this case the issues were raised by an ARC member (on sabbatical) during PSARC review, not by the C-team (who is just noting the ongoing discussion). > Andy,... you seem to be the most senior, active ARC member who chimed in > on this (and even said "This does seem to represent a significant hole in > the proposal..."). Could you make the call on this? I'll try to resolve this offline with Tim and Casper. Andy From sacadmin Thu Feb 20 09:42:01 2003 Date: Thu, 20 Feb 2003 09:41:30 -0800 (PST) From: Gary Winiger To: psarc@sac.eng.sun.com, tucker@trinity.eng.sun.com, tpm@lp64.eng.sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Cc: casper.dik@sun.com Content-Length: 1502 > |/etc/security/device_policy |Project |Device | > | |Private |privilege | > | | |file | > > But we need to tell administrators about it, because we're worried that > people (or driver developers, or home-made security-enhancement kits :) > will start to add things to it? Is Project Private really the right > level here? Is there a follow-on phase of this project planning to eliminate > and/or change it, or is it really Consolidation Private? Or if we're going > to start using it for drivers for security products is it Sun Private? Or > if we're going to expect administrators to begin to rely on its contents, > is it really Unstable? With fear of muddying the waters -- since I believe I had a review comment that device_policy should be private -- IMHO device_policy is an implementation detail and should not be an interface. The project team had/has "stable" interfaces for creating/managing the association of privileges with device access (the implementation happens to use the device_policy file). Reading the other comments leads me to believe that there may be a missing interface to view the device privilege bindings. I believe there were/are also granularity issues for minors with the same major number. IMO those are unrelated to whether the device_policy file is part of the implementation or is an interface. Gary.. From sacadmin Thu Feb 20 11:17:57 2003 To: Gary Winiger cc: psarc@sac.eng.sun.com, tucker@trinity.eng.sun.com, tpm@lp64.eng.sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Date: Thu, 20 Feb 2003 20:16:54 +0100 From: Casper Dik Content-Length: 3487 >> |/etc/security/device_policy |Project |Device | >> | |Private |privilege | >> | | |file | >> >> But we need to tell administrators about it, because we're worried that >> people (or driver developers, or home-made security-enhancement kits :) >> will start to add things to it? Is Project Private really the right >> level here? Is there a follow-on phase of this project planning to eliminate >> and/or change it, or is it really Consolidation Private? Or if we're going >> to start using it for drivers for security products is it Sun Private? Or >> if we're going to expect administrators to begin to rely on its contents, >> is it really Unstable? > > With fear of muddying the waters -- since I believe I had a review > comment that device_policy should be private -- IMHO device_policy > is an implementation detail and should not be an interface. The > project team had/has "stable" interfaces for creating/managing > the association of privileges with device access (the implementation > happens to use the device_policy file). Reading the other comments > leads me to believe that there may be a missing interface to view > the device privilege bindings. > > I believe there were/are also granularity issues for minors with the > same major number. IMO those are unrelated to whether the > device_policy file is part of the implementation or is an interface. Current proposal: $ getdevpolicy [ more or less cat of /etc/security/device_policy but obtained from the kernel .... ] $ getdevpolicy /dev/ip /dev/ip read_priv_set=net_rawaccess write_priv_set=net_rawaccess man page: System Administration Commands getdevpolicy(1M) NAME getdevpolicy - inspect the system's device policy SYNOPSIS /usr/sbin/devpolicy [device ....] DESCRIPTION When run without arguments, the command outputs the device policy currently in effect to standard output. If arguments are supplied, each argument is treated as a pathname to a device and the device policy in effect for that specific device is printed preceeded by the supplied pathname. USAGE The device policy adds access restrictions over and above the file permissions. EXIT STATUS The following exit values are returned: 0 Successful operation. non-zero An error has occurred. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWcsu | |_____________________________|_____________________________| | Interface stability | | | | | | Invocation | Evolving | | | | | Output | Unstable | |_____________________________|_____________________________| SEE ALSO add_drv(1M), rem_drv(1M), update_drv(1M), attributes(5), priviliges(5), devfs(7FS) SunOS 5.10 Last change: 20 Feb 2003 1 From sacadmin Thu Feb 20 11:40:29 2003 Date: Thu, 20 Feb 2003 11:39:31 -0800 (PST) From: Shudong Zhou Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris To: gww@marduk.eng.sun.com, Casper.Dik@sun.com Cc: psarc@sac.eng.sun.com, tucker@trinity.eng.sun.com, tpm@lp64.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7KMD1w4WOGqcg94lusAtrw== Content-Length: 263 > Current proposal: > > $ getdevpolicy > [ more or less cat of /etc/security/device_policy but obtained from the > kernel .... ] > > $ getdevpolicy /dev/ip > /dev/ip > read_priv_set=net_rawaccess > write_priv_set=net_rawaccess > No setdevpolicy? Shudong From sacadmin Thu Feb 20 11:48:50 2003 Date: Thu, 20 Feb 2003 11:47:50 -0800 (PST) From: Tim Marsland To: gww@marduk.eng.sun.com, Casper.Dik@sun.com, szhou@billybob.eng.sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Cc: psarc@sac.eng.sun.com, tucker@trinity.eng.sun.com, tpm@lp64.eng.sun.com Content-Length: 477 | From szhou@billybob.eng.sun.com Thu Feb 20 11:37 PST 2003 | | > Current proposal: | > | > $ getdevpolicy | > [ more or less cat of /etc/security/device_policy but obtained from the | > kernel .... ] | > | > $ getdevpolicy /dev/ip | > /dev/ip | > read_priv_set=net_rawaccess | > write_priv_set=net_rawaccess | > | | No setdevpolicy? I'm satisfied with the 'update_drv' answer for now, since I don't believe this is going to be something that changes very often. tim From sacadmin Thu Feb 20 11:51:12 2003 To: Shudong Zhou cc: gww@marduk.eng.sun.com, psarc@sac.eng.sun.com, tucker@trinity.eng.sun.com, tpm@lp64.eng.sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Date: Thu, 20 Feb 2003 20:50:06 +0100 From: Casper Dik Content-Length: 539 > >> Current proposal: >> >> $ getdevpolicy >> [ more or less cat of /etc/security/device_policy but obtained from the >> kernel .... ] >> >> $ getdevpolicy /dev/ip >> /dev/ip >> read_priv_set=net_rawaccess >> write_priv_set=net_rawaccess >> > >No setdevpolicy? I believe we had already agreed that PSARC 2002/188 would do without that functionality (insofar not covered with update_drv). The infrastructure doesn't allow it. The device policy does allow settings based on both minor names as well as minor number ranges. Casper From sacadmin Thu Feb 20 11:59:57 2003 To: Tim Marsland cc: gww@marduk.eng.sun.com, szhou@billybob.eng.sun.com, psarc@sac.eng.sun.com, tucker@trinity.eng.sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Date: Thu, 20 Feb 2003 20:58:51 +0100 From: Casper Dik Content-Length: 585 > >| From szhou@billybob.eng.sun.com Thu Feb 20 11:37 PST 2003 >| >| > Current proposal: >| > >| > $ getdevpolicy >| > [ more or less cat of /etc/security/device_policy but obtained from the >| > kernel .... ] >| > >| > $ getdevpolicy /dev/ip >| > /dev/ip >| > read_priv_set=net_rawaccess >| > write_priv_set=net_rawaccess >| > >| >| No setdevpolicy? > >I'm satisfied with the 'update_drv' answer for now, since I don't >believe this is going to be something that changes very often. Does this mean that I've satisfied the C-team AI with the addition of getdevpolicy? Casper From sacadmin Thu Feb 20 12:14:08 2003 Date: Thu, 20 Feb 2003 12:12:51 -0800 (PST) From: John Danielson Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris To: tpm@lp64.eng.sun.com, Casper.Dik@sun.com Cc: gww@marduk.eng.sun.com, szhou@billybob.eng.sun.com, psarc@sac.eng.sun.com, tucker@trinity.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: dMxQqf+4aVpccO+V+FbBmg== Content-Length: 1085 >To: Tim Marsland >cc: gww@marduk.eng.sun.com, szhou@billybob.eng.sun.com, psarc@sac.eng.sun.com, tucker@trinity.eng.sun.com >Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris >Date: Thu, 20 Feb 2003 20:58:51 +0100 >From: Casper Dik > > >> >>| From szhou@billybob.eng.sun.com Thu Feb 20 11:37 PST 2003 >>| >>| > Current proposal: >>| > >>| > $ getdevpolicy >>| > [ more or less cat of /etc/security/device_policy but obtained from the >>| > kernel .... ] >>| > >>| > $ getdevpolicy /dev/ip >>| > /dev/ip >>| > read_priv_set=net_rawaccess >>| > write_priv_set=net_rawaccess >>| > >>| >>| No setdevpolicy? >> >>I'm satisfied with the 'update_drv' answer for now, since I don't >>believe this is going to be something that changes very often. > >Does this mean that I've satisfied the C-team AI with the >addition of getdevpolicy? > >Casper The C-team is statisfied once this has been approved by PSARC. Please update the docs (TPT, commitment plan, etc.) with the addition of this new command. - john From sacadmin Thu Feb 20 12:47:24 2003 Date: Thu, 20 Feb 2003 12:46:22 -0800 (PST) From: Tim Marsland To: tpm@lp64.eng.sun.com, Casper.Dik@Sun.COM Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Cc: gww@marduk.eng.sun.com, szhou@billybob.eng.sun.com, psarc@sac.eng.sun.com, tucker@trinity.eng.sun.com Content-Length: 584 | Does this mean that I've satisfied the C-team AI with the | addition of getdevpolicy? I have no idea - that's John Danielsons call to figure out if the C-team believes that the ARC process is in "paperwork-only" mode yet, or if there is the possibility of further contention at sac-review. Moreover, I think the rest of the ARC has to be sufficiently happy with the revamped opinion that Andy's working on first before I'd think I was done here. Seems highly likely to me, but I'd encourage any other substantive issues that people are sitting on to be brought up now ... tim From sacadmin Fri Feb 21 17:30:30 2003 Date: Fri, 21 Feb 2003 17:29:30 -0800 From: Andrew Tucker To: psarc@sac.eng.sun.com Cc: casper.dik@sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Content-Length: 18959 Here's a revised opinion. The specification in final.materials has been updated to include the getdevpolicy interface. The changes in the opinion are: - Added getdevpolicy and corresponding modctl subcommand to interface table. - Added add_drv, update_drv and pfexec to interface table (these were mistakenly omitted before). - Updated Section 4.1 (Device Privileges) to address the changes in the case and to fix some confusing wording. - Eliminated Section 4.2 (Visibility of Privilege Restrictions) since it was redundant with 4.1. - Added mention of extended attributes to steering committee advice (as a possible direction for improving privilege visibility in devices). Unless there are objections, I'd like to keep the timer rolling on this. Please (re)review by Tuesday, February 25. As before, HTML and Postscript versions are in the case directory. +------------------------------------------------------------------------+ | Sun Microsystems Systems Architecture Committee | +--------------+---------------------------------------------------------+ | Subject |Least Privilege for Solaris | +--------------+---------------------------------------------------------+ | Submitted by |Casper Dik | +--------------+---------------------------------------------------------+ | File |PSARC/2002/188/opinion.html | +--------------+---------------------------------------------------------+ | Date |January 15th, 2003 | +--------------+---------------------------------------------------------+ | Committee |Andrew Tucker, Ralph Campbell, James Carlson, Joseph | | |Kowalski, Richard McDougall, Terrence Miller, Glenn | | |Skinner. | +--------------+---------------------------------------------------------+ | Product |Solaris PAC | | Approval | | | Committee | | +--------------+---------------------------------------------------------+ 1. Summary This project adds support for fine-grained process privileges to Solaris. This allows processes to perform certain privileged operations, such as binding to a reserved port, without having full root privileges. It also allows the powers of root processes to be restricted to a subset of those normally available. 2. Decision & Precedence Information The project is approved as specified in reference [1], but as modified by the required technical changes listed in Appendix A. The project may be delivered in a minor release of Solaris. 3. Interfaces +------------------------------------------------------------------------+ | Interfaces Exported | +-------------------------------------------+--------------+-------------+ | Interface Name |Classification| Comment | +-------------------------------------------+--------------+-------------+ |/etc/security/extra_privs |Project |Additional | | |Private |privileges | +-------------------------------------------+--------------+-------------+ |/etc/security/device_policy |Project |Device | | |Private |privilege | | | |file | +-------------------------------------------+--------------+-------------+ |/etc/security/priv_names {LC_MESSAGES dir}/|Stable |Support files| |priv_names | |for | | | |priv_gettext | +-------------------------------------------+--------------+-------------+ |/usr/include/priv.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/include/ucred.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/include/sys/priv.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/include/sys/priv_names.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/include/sys/policy.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/bin/ppriv |Invocation: |Process | | |Evolving |privilege | | |Output: |utility | | |Unstable | | +-------------------------------------------+--------------+-------------+ |/usr/sbin/getdevpolicy |Invocation: |Device policy| | |Evolving |inspection | | |Output: |utility | | |Unstable | | +-------------------------------------------+--------------+-------------+ |pfexec |Evolving |New -P option| +-------------------------------------------+--------------+-------------+ |add_drv |Evolving |New -p and -P| | | |options | +-------------------------------------------+--------------+-------------+ |update_drv |Evolving |New -p and -P| | | |options | +-------------------------------------------+--------------+-------------+ |setppriv getppriv |Evolving |System calls | | | |to set/get | | | |privilege set| +-------------------------------------------+--------------+-------------+ |setpflags getpflags |Evolving |System calls | | | |to set/get | | | |process flags| +-------------------------------------------+--------------+-------------+ |priv_str_to_set priv_set_to_str |Evolving |Privilege | |priv_getbyname priv_getbynum | |name | |priv_getsetbyname priv_getsetbynum | |functions | |priv_gettext | | | +-------------------------------------------+--------------+-------------+ |priv_set priv_ineffect |Evolving |Functions to | | | |set/check | | | |privileges | +-------------------------------------------+--------------+-------------+ |priv_allocset priv_freeset priv_emptyset |Evolving |Privilege set| |priv_fillset priv_isemptyset priv_isfullset| |manipulation | |priv_isequalset priv_issubset | |functions | |priv_intersect priv_union priv_inverse | | | |priv_addset priv_copyset priv_delset | | | |priv_ismember | | | +-------------------------------------------+--------------+-------------+ |ucred_get ucred_free ucred_geteuid |Evolving |Credential | |ucred_getruid ucred_getsuid ucred_getegid | |access | |ucred_getrgid ucred_getsgid ucred_getgroups| |functions | |ucred_getprivset ucred_getpid | | | |ucred_getpflags | | | +-------------------------------------------+--------------+-------------+ |door_ucred |Evolving |Returns door | | | |client | | | |credential | +-------------------------------------------+--------------+-------------+ |Privilege constants |Stable |See [1] for | | | |list | +-------------------------------------------+--------------+-------------+ |MODSETDEVPOLICY MODGETDEVPOLICY |Project |modctl | |MODALLOCPRIV MODGETDEVTDEVPLCY |Private |subcommands | +-------------------------------------------+--------------+-------------+ |AUE_SETPPRIV AUE_MODDEVPLCY |Stable |New audit | |AUE_MODALLOCPRIV | |events | +-------------------------------------------+--------------+-------------+ |NT_PRPRIV NT_PRPRIVINFO |Stable |New ELF notes| +-------------------------------------------+--------------+-------------+ |AT_SUN_AUXFLAGS AT_SUN_SETUGID |Consolidation |New aux | | |Private |vector | | | |attributes | +-------------------------------------------+--------------+-------------+ |SYS_privsys |Consolidation |New system | | |Private |call entry | | | |point | +-------------------------------------------+--------------+-------------+ |PCSPRIV prpriv_t pr_errpriv |Stable |/proc | | | |privilege | | | |information | +-------------------------------------------+--------------+-------------+ |prof_attr |Evolving |New "privs" | | | |attribute | +-------------------------------------------+--------------+-------------+ |user_attr |Evolving |New | | | |"defaultpriv"| | | |and | | | |"limitpriv" | | | |attributes | +-------------------------------------------+--------------+-------------+ |DB_CRED DB_CREDDEF |Consolidation |STREAMS | | |Private |macros | +-------------------------------------------+--------------+-------------+ |allocb_tmpl |Evolving |Kernel | | | |function to | | | |allocate mblk| | | |from template| +-------------------------------------------+--------------+-------------+ |allocb_cred allocb_cred_wait |Consolidation |Kernel | | |Private |function to | | | |allocate mblk| | | |with cred | +-------------------------------------------+--------------+-------------+ |crgetuid crgetruid crgetsuid crgetgid |Evolving |Kernel | |crgetrgid crgetsgid crgetgroups | |functions to | |crgetngroups | |access cred | | | |fields | +-------------------------------------------+--------------+-------------+ |crgetref |Consolidation |Kernel | | |Private |function to | | | |get cred ref | | | |count | +-------------------------------------------+--------------+-------------+ |crsetuid crsetruid crsetsuid crsetgid |Consolidation |Kernel | |crsetrgid crsetsgid crsetgroups |Private |functions to | |crsetngroups | |set cred | | | |fields | +-------------------------------------------+--------------+-------------+ |mblk_setcred |Consolidation |Kernel | | |Private |function to | | | |set cred in | | | |mblk | +-------------------------------------------+--------------+-------------+ |priv_getbyname |Evolving |Kernel | | | |function to | | | |lookup | | | |privilege | | | |names | +-------------------------------------------+--------------+-------------+ |priv_policy priv_policy_only |Evolving |Kernel | |priv_policy_choice | |functions to | | | |report | | | |privileges | +-------------------------------------------+--------------+-------------+ |secpolicy functions |Consolidation |Kernel | | |Private |functions to | | | |check | | | |security | | | |policies | +-------------------------------------------+--------------+-------------+ |priv_debug |Unstable |/etc/system | | | |variable | +-------------------------------------------+--------------+-------------+ 4. Opinion 4.1 Device Privileges A substantial amount of time was spent discussing how the introduction of privileges should affect the access model for devices. Previously, access to privileged operations through devices was restricted by the permission bits on the device node. The introduction of privileges makes this approach seem inadequate, since it continues to associate the ability to perform privileged operations with specific user and group ids rather than with a process-specific privileges. The project team proposed adding options to add_drv and update_drv to specify device policies, allowing administrators to define the privileges required to access a particular device. This restriction is in addition to the device node permissions. The committee had some concerns about the lack of visibility of the privilege restrictions (particularly the fact that they are not reflected in the device node itself), the completeness of such an approach, the inability to assign distinct privileges to separate device instances with the same minor number, and the lack of clear direction regarding when to use privileges instead of (or in addition to) file permissions. Although this issue prompted some extended discussion during and after the review, in the end the committee accepted the proposal with the addition of a "getdevpolicy" utility to retrieve such information on a per-device (as well as system-wide) basis. See also the steering committee advice in Section 6 regarding future work in this area. The committee was also concerned about the possibility that the change in the permissions model (the imposition of additional restrictions beyond those indicated by the file permissions) would surprise and confuse administrators. This resulted in the TCR listed in Appendix A, requiring the project team to discuss this change in the Solaris release notes as well as other appropriate documentation such as the Writing Device Drivers guide. The documentation should include advice to driver developers regarding when the use of privileges is appropriate. 4.2 Privilege Escalation Prevention The project proposes measures to prevent "privilege escalation", where a process with a subset of privileges is able to gain additional privileges by exercising its privileges. While the project team identified and addressed certain scenarios that allow such escalation, some committee members were concerned that this might not be a comprehensive list. The project team responded that they had attempted to discover all such cases, but that due to the complex interactions in the Solaris kernel others might be possible. As with other security issues, these problems would be fixed when identified. The committee accepted this rationale. 4.3 Distinction between Privileges and Authorizations The similarities between privileges and the authorizations introduced by the Role Based Access Control project [2] prompted some discussion. The project team explained that privileges represent basic system privileges enforced by the kernel, while authorizations represent higher-level capabilities defined by applications. 5. Minority Opinion(s) None. 6. Advisory Information The Solaris PAC is advised to fund a project to improve the visibility of privileges required for device access, possibly through the use of extended attributes [3]. Appendices Appendix A: Technical Changes Required 1. Add notice of the change to the device permissions model to the Solaris release notes. Appendix B: Technical Changes Advised None. Appendix C: Reference Material Unless otherwise stated, path names are relative to the case directory (PSARC/2002/188). 1. final.materials/priv.pdf Design document 2. ../../1997/332/opinion.ps Execution Profiles for Restricted Environments 3. ../../1999/209/opinion.ps Extended File Attributes From sacadmin Tue Feb 25 18:08:45 2003 Date: Tue, 25 Feb 2003 18:07:42 -0800 From: Andrew Tucker To: sac-review@sac.eng.sun.com Cc: casper.dik@sun.com Subject: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Content-Length: 18165 Please review by March 4. Postscript and HTML formats are in the case directory. +------------------------------------------------------------------------+ | Sun Microsystems Systems Architecture Committee | +--------------+---------------------------------------------------------+ | Subject |Least Privilege for Solaris | +--------------+---------------------------------------------------------+ | Submitted by |Casper Dik | +--------------+---------------------------------------------------------+ | File |PSARC/2002/188/opinion.html | +--------------+---------------------------------------------------------+ | Date |January 15th, 2003 | +--------------+---------------------------------------------------------+ | Committee |Andrew Tucker, Ralph Campbell, James Carlson, Joseph | | |Kowalski, Richard McDougall, Terrence Miller, Glenn | | |Skinner. | +--------------+---------------------------------------------------------+ | Product |Solaris PAC | | Approval | | | Committee | | +--------------+---------------------------------------------------------+ 1. Summary This project adds support for fine-grained process privileges to Solaris. This allows processes to perform certain privileged operations, such as binding to a reserved port, without having full root privileges. It also allows the powers of root processes to be restricted to a subset of those normally available. 2. Decision & Precedence Information The project is approved as specified in reference [1], but as modified by the required technical changes listed in Appendix A. The project may be delivered in a minor release of Solaris. 3. Interfaces +------------------------------------------------------------------------+ | Interfaces Exported | +-------------------------------------------+--------------+-------------+ | Interface Name |Classification| Comment | +-------------------------------------------+--------------+-------------+ |/etc/security/extra_privs |Project |Additional | | |Private |privileges | +-------------------------------------------+--------------+-------------+ |/etc/security/device_policy |Project |Device | | |Private |privilege | | | |file | +-------------------------------------------+--------------+-------------+ |/etc/security/priv_names {LC_MESSAGES dir}/|Stable |Support files| |priv_names | |for | | | |priv_gettext | +-------------------------------------------+--------------+-------------+ |/usr/include/priv.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/include/ucred.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/include/sys/priv.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/include/sys/priv_names.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/include/sys/policy.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/bin/ppriv |Invocation: |Process | | |Evolving |privilege | | |Output: |utility | | |Unstable | | +-------------------------------------------+--------------+-------------+ |/usr/sbin/getdevpolicy |Invocation: |Device policy| | |Evolving |inspection | | |Output: |utility | | |Unstable | | +-------------------------------------------+--------------+-------------+ |pfexec |Evolving |New -P option| +-------------------------------------------+--------------+-------------+ |add_drv |Evolving |New -p and -P| | | |options | +-------------------------------------------+--------------+-------------+ |update_drv |Evolving |New -p and -P| | | |options | +-------------------------------------------+--------------+-------------+ |setppriv getppriv |Evolving |System calls | | | |to set/get | | | |privilege set| +-------------------------------------------+--------------+-------------+ |setpflags getpflags |Evolving |System calls | | | |to set/get | | | |process flags| +-------------------------------------------+--------------+-------------+ |priv_str_to_set priv_set_to_str |Evolving |Privilege | |priv_getbyname priv_getbynum | |name | |priv_getsetbyname priv_getsetbynum | |functions | |priv_gettext | | | +-------------------------------------------+--------------+-------------+ |priv_set priv_ineffect |Evolving |Functions to | | | |set/check | | | |privileges | +-------------------------------------------+--------------+-------------+ |priv_allocset priv_freeset priv_emptyset |Evolving |Privilege set| |priv_fillset priv_isemptyset priv_isfullset| |manipulation | |priv_isequalset priv_issubset | |functions | |priv_intersect priv_union priv_inverse | | | |priv_addset priv_copyset priv_delset | | | |priv_ismember | | | +-------------------------------------------+--------------+-------------+ |ucred_get ucred_free ucred_geteuid |Evolving |Credential | |ucred_getruid ucred_getsuid ucred_getegid | |access | |ucred_getrgid ucred_getsgid ucred_getgroups| |functions | |ucred_getprivset ucred_getpid | | | |ucred_getpflags | | | +-------------------------------------------+--------------+-------------+ |door_ucred |Evolving |Returns door | | | |client | | | |credential | +-------------------------------------------+--------------+-------------+ |Privilege constants |Stable |See [1] for | | | |list | +-------------------------------------------+--------------+-------------+ |MODSETDEVPOLICY MODGETDEVPOLICY |Project |modctl | |MODALLOCPRIV MODGETDEVTDEVPLCY |Private |subcommands | +-------------------------------------------+--------------+-------------+ |AUE_SETPPRIV AUE_MODDEVPLCY |Stable |New audit | |AUE_MODALLOCPRIV | |events | +-------------------------------------------+--------------+-------------+ |NT_PRPRIV NT_PRPRIVINFO |Stable |New ELF notes| +-------------------------------------------+--------------+-------------+ |AT_SUN_AUXFLAGS AT_SUN_SETUGID |Consolidation |New aux | | |Private |vector | | | |attributes | +-------------------------------------------+--------------+-------------+ |SYS_privsys |Consolidation |New system | | |Private |call entry | | | |point | +-------------------------------------------+--------------+-------------+ |PCSPRIV prpriv_t pr_errpriv |Stable |/proc | | | |privilege | | | |information | +-------------------------------------------+--------------+-------------+ |prof_attr |Evolving |New "privs" | | | |attribute | +-------------------------------------------+--------------+-------------+ |user_attr |Evolving |New | | | |"defaultpriv"| | | |and | | | |"limitpriv" | | | |attributes | +-------------------------------------------+--------------+-------------+ |DB_CRED DB_CREDDEF |Consolidation |STREAMS | | |Private |macros | +-------------------------------------------+--------------+-------------+ |allocb_tmpl |Evolving |Kernel | | | |function to | | | |allocate mblk| | | |from template| +-------------------------------------------+--------------+-------------+ |allocb_cred allocb_cred_wait |Consolidation |Kernel | | |Private |function to | | | |allocate mblk| | | |with cred | +-------------------------------------------+--------------+-------------+ |crgetuid crgetruid crgetsuid crgetgid |Evolving |Kernel | |crgetrgid crgetsgid crgetgroups | |functions to | |crgetngroups | |access cred | | | |fields | +-------------------------------------------+--------------+-------------+ |crgetref |Consolidation |Kernel | | |Private |function to | | | |get cred ref | | | |count | +-------------------------------------------+--------------+-------------+ |crsetuid crsetruid crsetsuid crsetgid |Consolidation |Kernel | |crsetrgid crsetsgid crsetgroups |Private |functions to | |crsetngroups | |set cred | | | |fields | +-------------------------------------------+--------------+-------------+ |mblk_setcred |Consolidation |Kernel | | |Private |function to | | | |set cred in | | | |mblk | +-------------------------------------------+--------------+-------------+ |priv_getbyname |Evolving |Kernel | | | |function to | | | |lookup | | | |privilege | | | |names | +-------------------------------------------+--------------+-------------+ |priv_policy priv_policy_only |Evolving |Kernel | |priv_policy_choice | |functions to | | | |report | | | |privileges | +-------------------------------------------+--------------+-------------+ |secpolicy functions |Consolidation |Kernel | | |Private |functions to | | | |check | | | |security | | | |policies | +-------------------------------------------+--------------+-------------+ |priv_debug |Unstable |/etc/system | | | |variable | +-------------------------------------------+--------------+-------------+ 4. Opinion 4.1 Device Privileges A substantial amount of time was spent discussing how the introduction of privileges should affect the access model for devices. Previously, access to privileged operations through devices was restricted by the permission bits on the device node. The introduction of privileges makes this approach seem inadequate, since it continues to associate the ability to perform privileged operations with specific user and group ids rather than with a process-specific privileges. The project team proposed adding options to add_drv and update_drv to specify device policies, allowing administrators to define the privileges required to access a particular device. This restriction is in addition to the device node permissions. The committee had some concerns about the lack of visibility of the privilege restrictions (particularly the fact that they are not reflected in the device node itself), the completeness of such an approach, the inability to assign distinct privileges to separate device instances with the same minor number, and the lack of clear direction regarding when to use privileges instead of (or in addition to) file permissions. Although this issue prompted some extended discussion during and after the review, in the end the committee accepted the proposal with the addition of a "getdevpolicy" utility to retrieve such information on a per-device (as well as system-wide) basis. See also the steering committee advice in Section 6 regarding future work in this area. The committee was also concerned about the possibility that the change in the permissions model (the imposition of additional restrictions beyond those indicated by the file permissions) would surprise and confuse administrators. This resulted in the TCR listed in Appendix A, requiring the project team to discuss this change in the Solaris release notes as well as other appropriate documentation such as the Writing Device Drivers guide. The documentation should include advice to driver developers regarding when the use of privileges is appropriate. 4.2 Privilege Escalation Prevention The project proposes measures to prevent "privilege escalation", where a process with a subset of privileges is able to gain additional privileges by exercising its privileges. While the project team identified and addressed certain scenarios that allow such escalation, some committee members were concerned that this might not be a comprehensive list. The project team responded that they had attempted to discover all such cases, but that due to the complex interactions in the Solaris kernel others might be possible. As with other security issues, these problems would be fixed when identified. The committee accepted this rationale. 4.3 Distinction between Privileges and Authorizations The similarities between privileges and the authorizations introduced by the Role Based Access Control project [2] prompted some discussion. The project team explained that privileges represent basic system privileges enforced by the kernel, while authorizations represent higher-level capabilities defined by applications. 5. Minority Opinion(s) None. 6. Advisory Information The Solaris PAC is advised to fund a project to improve the visibility of privileges required for device access, possibly through the use of extended attributes [3]. Appendices Appendix A: Technical Changes Required 1. Add notice of the change to the device permissions model to the Solaris release notes. Appendix B: Technical Changes Advised None. Appendix C: Reference Material Unless otherwise stated, path names are relative to the case directory (PSARC/2002/188). 1. final.materials/priv.pdf Design document 2. ../../1997/332/opinion.ps Execution Profiles for Restricted Environments 3. ../../1999/209/opinion.ps Extended File Attributes From sacadmin Wed Feb 26 13:15:32 2003 Date: Wed, 26 Feb 2003 14:14:26 -0700 From: Henry Knapp User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Tucker CC: sac-review@sac.eng.sun.com, casper.dik@sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 18964 Hello Casper, I suggest expanding the TCR to include adding decriptions of the effect of the new facility to other Solaris documentation, as suggested in Section 4.1. Regards, Henry Andrew Tucker wrote: > Please review by March 4. Postscript and HTML formats are in the > case directory. > > +------------------------------------------------------------------------+ > | Sun Microsystems Systems Architecture Committee | > +--------------+---------------------------------------------------------+ > | Subject |Least Privilege for Solaris | > +--------------+---------------------------------------------------------+ > | Submitted by |Casper Dik | > +--------------+---------------------------------------------------------+ > | File |PSARC/2002/188/opinion.html | > +--------------+---------------------------------------------------------+ > | Date |January 15th, 2003 | > +--------------+---------------------------------------------------------+ > | Committee |Andrew Tucker, Ralph Campbell, James Carlson, Joseph | > | |Kowalski, Richard McDougall, Terrence Miller, Glenn | > | |Skinner. | > +--------------+---------------------------------------------------------+ > | Product |Solaris PAC | > | Approval | | > | Committee | | > +--------------+---------------------------------------------------------+ > > 1. Summary > > This project adds support for fine-grained process privileges to Solaris. > This allows processes to perform certain privileged operations, such as > binding to a reserved port, without having full root privileges. It also > allows the powers of root processes to be restricted to a subset of those > normally available. > > 2. Decision & Precedence Information > > The project is approved as specified in reference [1], but as modified by > the required technical changes listed in Appendix A. The project may be > delivered in a minor release of Solaris. > > 3. Interfaces > > +------------------------------------------------------------------------+ > | Interfaces Exported | > +-------------------------------------------+--------------+-------------+ > | Interface Name |Classification| Comment | > +-------------------------------------------+--------------+-------------+ > |/etc/security/extra_privs |Project |Additional | > | |Private |privileges | > +-------------------------------------------+--------------+-------------+ > |/etc/security/device_policy |Project |Device | > | |Private |privilege | > | | |file | > +-------------------------------------------+--------------+-------------+ > |/etc/security/priv_names {LC_MESSAGES dir}/|Stable |Support files| > |priv_names | |for | > | | |priv_gettext | > +-------------------------------------------+--------------+-------------+ > |/usr/include/priv.h |Stable |Location | > +-------------------------------------------+--------------+-------------+ > |/usr/include/ucred.h |Stable |Location | > +-------------------------------------------+--------------+-------------+ > |/usr/include/sys/priv.h |Stable |Location | > +-------------------------------------------+--------------+-------------+ > |/usr/include/sys/priv_names.h |Stable |Location | > +-------------------------------------------+--------------+-------------+ > |/usr/include/sys/policy.h |Stable |Location | > +-------------------------------------------+--------------+-------------+ > |/usr/bin/ppriv |Invocation: |Process | > | |Evolving |privilege | > | |Output: |utility | > | |Unstable | | > +-------------------------------------------+--------------+-------------+ > |/usr/sbin/getdevpolicy |Invocation: |Device policy| > | |Evolving |inspection | > | |Output: |utility | > | |Unstable | | > +-------------------------------------------+--------------+-------------+ > |pfexec |Evolving |New -P option| > +-------------------------------------------+--------------+-------------+ > |add_drv |Evolving |New -p and -P| > | | |options | > +-------------------------------------------+--------------+-------------+ > |update_drv |Evolving |New -p and -P| > | | |options | > +-------------------------------------------+--------------+-------------+ > |setppriv getppriv |Evolving |System calls | > | | |to set/get | > | | |privilege set| > +-------------------------------------------+--------------+-------------+ > |setpflags getpflags |Evolving |System calls | > | | |to set/get | > | | |process flags| > +-------------------------------------------+--------------+-------------+ > |priv_str_to_set priv_set_to_str |Evolving |Privilege | > |priv_getbyname priv_getbynum | |name | > |priv_getsetbyname priv_getsetbynum | |functions | > |priv_gettext | | | > +-------------------------------------------+--------------+-------------+ > |priv_set priv_ineffect |Evolving |Functions to | > | | |set/check | > | | |privileges | > +-------------------------------------------+--------------+-------------+ > |priv_allocset priv_freeset priv_emptyset |Evolving |Privilege set| > |priv_fillset priv_isemptyset priv_isfullset| |manipulation | > |priv_isequalset priv_issubset | |functions | > |priv_intersect priv_union priv_inverse | | | > |priv_addset priv_copyset priv_delset | | | > |priv_ismember | | | > +-------------------------------------------+--------------+-------------+ > |ucred_get ucred_free ucred_geteuid |Evolving |Credential | > |ucred_getruid ucred_getsuid ucred_getegid | |access | > |ucred_getrgid ucred_getsgid ucred_getgroups| |functions | > |ucred_getprivset ucred_getpid | | | > |ucred_getpflags | | | > +-------------------------------------------+--------------+-------------+ > |door_ucred |Evolving |Returns door | > | | |client | > | | |credential | > +-------------------------------------------+--------------+-------------+ > |Privilege constants |Stable |See [1] for | > | | |list | > +-------------------------------------------+--------------+-------------+ > |MODSETDEVPOLICY MODGETDEVPOLICY |Project |modctl | > |MODALLOCPRIV MODGETDEVTDEVPLCY |Private |subcommands | > +-------------------------------------------+--------------+-------------+ > |AUE_SETPPRIV AUE_MODDEVPLCY |Stable |New audit | > |AUE_MODALLOCPRIV | |events | > +-------------------------------------------+--------------+-------------+ > |NT_PRPRIV NT_PRPRIVINFO |Stable |New ELF notes| > +-------------------------------------------+--------------+-------------+ > |AT_SUN_AUXFLAGS AT_SUN_SETUGID |Consolidation |New aux | > | |Private |vector | > | | |attributes | > +-------------------------------------------+--------------+-------------+ > |SYS_privsys |Consolidation |New system | > | |Private |call entry | > | | |point | > +-------------------------------------------+--------------+-------------+ > |PCSPRIV prpriv_t pr_errpriv |Stable |/proc | > | | |privilege | > | | |information | > +-------------------------------------------+--------------+-------------+ > |prof_attr |Evolving |New "privs" | > | | |attribute | > +-------------------------------------------+--------------+-------------+ > |user_attr |Evolving |New | > | | |"defaultpriv"| > | | |and | > | | |"limitpriv" | > | | |attributes | > +-------------------------------------------+--------------+-------------+ > |DB_CRED DB_CREDDEF |Consolidation |STREAMS | > | |Private |macros | > +-------------------------------------------+--------------+-------------+ > |allocb_tmpl |Evolving |Kernel | > | | |function to | > | | |allocate mblk| > | | |from template| > +-------------------------------------------+--------------+-------------+ > |allocb_cred allocb_cred_wait |Consolidation |Kernel | > | |Private |function to | > | | |allocate mblk| > | | |with cred | > +-------------------------------------------+--------------+-------------+ > |crgetuid crgetruid crgetsuid crgetgid |Evolving |Kernel | > |crgetrgid crgetsgid crgetgroups | |functions to | > |crgetngroups | |access cred | > | | |fields | > +-------------------------------------------+--------------+-------------+ > |crgetref |Consolidation |Kernel | > | |Private |function to | > | | |get cred ref | > | | |count | > +-------------------------------------------+--------------+-------------+ > |crsetuid crsetruid crsetsuid crsetgid |Consolidation |Kernel | > |crsetrgid crsetsgid crsetgroups |Private |functions to | > |crsetngroups | |set cred | > | | |fields | > +-------------------------------------------+--------------+-------------+ > |mblk_setcred |Consolidation |Kernel | > | |Private |function to | > | | |set cred in | > | | |mblk | > +-------------------------------------------+--------------+-------------+ > |priv_getbyname |Evolving |Kernel | > | | |function to | > | | |lookup | > | | |privilege | > | | |names | > +-------------------------------------------+--------------+-------------+ > |priv_policy priv_policy_only |Evolving |Kernel | > |priv_policy_choice | |functions to | > | | |report | > | | |privileges | > +-------------------------------------------+--------------+-------------+ > |secpolicy functions |Consolidation |Kernel | > | |Private |functions to | > | | |check | > | | |security | > | | |policies | > +-------------------------------------------+--------------+-------------+ > |priv_debug |Unstable |/etc/system | > | | |variable | > +-------------------------------------------+--------------+-------------+ > > 4. Opinion > > 4.1 Device Privileges > > A substantial amount of time was spent discussing how the introduction of > privileges should affect the access model for devices. Previously, access > to privileged operations through devices was restricted by the permission > bits on the device node. The introduction of privileges makes this > approach seem inadequate, since it continues to associate the ability to > perform privileged operations with specific user and group ids rather than > with a process-specific privileges. > > The project team proposed adding options to add_drv and update_drv to > specify device policies, allowing administrators to define the privileges > required to access a particular device. This restriction is in addition to > the device node permissions. The committee had some concerns about the > lack of visibility of the privilege restrictions (particularly the fact > that they are not reflected in the device node itself), the completeness > of such an approach, the inability to assign distinct privileges to > separate device instances with the same minor number, and the lack of > clear direction regarding when to use privileges instead of (or in > addition to) file permissions. Although this issue prompted some extended > discussion during and after the review, in the end the committee accepted > the proposal with the addition of a "getdevpolicy" utility to retrieve > such information on a per-device (as well as system-wide) basis. See also > the steering committee advice in Section 6 regarding future work in this > area. > > The committee was also concerned about the possibility that the change in > the permissions model (the imposition of additional restrictions beyond > those indicated by the file permissions) would surprise and confuse > administrators. This resulted in the TCR listed in Appendix A, requiring > the project team to discuss this change in the Solaris release notes as > well as other appropriate documentation such as the Writing Device Drivers > guide. The documentation should include advice to driver developers > regarding when the use of privileges is appropriate. > > 4.2 Privilege Escalation Prevention > > The project proposes measures to prevent "privilege escalation", where a > process with a subset of privileges is able to gain additional privileges > by exercising its privileges. While the project team identified and > addressed certain scenarios that allow such escalation, some committee > members were concerned that this might not be a comprehensive list. The > project team responded that they had attempted to discover all such cases, > but that due to the complex interactions in the Solaris kernel others > might be possible. As with other security issues, these problems would be > fixed when identified. The committee accepted this rationale. > > 4.3 Distinction between Privileges and Authorizations > > The similarities between privileges and the authorizations introduced by > the Role Based Access Control project [2] prompted some discussion. The > project team explained that privileges represent basic system privileges > enforced by the kernel, while authorizations represent higher-level > capabilities defined by applications. > > 5. Minority Opinion(s) > > None. > > 6. Advisory Information > > The Solaris PAC is advised to fund a project to improve the visibility of > privileges required for device access, possibly through the use of > extended attributes [3]. > > Appendices > > Appendix A: Technical Changes Required > > 1. Add notice of the change to the device permissions model to the > Solaris release notes. > > Appendix B: Technical Changes Advised > > None. > > Appendix C: Reference Material > > Unless otherwise stated, path names are relative to the case directory > (PSARC/2002/188). > > > 1. final.materials/priv.pdf Design document > 2. ../../1997/332/opinion.ps Execution Profiles for Restricted > Environments > 3. ../../1999/209/opinion.ps Extended File Attributes > -- From sacadmin Wed Feb 26 13:25:17 2003 To: Henry.Knapp@sun.com cc: Andrew Tucker , sac-review@sac.eng.sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Date: Wed, 26 Feb 2003 22:24:11 +0100 From: Casper Dik Content-Length: 442 >Hello Casper, > >I suggest expanding the TCR to include adding >decriptions of the effect of the new facility >to other Solaris documentation, as suggested >in Section 4.1. You mean in addition to all the changes to the manual pages which reflect the new privilege check? The case materials cover a substantial amount of documentation. So could you be a bit more specific as to what documentation you would like to see changed? Casper From sacadmin Wed Feb 26 14:00:40 2003 Date: Wed, 26 Feb 2003 14:59:34 -0700 From: Henry Knapp User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Casper Dik CC: Andrew Tucker , sac-review@sac.eng.sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 750 Casper Dik wrote: >>Hello Casper, >> >>I suggest expanding the TCR to include adding >>decriptions of the effect of the new facility >>to other Solaris documentation, as suggested >>in Section 4.1. > > > > You mean in addition to all the changes to the manual pages which > reflect the new privilege check? The case materials cover a substantial > amount of documentation. So could you be a bit more specific as to > what documentation you would like to see changed? > > Casper -- Hello Casper, In particular you mention Writing Solaris Device Drivers in section 4.1 of the opinion. I suppose we could add any other documentation likely to be used by folks affected by the change - e.g. system management documentation. Regards, Henry From sacadmin Fri Mar 14 16:00:42 2003 Date: Fri, 14 Mar 2003 15:59:29 -0800 From: Andrew Tucker To: Henry Knapp Cc: Casper Dik , sac-review@sac.eng.sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Content-Length: 1151 On Wed, Feb 26, 2003 at 02:59:34PM -0700, Henry Knapp wrote: > Casper Dik wrote: > >>Hello Casper, > >> > >>I suggest expanding the TCR to include adding > >>decriptions of the effect of the new facility > >>to other Solaris documentation, as suggested > >>in Section 4.1. > > > >You mean in addition to all the changes to the manual pages which > >reflect the new privilege check? The case materials cover a substantial > >amount of documentation. So could you be a bit more specific as to > >what documentation you would like to see changed? > > > >Casper > > In particular you mention Writing Solaris Device Drivers in > section 4.1 of the opinion. I suppose we could add any other > documentation likely to be used by folks affected by the > change - e.g. system management documentation. I realized when going to close this case that this issue was still open... I added the comment about other documentation in response to post-review comments, so this wasn't included in the original TCR. Given the non-specific nature of the comment it doesn't seem appropriate as a TCR --- I'd rather just leave it as advice to the project team. Andy From sacadmin Thu Mar 20 14:38:46 2003 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 20 Mar 2003 17:37:23 -0500 From: James Carlson To: Andrew Tucker Cc: sac-review@sac.eng.sun.com, casper.dik@Sun.Com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Content-Length: 580 Andrew Tucker writes: > 6. Advisory Information > > The Solaris PAC is advised to fund a project to improve the visibility of > privileges required for device access, possibly through the use of > extended attributes [3]. (I know, I'm late as usual.) The meeting minutes record a note about SC advice for NFS support for privileges. Was that an error? -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Fri Mar 21 15:55:12 2003 Date: Fri, 21 Mar 2003 15:53:55 -0800 From: Andrew Tucker To: James Carlson Cc: sac-review@sac.eng.sun.com, casper.dik@Sun.Com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Content-Length: 669 On Thu, Mar 20, 2003 at 05:37:23PM -0500, James Carlson wrote: > Andrew Tucker writes: > > 6. Advisory Information > > > > The Solaris PAC is advised to fund a project to improve the visibility of > > privileges required for device access, possibly through the use of > > extended attributes [3]. > > (I know, I'm late as usual.) > > The meeting minutes record a note about SC advice for NFS support for > privileges. Was that an error? I appear to have inadvertently dropped this, and frankly don't remember the specific issue (something about diskless that came up at the inception review). I'll try to track it down and amend the opinion as appropriate. Andy From sacadmin Sat Mar 22 01:52:58 2003 To: Andrew Tucker cc: James Carlson , sac-review@sac.eng.sun.com Subject: Re: Opinion for review: PSARC/2002/188 Least Privilege for Solaris Date: Sat, 22 Mar 2003 10:51:35 +0100 From: Casper Dik Content-Length: 1751 >On Thu, Mar 20, 2003 at 05:37:23PM -0500, James Carlson wrote: >> Andrew Tucker writes: >> > 6. Advisory Information >> > >> > The Solaris PAC is advised to fund a project to improve the visibility of >> > privileges required for device access, possibly through the use of >> > extended attributes [3]. >> >> (I know, I'm late as usual.) >> >> The meeting minutes record a note about SC advice for NFS support for >> privileges. Was that an error? > >I appear to have inadvertently dropped this, and frankly don't >remember the specific issue (something about diskless that came >up at the inception review). I'll try to track it down and amend >the opinion as appropriate. The issue with NFS is that we cannot send privileges over the wire; this is an issue only in those cases where we currently use root exports (anon=0 or root=....). It concerns the following four privileges: file_dac_execute file_dac_read file_dac_search file_dac_write Case Process type Export type Problem #1 ANY default none #2 uid != 0, anon=0/root= none w/o file* privs #3 uid != 0, anon=0/root= file_dac* privs do not work w/ file* privs #4 uid == 0 anon=0/root= mapped to ALL priv; failure of too w/o file* privs much access. #5 uid == 0 anon=0/root= none w/ file* privs The diskless case falls under the anon=0/root= case; the table implies that we cannot run uid != 0 processes w/ file_* privileges on diskless clients and expect them to work. (And that restricting file_* privileges for uid 0 process on diskless clients also does not work; but that, I think, is a minor matter). #3 is the most problematic one and we should therefor avoid building such processes. Case #3 & #4 do not arise for "legacy" processes. Casper From sacadmin Thu May 1 18:21:18 2003 Date: Thu, 1 May 2003 18:19:31 -0700 From: Andrew Tucker To: psarc@sun.com Cc: casper@holland.sun.com Subject: Revised opinion for PSARC/2002/188 Least Privilege for Solaris Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Content-Length: 19596 Jim noticed that I (inadvertently) omitted a discussion of NFS issues from the least privilege opinion. Although the opinion is nominally "final" (at least it has been sent to sac-opinion), I'm revising it to add the NFS discussion and related PAC advice. The only changes are the addition of Section 4.4 and the second paragraph of Section 6, so there's no need to look at the rest unless you want to find something else I missed. I'll put the usual timer on the revision, please review by 5/8. +------------------------------------------------------------------------+ | Sun Microsystems Systems Architecture Committee | +--------------+---------------------------------------------------------+ | Subject |Least Privilege for Solaris | +--------------+---------------------------------------------------------+ | Submitted by |Casper Dik | +--------------+---------------------------------------------------------+ | File |PSARC/2002/188/opinion.html | +--------------+---------------------------------------------------------+ | Date |January 15th, 2003 | +--------------+---------------------------------------------------------+ | Committee |Andrew Tucker, Ralph Campbell, James Carlson, Joseph | | |Kowalski, Richard McDougall, Terrence Miller, Glenn | | |Skinner. | +--------------+---------------------------------------------------------+ | Product |Solaris PAC | | Approval | | | Committee | | +--------------+---------------------------------------------------------+ 1. Summary This project adds support for fine-grained process privileges to Solaris. This allows processes to perform certain privileged operations, such as binding to a reserved port, without having full root privileges. It also allows the powers of root processes to be restricted to a subset of those normally available. 2. Decision & Precedence Information The project is approved as specified in reference [1], but as modified by the required technical changes listed in Appendix A. The project may be delivered in a minor release of Solaris. 3. Interfaces +------------------------------------------------------------------------+ | Interfaces Exported | +-------------------------------------------+--------------+-------------+ | Interface Name |Classification| Comment | +-------------------------------------------+--------------+-------------+ |/etc/security/extra_privs |Project |Additional | | |Private |privileges | +-------------------------------------------+--------------+-------------+ |/etc/security/device_policy |Project |Device | | |Private |privilege | | | |file | +-------------------------------------------+--------------+-------------+ |/etc/security/priv_names {LC_MESSAGES dir}/|Stable |Support files| |priv_names | |for | | | |priv_gettext | +-------------------------------------------+--------------+-------------+ |/usr/include/priv.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/include/ucred.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/include/sys/priv.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/include/sys/priv_names.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/include/sys/policy.h |Stable |Location | +-------------------------------------------+--------------+-------------+ |/usr/bin/ppriv |Invocation: |Process | | |Evolving |privilege | | |Output: |utility | | |Unstable | | +-------------------------------------------+--------------+-------------+ |/usr/sbin/getdevpolicy |Invocation: |Device policy| | |Evolving |inspection | | |Output: |utility | | |Unstable | | +-------------------------------------------+--------------+-------------+ |pfexec |Evolving |New -P option| +-------------------------------------------+--------------+-------------+ |add_drv |Evolving |New -p and -P| | | |options | +-------------------------------------------+--------------+-------------+ |update_drv |Evolving |New -p and -P| | | |options | +-------------------------------------------+--------------+-------------+ |setppriv getppriv |Evolving |System calls | | | |to set/get | | | |privilege set| +-------------------------------------------+--------------+-------------+ |setpflags getpflags |Evolving |System calls | | | |to set/get | | | |process flags| +-------------------------------------------+--------------+-------------+ |priv_str_to_set priv_set_to_str |Evolving |Privilege | |priv_getbyname priv_getbynum | |name | |priv_getsetbyname priv_getsetbynum | |functions | |priv_gettext | | | +-------------------------------------------+--------------+-------------+ |priv_set priv_ineffect |Evolving |Functions to | | | |set/check | | | |privileges | +-------------------------------------------+--------------+-------------+ |priv_allocset priv_freeset priv_emptyset |Evolving |Privilege set| |priv_fillset priv_isemptyset priv_isfullset| |manipulation | |priv_isequalset priv_issubset | |functions | |priv_intersect priv_union priv_inverse | | | |priv_addset priv_copyset priv_delset | | | |priv_ismember | | | +-------------------------------------------+--------------+-------------+ |ucred_get ucred_free ucred_geteuid |Evolving |Credential | |ucred_getruid ucred_getsuid ucred_getegid | |access | |ucred_getrgid ucred_getsgid ucred_getgroups| |functions | |ucred_getprivset ucred_getpid | | | |ucred_getpflags | | | +-------------------------------------------+--------------+-------------+ |door_ucred |Evolving |Returns door | | | |client | | | |credential | +-------------------------------------------+--------------+-------------+ |Privilege constants |Stable |See [1] for | | | |list | +-------------------------------------------+--------------+-------------+ |MODSETDEVPOLICY MODGETDEVPOLICY |Project |modctl | |MODALLOCPRIV MODGETDEVTDEVPLCY |Private |subcommands | +-------------------------------------------+--------------+-------------+ |AUE_SETPPRIV AUE_MODDEVPLCY |Stable |New audit | |AUE_MODALLOCPRIV | |events | +-------------------------------------------+--------------+-------------+ |NT_PRPRIV NT_PRPRIVINFO |Stable |New ELF notes| +-------------------------------------------+--------------+-------------+ |AT_SUN_AUXFLAGS AT_SUN_SETUGID |Consolidation |New aux | | |Private |vector | | | |attributes | +-------------------------------------------+--------------+-------------+ |SYS_privsys |Consolidation |New system | | |Private |call entry | | | |point | +-------------------------------------------+--------------+-------------+ |PCSPRIV prpriv_t pr_errpriv |Stable |/proc | | | |privilege | | | |information | +-------------------------------------------+--------------+-------------+ |prof_attr |Evolving |New "privs" | | | |attribute | +-------------------------------------------+--------------+-------------+ |user_attr |Evolving |New | | | |"defaultpriv"| | | |and | | | |"limitpriv" | | | |attributes | +-------------------------------------------+--------------+-------------+ |DB_CRED DB_CREDDEF |Consolidation |STREAMS | | |Private |macros | +-------------------------------------------+--------------+-------------+ |allocb_tmpl |Evolving |Kernel | | | |function to | | | |allocate mblk| | | |from template| +-------------------------------------------+--------------+-------------+ |allocb_cred allocb_cred_wait |Consolidation |Kernel | | |Private |function to | | | |allocate mblk| | | |with cred | +-------------------------------------------+--------------+-------------+ |crgetuid crgetruid crgetsuid crgetgid |Evolving |Kernel | |crgetrgid crgetsgid crgetgroups | |functions to | |crgetngroups | |access cred | | | |fields | +-------------------------------------------+--------------+-------------+ |crgetref |Consolidation |Kernel | | |Private |function to | | | |get cred ref | | | |count | +-------------------------------------------+--------------+-------------+ |crsetuid crsetruid crsetsuid crsetgid |Consolidation |Kernel | |crsetrgid crsetsgid crsetgroups |Private |functions to | |crsetngroups | |set cred | | | |fields | +-------------------------------------------+--------------+-------------+ |mblk_setcred |Consolidation |Kernel | | |Private |function to | | | |set cred in | | | |mblk | +-------------------------------------------+--------------+-------------+ |priv_getbyname |Evolving |Kernel | | | |function to | | | |lookup | | | |privilege | | | |names | +-------------------------------------------+--------------+-------------+ |priv_policy priv_policy_only |Evolving |Kernel | |priv_policy_choice | |functions to | | | |report | | | |privileges | +-------------------------------------------+--------------+-------------+ |secpolicy functions |Consolidation |Kernel | | |Private |functions to | | | |check | | | |security | | | |policies | +-------------------------------------------+--------------+-------------+ |priv_debug |Unstable |/etc/system | | | |variable | +-------------------------------------------+--------------+-------------+ 4. Opinion 4.1 Device Privileges A substantial amount of time was spent discussing how the introduction of privileges should affect the access model for devices. Previously, access to privileged operations through devices was restricted by the permission bits on the device node. The introduction of privileges makes this approach seem inadequate, since it continues to associate the ability to perform privileged operations with specific user and group ids rather than with a process-specific privileges. The project team proposed adding options to add_drv and update_drv to specify device policies, allowing administrators to define the privileges required to access a particular device. This restriction is in addition to the device node permissions. The committee had some concerns about the lack of visibility of the privilege restrictions (particularly the fact that they are not reflected in the device node itself), the completeness of such an approach, the inability to assign distinct privileges to separate device instances with the same minor number, and the lack of clear direction regarding when to use privileges instead of (or in addition to) file permissions. Although this issue prompted some extended discussion during and after the review, in the end the committee accepted the proposal with the addition of a "getdevpolicy" utility to retrieve such information on a per-device (as well as system-wide) basis. See also the steering committee advice in Section 6 regarding future work in this area. The committee was also concerned about the possibility that the change in the permissions model (the imposition of additional restrictions beyond those indicated by the file permissions) would surprise and confuse administrators. This resulted in the TCR listed in Appendix A, requiring the project team to discuss this change in the Solaris release notes as well as other appropriate documentation such as the Writing Device Drivers guide. The documentation should include advice to driver developers regarding when the use of privileges is appropriate. 4.2 Privilege Escalation Prevention The project proposes measures to prevent "privilege escalation", where a process with a subset of privileges is able to gain additional privileges by exercising its privileges. While the project team identified and addressed certain scenarios that allow such escalation, some committee members were concerned that this might not be a comprehensive list. The project team responded that they had attempted to discover all such cases, but that due to the complex interactions in the Solaris kernel others might be possible. As with other security issues, these problems would be fixed when identified. The committee accepted this rationale. 4.3 Distinction between Privileges and Authorizations The similarities between privileges and the authorizations introduced by the Role Based Access Control project [2] prompted some discussion. The project team explained that privileges represent basic system privileges enforced by the kernel, while authorizations represent higher-level capabilities defined by applications. 4.4 NFS Support for Privileges This project introduces several file access control privileges, which allow non-root processes to override file ownership and mode settings. Although these privileges will work for files in local file systems, they will not work for files mounted over NFS since NFS has no mechanism for passing privilege information over the wire. This is particularly a concern for diskless client systems, where all file systems are mounted over NFS, and privileged access is often required. Since adding such support would require extensions to the NFS protocol to support passing privilege information, the committee agreed that it was outside the scope of this project, but suggested that the issue be considered in the context of future enhancements to NFS. Section 6 contains advice regarding this issue. 5. Minority Opinion(s) None. 6. Advisory Information The Solaris PAC is advised to fund a project to improve the visibility of privileges required for device access, possibly through the use of extended attributes [3]. The Solaris PAC (or members therein with engineering management responsibilities) is advised to charter a group to investigate how to address the use of fine-grained privileges within NFS. Appendices Appendix A: Technical Changes Required 1. Add notice of the change to the device permissions model to the Solaris release notes. Appendix B: Technical Changes Advised None. Appendix C: Reference Material Unless otherwise stated, path names are relative to the case directory (PSARC/2002/188). 1. final.materials/priv.pdf Design document 2. ../../1997/332/opinion.ps Execution Profiles for Restricted Environments 3. ../../1999/209/opinion.ps Extended File Attributes From gww@sac.sfbay.sun.com Wed Oct 22 14:01:15 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9ML1EYY006857 for ; Wed, 22 Oct 2008 14:01:15 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9ML1D6I014185 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 22 Oct 2008 22:01:14 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9500J0LRQ18A00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 22 Oct 2008 14:01:13 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9500J42RQ05E00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 22 Oct 2008 14:01:12 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9ML1Ap4050396; Wed, 22 Oct 2008 14:01:10 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9ML1A2K006855; Wed, 22 Oct 2008 14:01:10 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m9ML1AcO006854; Wed, 22 Oct 2008 14:01:10 -0700 (PDT) Date: Wed, 22 Oct 2008 14:01:10 -0700 (PDT) From: Gary Winiger Subject: Redacted -- PSARC/2002/188 Least Privilege for Solaris To: psarc-ext@sun.com Cc: casper@holland.sun.com Message-id: <200810222101.m9ML1AcO006854@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 284 I redacted this case today. Presuming I did it correctly, it should be published to the OpenSolaris ARC web site the next time the site update scripts run. I presume John Plocher will contact me if I've not been complete in my recaction as the update scripts won't publish. Gary.. From casper@holland.sun.com Wed Oct 22 15:15:09 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9MMF9uA009191 for ; Wed, 22 Oct 2008 15:15:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9MMEwH9024351 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 22 Oct 2008 15:15:09 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9500203V51XU00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 22 Oct 2008 16:15:01 -0600 (MDT) Received: from dm-holland-01.uk.sun.com ([129.156.101.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9500KFPV4ZLZA0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 22 Oct 2008 16:15:00 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m9MMEwpZ028307; Wed, 22 Oct 2008 23:14:58 +0100 (BST) Date: Thu, 23 Oct 2008 00:14:58 +0200 From: Casper.Dik@sun.com Subject: Re: Redacted -- PSARC/2002/188 Least Privilege for Solaris In-reply-to: <200810222101.m9ML1AcO006854@sac.sfbay.sun.com> Sender: casper@holland.sun.com To: Gary Winiger Cc: psarc-ext@sun.com Message-id: <200810222214.m9MMEwpZ028307@dm-holland-01.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810222101.m9ML1AcO006854@sac.sfbay.sun.com> Status: RO Content-Length: 313 >I redacted this case today. Presuming I did it correctly, it should >be published to the OpenSolaris ARC web site the next time the site >update scripts run. > >I presume John Plocher will contact me if I've not been complete in >my recaction as the update scripts won't publish. Excellent, thanks. Casper