Limiting Execution of SUID/SGID Binaries

Limiting Execution of SUID/SGID Binaries

Post by Jim Denni » Fri, 16 Aug 1996 04:00:00



        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.

 
 
 

Limiting Execution of SUID/SGID Binaries

Post by gtaylor+csu081.. » Sat, 17 Aug 1996 04:00:00



>    Why can't one simply configure most S?ID binaries
>    to be group (and maybe owner) executable?
>       [...]

In general, I agree with what you describe.  Most sites make vary
little use, if any, of what capability they have in the form of
groups.

However, I would hate to run a system with dozens or hundreds of
groups the addition of new users to which might compromise the system.
It's much easier to just do a regular find for suid binaries, keep the
number to a minumum, and fix problems as they become known.  This can
even be somewhat automated.

With groups, OTOH, you could end up with a rats-nest of access levels
and inconsistent behaviour.  BSD and ATT unices (at least used to)
handle groups differently, to boot.

As for restricting programs not of use to joe user, I'm all for it.
The last place I admin'd, we didn't let anyone use the compiler on the
email machine.  It's a very good thing that we didn't.  The few people
who caused problems with Perl were easy to spot, and the number of
people who caused problems with things like slirp, crack, or the
exploit of the week was mostly zero.  (Of course, if you've got a
commonplace platform like linux-x86, this isn't so effective, but with
DEC Unix on an Alpha, we did OK.)

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

Restricted shells are generally regarded as being fairly easy to
escape from, although I can still see them being useful in many
situations.  Chroot is something of a bother to set up and use, but
once you do, it's all right.  The resultant environmnet is, however,
either so limited as to be mostly useless, or so big as to be not
secure.  Anonymous FTP is one of the few applications that fits well
into a chrooted environment.

--


 
 
 

Limiting Execution of SUID/SGID Binaries

Post by Thomas H. Ptac » Sun, 18 Aug 1996 04:00:00



Quote:>As for restricting programs not of use to joe user, I'm all for it.
>The last place I admin'd, we didn't let anyone use the compiler on the
>email machine.  It's a very good thing that we didn't.  The few people

I've seen a number of organizations do this for "security" reasons
(restricting access to compilers). It doesn't work, period. What you're
really doing is causing problems for legitimate users of the system.

If, for operational/policy reasons, you don't want people compiling
programs on your system (or using it for software development),
restricting compiler access might make sense. However, as a security
measure, it's pointless. The creation of files in proper executable format
for any platform doesn't require any special access. The easiest loophole
in this system is that I can simply find a different box running the same
OS, compile the program on that system, and upload the binary.

If you *are* going to restrict compiler access, do it right. Simply
chmod'ing /usr/bin/cc 0700 won't do it, as anyone can just upload another
copy of 'cc', and it'll work fine. About all you really CAN do in this
situation is to turn it into so much of a pain to compile software that
nobody bothers to do it.

Keep in mind, especially if you don't watch disk usage, that I could
install all of GNU C on your OS without any special priv's.

--
-----------------------------------------------------------------------------
Thomas Ptacek at The rdist Organization,
Chicagoland's only kung-fu guerilla terrorist computer security organization.

"If you're so special, why aren't you dead?"

 
 
 

Limiting Execution of SUID/SGID Binaries

Post by steve.morris » Mon, 19 Aug 1996 04:00:00




: >As for restricting programs not of use to joe user, I'm all for it.
: >The last place I admin'd, we didn't let anyone use the compiler on the
: >email machine.  It's a very good thing that we didn't.  The few people

: I've seen a number of organizations do this for "security" reasons
: (restricting access to compilers). It doesn't work, period. What you're
: really doing is causing problems for legitimate users of the system.

        I agree. What if I'm just average joe user who wants to learn C
and I don't have access to other resources?
This isn't a hypothetical situation, it actually was a fact of life at
"the last place I admin'd". If you didn't want people to compile code and
only use the system for mail, why not just require everyone to use POP and
shell menus and such?
        Your basically relying on security through obscurity (which we all
know is a false premise) since you are relying on the fact that no_one
who is malicious has access to another Dec Alpha.
        So what does this all mean? Are we going to deny users access to
certain useful day to day tools because it _might_ cause a problem?
Were is an  appropriate line to draw between providing a good useful
service and making it secure and possibly unusable?

--steve
www.seas.upenn.edu/~sdm
finger for public PGP key

 
 
 

1. SUID or SGID execution

Here's the scenario...I have a binary that was compiled with shared
libraries and is set to run SGID (group root).    The problem is that if
the library is not in the usual library path (/usr/lib) the program
cannot find the library.  How can I pass a parameter to the executing
shell to tell it where the library is?  What is the process of a SGID or
SUID program?  Does it fork a separate shell and inherit it's properties
(such as from /etc/default/profile or .login)?  Can I change these
global files and make the new process inherit the variables we need
(such as LD_LIBRARY_PATH)?

We are running Solaris 7 on Ultra/5 and 10's.

Thanks.

Jeff

2. Sound and Printing in Linux

3. What does suid and sgid mean for a directory??

4. How to mount floppy disk A and CDROM to a directory on linux

5. [Fwd: Re: SUID, SGID]

6. archive of fixed size for cd-r backup

7. SUID, SGID

8. Scalable CPU bitmasks

9. How to find SGID e SUID?

10. FDs 0, 1, 2 for SUID/SGID programs

11. Suid/sgid shell scripts

12. What dirs are "unsafe" for suid/sgid

13. SUID, SGID, sticky bit, su & chmod questions