Date: Thu, 12 Apr 2001 00:38:39 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: jon@licq.org Cc: tmm@FreeBSD.org, Eivind Eklund <eivind@FreeBSD.org>, arch@FreeBSD.org Subject: Re: suser security Message-ID: <Pine.NEB.3.96L.1010411222312.97516F-100000@fledge.watson.org> In-Reply-To: <20010327132808.B14068@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 Mar 2001, Eivind Eklund wrote: > > Last year I was working on changing the uid compares to 0 to suser() calls. > > I lost direct internet access for a period of time so was unable to keep > > current with the tree. Anyways, I have time and resources to work on it > > again and saw that it was still on the list of things to do. I also found > > my notes on what files needed patched, the other day when I was cleaning my > > room up. > > > > So just let me know if it's still needed. Perhaps you can tell me what you > > would like suser() to do? I remember you mentioned a logging facility I > > believe. I could work on that part as well, since obviously the changing to > > suser isn't much of a challenge. > > The point was that suser() takes a process argument, and logs which > processes have used superuser capabilities (ie, have needed the call to > suser()). This was relevant at the point the entry was added to the > TODO list, but I'm not sure it is relevant now. > > Robert Watson <rwatson@FreeBSD.org> (Cc'ed) is working on adding ACLs > and process capabilities to FreeBSD. This work touches the same areas, > and I am not quite sure how it will interact. I think it might be > better to coordinate this with him. Jon, Sorry for the delay in getting back to you -- things are, as always, pretty busy around here and I've been slipping up on my e-mail. Eivind is correct in pointing out that a number of pieces of work are on-going which affect the suser/privilege-related code, including the implementation of POSIX.1e Capabilities as part of the TrustedBSD Project. Currently Thomas Moestl is working on that implementation, so I've CC'd this message to him also. I've also CC'd the trustedbsd-discuss mailing list, since there's a fair amount of architectural commentary here that others might be interested in commenting on. Here are a few comments on the ideas expressed in your and Eivind's messages: 1) There remain a number of places in the kernel where the credential or process effective uid is directly compared with 0, rather than making use of the suser() or suser_xxx() primitives. The reason for this is interesting, and actually related to one of your other points. Originally, suser() set the ASU process accounting flag when it was invoked, in an attempt to account for use of superuser privilege. However, the goal was that this flag only be set when privilege was actually employed, not when it was tested, so rather than use suser() in situations where it was tested but not necessarily employed, manual tests were performed. Consider, for example, some of the compound security checks performed in the UFS code: privilege can be used to override some but not all of the checks (such as system file flags under securelevel>0). Rather than call suser early in the check and set ASU incorrectly, the caller would manually test. Clearly, this is a problem, as it means that the security primitives are not used, resulting in inconsistent implementations throughout the kernel. In the capability implementation, instances of suser() and suser_xxx() are being replaced with the cap_check() call, which checks the passed process or credential for specific POSIX.1e privileges; as such, it is now necessary to replace the remaining direct uid checks with calls to cap_check(), as suser() will no longer be used in most situations. In my first implementation of the Capability code, I broke out the setting of the ASU bit from the suser() call and placed it in a seperate primitive, suser_used(p); this allowed calls to be made to suser() without incorrectly setting the ASU bit. In doing this, I discovered that the ASU bit was frequently misused throughout the tree already, especially in the network code where often a single invocation of suser() is made, and then the result cached for later use deeper in the stack. On realizing this, I proposed an alternative strategy: for the time being, we would disable the ASU functionality, since it is infrequently (if at all) used, and was incorrect in many situations anyway. In the second capability implementation, currently being worked on by Thomas, it is assumed that ASU no longe needs to be maintained, substantially simplifying the code (if you look in 5.0-CURRENT, you'll note that various authorization calls are careful to return a "privileged used" result via an optional call-by-reference privused pointer so that the caller can then use suser_used(), which in turn introduces complexity). I suspect that Thomas has caught most of the remaining uid calls, but once he publishes the next version of the capability patch, we'd welcome your work on it to catch remaining instances, and to comment on correctness. 2) The second point that is raised in your and Eivind's e-mails is that of introducing additional logging behavior in suser(). As I've mentioned above, there are a number of substantial technical and philosophical reasons why this might be a bad idea, especially relating to seperating the checking of privilege and the actual use of privilege to perform an operation during a compound access control check. However, the fact that this particular approach may not be the best one doesn't mean that the service is not leaded: one of the (thus far under-visited) goals of the TrustedBSD project is to provide some form of fine-grained event auditing; this audit log would be more useful if it did allow the auditing of the use of privilege (without capabilities, simply the necessary invocation of superuser privileges, but with privileges, also an indication of which privileges were required, if any, for the operation to succeed). Andrew Reiter has been preparing an auditing subsystem requirements document, as well as descriptions of implementations on other platforms so that we can go through a more informed design process. Having partially implemented auditing on FreeBSD twice in the past, I can comment both on the complexity of correct implemetation, and the need to be sensitive to issues of simplicity, maintainability, and performance. Taking a fairly deep look into other implementations will be important to developing an audit implementation that can be accepted by the FreeBSD community. This is certainly an area where both your contributions in the form of ideas and implementation would be most welcome. In any case, I'd greatly welcome your participation in improving the security and correctness of FreeBSD, and invite you to join the TrustedBSD mailing lists since TrustedBSD seems to be the current source of many of the types of changes you're considering implementing. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010411222312.97516F-100000>