Re: Re : Bounds-checking gcc ..:In message <199702181830.KAA24561@flea.best.net> Matt Dillon writes:
There is a quite a bit of real gain.. It takes work to secure
an suid program? Of course it does! You have to do these things
anyway if you want an suid program to be truely secure, requiring
it only formalizes it. i.e. it means that programmers who would
otherwise have no understanding of what 'suid' means would be
required to actually *learn* something before writing an suid
program.
It's better to take an approach similar to the firewall approach...
if firewalls are turned on, the *default* operation is to disallow
all packet traffic, period. The default operation is to err on
the side securedness.
The same approach ought to be taken for suid programs.
The default should be 'secure', requiring the program to explicitly
state what it wants, not 'insecure', where any joe programmer can
say 'gee, I'll just make this program suid and not worry about the
consequences'. The logistical problems are minor.
--
There are a number of ways we can do this... for example, the
startup code could, by default, clear the environment if the
program was run suid, re-setting it with minimal values and
a basic PATH. Fuck the LD_* stuff... those environment variables
should never have existed in the first place. If anything, the library
load path should be an inherited system resources of some sort. It
could store the original envp in an accessible location allowing the main
program to 'restore' those environment variable that it explicitly needs.
The startup code could also check the resource set if the program
is run suid and exit if the resources are not considered
'reasonable'.
This would not require a system call to 'enable' suid operation,
but it would require suid programs to explicitly specify which
(if any) third party environment variables they want to pass through.
-Matt
Matthew Dillon Engineering, BEST Internet Communications, Inc.
<dillon@best.net>
[always include a portion of the original email in any response!]
Received on Tue Feb 18 10:57:47 1997
This archive was generated by hypermail 2.1.8
: Wed Aug 23 2006 - 12:41:02 EDT
|
