suser security

[Robert Watson]

(I actually neglected to send this message to trustedbsd-discuss, so am
redirecting it there also.)

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 at 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 at fledge.watson.org      NAI Labs, Safeport Network Services



To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message