[m-dev.] Libraries Idea

[Fergus Henderson]

On 22-Sep-1999, Warwick Harvey <wharvey at cs.monash.edu.au> wrote:
> Peter Schachte wrote:
> > Isn't there some way to do this under unix?  All it needs is a way to
> > have files that can be read by anybody but can only be written by one
> > program.  It seems like a simple enough request, someone must have
> > solved this before.
> 
> Yes, setuid basically does that.  The problem is avoiding that one "program" 
> (in this case a raft of programs under the management of a top-level script) 
> being faked out or subverted by outside influences.

Yes.  Since there are as you say a raft of programs, many of which are
out of our control, avoiding this could be tricky.

> We can probably narrow the problem down a bit.  E.g. suppose we can assume 
> that the build process can be started as intended (i.e. as the sysadmin 
> would start it, so ignoring external influences such as environment variable 
> settings).  Then one could argue that we need not address for these purposes 
> issues such as insecure use of temp files, etc., because the current method 
> (sysadmin installs) is also vulnerable to these, even if the timing is not a 
> bit easier.

We fixed all of our known vulnerabilities due to insecure use of temp files
on 1998/03/30.  So the current process should not be vulnerable to those.

> So then the question becomes how we make sure the program is invoked as the 
> sysadmin intended.  The main problem here (though there may be others) is 
> that the Mercury build process makes extensive use of things like 
> environment variables for configuring what it does, how and where.  The 
> possibility of these things affecting the build process needs to be plugged 
> in a reliable way that isn't going to be inadvertently broken as Mercury 
> develops.

Yes.  At very least, the setuid wrapper program would need to
	- reset the environment to a known value
	- reset the uid, so that called programs cannot look for configuration
	  files in the invoking users home directory
	- reset the current directory
	- reset the umask
There may be other things needed here.

> If there is a single server process which handles all of this, then that 
> probably goes a long way toward making sure the build environment is 
> "clean".  It may even "solve" the problem (no suid executables would be 
> needed in any event).  But I have little experience with writing this kind 
> of server, so I cannot comment all that much more on security/practicality 
> issues.

I think this approach has far fewer potential flaws.

> Possible problems with the server approach:
> - You want to be able to handle the case where the server dies for some 
> reason.

The standard solution here is to start the server from inetd
by adding an entry in /etc/inetd.conf.  Then inetd will restart
the server whenever someone tries to make a connection on the socket,
unless it is already running.

However, that solution conflicts with your second goal:

> - You want an "average user" to be able to run a server, not just a sysadmin.

For average users, one rather imperfect way to handle that is to add a
`crontab' entry that restarts the server every now and then. If the server
is already running, then any attempt to start another server will result
in an error because the port is already in use, so you don't have to worry
about two servers running at the same time.

The only other alternative, I think, is use a setuid program to start the
server, and in that case, you have all the risks of a setuid program, so you
might as well just do it all in the setuid program and forget about the
server.

> Hmmm, what happens when one gets a build error with this stuff?  Probably 
> just say tough luck and contact the person responsible...

Another issue: what happens when the sources were installed on one machine
but we discover that the library grade is needed on another machine that
NFS-mounts the same file system?  Should it attempt to make the grade
on the same machine that the user is working on, or should it connect
to the server on the original installation machine?

Well, personally I am going to put all those worms back in the can,
and continue working on other tasks that IMHO are more important
and/or less difficult.  But if anyone is really keen and wants to
have a go at this, they're most welcome.  The security problems
don't need to be addressed first-off -- for the first version,
we could just document it as something that should only be used
in an environment where you can trust the other users of that system.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------