Russ Allbery <[EMAIL PROTECTED]> writes on 8 September 1999 at 16:13:46 -0700
> Ken Jones <[EMAIL PROTECTED]> writes:
>
> > The best solution i've seen is to group all the programs that are
> > possible security holes, like in.telnet and compilers, to a new
> > group. And only allow members of that group to execute the programs.
>
> If you go that direction, you don't want to do it that way. Instead, you
> group all the programs that you're pretty sure *aren't* possible security
> holes and you remove people's ability to execute anything else.
>
> And as other people mentioned, if you take this route, you also need to
> make sure that your users don't have write access to any file system
> mounted without -noexec. And make sure that they can't execute any
> interpretor, since you can execute interpreted programs even from a
> -noexec file system. And... um... they'd better not have shell access
> then. And....
I've seen discussion on BUGTRAQ recently pointing out that you can
often use ld.so to execute things on non-executable partitions, and
people saying that noexec shouldn't be considered a security
mechanism. If it ain't a security mechanism, I haven't a clue what it
could be good for. If it isn't a *working* security mechanism, it
should either be fixed or removed; as long as it's sitting there,
people will try to use it as a security mechanism.
Another way around it I've thought of is that, if you have a shell
account, with many shells you can "source" a script without that
script having to be executable. Since you can write nearly anything
as a shell script, this gives yet another way to get around
restrictions.
> This isn't an easy thing to do.
As you say.
--
David Dyer-Bennet ***NOTE ADDRESS CHANGES*** [EMAIL PROTECTED]
http://dd-b.lighthunters.net/ (photos) Minicon: http://www.mnstf.org/minicon
http://www.dd-b.net/dd-b (sf) http://ouroboros.demesne.com/ Ouroboros Bookworms
Join the 20th century before it's too late!
