by I was just looking at some CERT advisory
(involving FrameMaker SUID binaries) and wondering:
Why can't one simply configure most S?ID binaries
to be group (and maybe owner) executable?
This seems like it should limit the exposure
somewhat. In cases where the danger of the binary
is it's S?ID property where some user can exploit
a buffer size or similar bug or some syntactical
ambiguity in the file's parameters or configuration
input -- the file still must be executable to a
given user in order to be exploited.
In cases where only certain users *or programs*
need access to a binary then making it o-x should
limit the exposure. It should be that only those
who *need* to run it (defined by some group membership)
have the opportunity to exploit it.
For example -- on one of my Linux boxes (RedHat) I
have some things like su, ping, mount and umount, pppd,
and a bunch of games all SUID. (it's only occasionally
connected to the net, via ppp -- and it has tcp
wrappers and the Linux firewall code configured to
prevent incoming IP access -- all mail is received
and sent via uucp).
So what if I configure su, ping, mount and umount to be
executable only by 'staff' Most users don't need any of
these. Users (like by fiance and my father) who have
console access can all be members of 'staff' so they
can mount magneto optical volumes and floppies
(as specified in my fstab with the nosuid,nodev,noauto,user
options).
Am I right in proposing that an attacker with knowlege
of the mount/umount bug (recently appearing on
the Linux security mailing list) would still need to
compromise one of the 'staff' accounts before exploiting
these SUID binaries. Shouldn't this be a tad more difficult
than getting *anything* (like nobody, guest, etc) to
run?
It seems like 'nobody' and 'guest' shouldn't even
be allowed access to send or receive mail. I could
see *some* argument for nobody or guest accessing
*some* sperl functions (certainly it would make
sense to allow 'www' to access some perl functions
or to access sendmail (but not any mail-user agents).
Certainly this is no panacea -- but I get the feeling that
many of the bugs listed on bugtraq for the last couple
of years would be *much* harder to exploit if more extensive
use of unix group controls was used.
Although this applies primarily to SUID/SGID files
it might help in other circumstances as well.
Obviously if a user can access any C compiler
(or any compiler or sufficiently powerful interpreter)
on the system or that user can write files
to any normally mounted filesystem in the tree
than that user can "bring their own" non-SUID/SGID
tools to the game.
However it doesn't seem that all users need access to a
C compiler. I would even warrant that some users
could be given a home on a noexec filesystem and never
be given write access to any "exec" capable filesystem.
It seems that limiting access to development tools
would prevent some classes of attack involving
exploits of system calls and some race conditions.
After extensive reading and playing around I've
come to the conclusion that the biggest security
problem in Unix is the underlying philosopy that
every user is a programmer -- and needs flexible
access to the programming facilities on the system.
There are tools (such as chroot and restricted shell's)
and mechanisms (such as the sticky bits on directories
read-only mounting and the whole group structure) in place
to make unix systems more secure. They don't seem
to be widely used -- because too many sysadmins aren't
sure of the "side effects" (loss of flexibility and
functionality)
I'm starting to ramble here. The point is that I'm
playing with some of these ideas to see if I can
contribute to the field using existing tools and
features.