[m-dev.] Libraries Idea

[Warwick Harvey]

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.

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.

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.

> Race conditions can be avoided by having a single process
> coordinate the building and accept requests for more objects to build.

These weren't the race conditions I was referring to (I was thinking more of 
traditional /tmp attacks), but yes, good point, I hadn't thought about those.

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.  (Hmm, the expression "X font server" just sprang to mind --- does 
that do something similar, or does it just sound as though it does?)

Possible problems with the server approach:
- You want to be able to handle the case where the server dies for some 
reason.
- You want an "average user" to be able to run a server, not just a sysadmin.


An alternative to the server approach would be to have some kind of setuid 
wrapper program which filters all external influences before invoking the 
build script, using locking to make sure only one grade build is attempted 
at a time.


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


Anyway, time for my disclaimer.  I'm not a security expert, only an 
interested amateur who just reached his depth limit.  :-)

Warwick

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------