linux security - Dec 1996 - Calls which cross trust boundaries

Many of the security problems we''ve had to deal with recently have
been where one program invokes another when no good level of trust
exists between them.

Currently solutions to this requirement are produced on an ad-hoc
basis, usually involving set-id programs (often setuid root),
superuser daemons calling user programs for `upcalls'', or both.

There are problems with this approach.  Unix processes inherit an
awful lot from their parent, making it difficult even for
security-aware programmers to write safe set-id code.  Daemons which
need to do something `as the user'' have to be root most of the time,
so that they are able to gain access to the users'' accounts.

I have for a while been thinking about a mechanism to help alleviate
this problem.  With it it will no longer be necessary to give root
privilege to MTA''s, cron and at, lpr (even with delayed copy out of
the user''s filespace).  Most buffer overrun problems in programs like
`crontab'' will no longer be security holes, and almost all of the rest
will only allow access to the subsystem in question and not lead to a
root compromise.  CGI programs can easily be made to run as something
other than the webserver user.

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/O is handled by setting up pipes which cross the security boundary.

Obviously the client and server need to be written carefully, but at
least the attention can be concentrated there.

I''ve written a specification for this facility, and am working on an
implementation.  The spec can be found at:
 ftp://ftp.chiark.greenend.org.uk/users/ijackson/userv/spec.sgml.gz
 http://www.chiark.greenend.org.uk/~ijackson/userv/spec.html/
 ftp://ftp.chiark.greenend.org.uk/users/ijackson/userv/spec.ps.gz
 ftp://ftp.chiark.greenend.org.uk/users/ijackson/userv/spec.text.gz
 ftp://ftp.chiark.greenend.org.uk/users/ijackson/userv/spec.textov.gz

Ian.

[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.       |
              +------------------------------------------------------------+