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.
John Saunders
1996-Dec-20 03:14 UTC
Re: [linux-security] Calls which cross trust boundaries
[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. | +------------------------------------------------------------+