[1530] in linux-security and linux-alert archive
[linux-security] Re: Re: Re: Re: Buffer Overflows: A Summary
daemon@ATHENA.MIT.EDU (Stefan Monnier)
Mon May 5 18:08:28 1997
To: linux-security@redhat.com
From: Stefan Monnier <monnier+/news/lists/linux/security@TEQUILA.SYSTEMSZ.CS.YALE.EDU>
Date: 05 May 1997 12:23:05 -0400
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
Phexro <ieure@linknet.kitsap.lib.wa.us> writes:
> chroot()'d processes. So, important system calls could be modified thus:
Since there are tons of syscalls and new ones appearing all the time, "Fixing"
some of them doesn't seem like a good idea. It seems more reasonbale to deny
access to all of them, except for a few specific ones (that can moreover be
modified so as to limit their strength). Still, it would be a big hassle
and probably not worth it.
> [mod: We thought about this, and always Linus could come up with
> another way to break out of the "jail". Feel free to delve in and
I'm fairly convinced that to really get something reasonable, you need to
totally redesign the OS with this "virtual machine" in mind. Several research
projects follow such a path (with further expectation also, of course).
[mod: Yes. One "catchall" would be to modify "suser()" to return
(uid==0) && (current->root == THE_ROOT). That would make a uid==0 in a
chrooted environment just another user. Just with a special uid. But
still you would have to review the WHOLE system to be sure that no
holes remain.... --REW]
Stefan
