Re: [linux-security] Calls which cross trust boundaries

[john nlc net au (John Saunders)]

[Mod: I am no longer going to approve the individual messages on this
topic as they arrive as at this stage it is not really linux related stuff.
But still the discussion is rather interesting so I will post a bunch of
them at the same time after say... 3-4 days?  Is it okay with everybody 
--alex]

Ian Jackson (ian chiark greenend org uk) wrote:
> My scheme involves a daemon which runs as root, and a setuid-root
> client program.  The client is invoked when a service of some kind is
> required, and arguments to it specify which user is to supply the
> service and which service is expected.  The client connects to the
> daemon using an AF_UNIX socket and passes it the details of the
> request.  The daemon reads a set of system and per-user configuration
> files, decides whether to allow or deny the request, and if the
> request is allowed invokes (as the `serving' user) the actual program
> which is to provide the service (as specified in the configuration
> files).

I suppose the obvious question is, what about buffer overrun bugs and other
such things in the daemon? Would a client be able to somehow spoof the
daemon into giving root privs to some program that shouldn't get it? You
might say that the daemon would be written such that it had no bugs that
could be exploited. I'm sure Paul Vixie thought that about crontab.

[Mod: there was a project that Matt Bishop from UCD Comp. Security Lab was
working on a while ago. I believe that it was determined that such aproach
is not terribly realistic. It was the conclusion that UNIX really needs a
machanism which would allow a program to be able to get a priv. in a
_section_ of a code while making other parts run with normal priviledge-- alex]

After all that negativeness (Not about your idea which I think would be
good) I think you should have a go and see what you can do. One thing I
would suggest is that the daemon be made very small, very simple, and
very very paranoid. I would be interested if you can come up with a
workable solution, Unix security is something that needs a fresh new
approach.

One other approach would be a system call that you would pass a username
and password to, if they are correct the kernel would change the process
uid and gid to that of the user. The actual checking of the password
could be done by calling out to a process much like kerneld. That way the
responsibility of checking username/passwords is outside of the program,
and the program never has to run as root. That would eliminate a large
class of programs that are setuid root simply to be able to change to
a user once the username/password has been verified.

[Mod: The only problem is... who said that username/password is the only
methods of establishing credentials? -- alex]

Cheers.
--            +------------------------------------------------------------+
        .     | John Saunders  - mailto:john nlc net au            (EMail) |
    ,--_|\    |                - http://www.nlc.net.au/              (WWW) |
   /  Oz  \   |                - 018-223-814 or 02-9477-2881       (Phone) |
   \_,--\_/   | NHJ NORTHLINK COMMUNICATIONS - Supplying a professional,   |
         v    | and above all friendly, internet connection service.       |
              +------------------------------------------------------------+