full-disclosure - Partial Solution to SUID Problems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20031206185052.A66813@dekadens.coredump.cx>
From: lcamtuf at ghettot.org (Michal Zalewski)
Subject: Partial Solution to SUID Problems

On Sat, 6 Dec 2003, Todd Burroughs wrote:

> As I said, this gives you some control and, regardless if you do this,
> you should have the minimum number of s[ug]id programs to make your
> system functional.  Start with 'su' and 'sendmail' for a server, for a
> workstation, you'll probably need a couple to run X properly and
> probably some for convenience.

Hmm, I would disagree... 'su' is not really neccessary to make your system
functional, is it? Unless your users need to switch privileges all the
time, which is doubtful. The only use of 'su' is when you believe the old
and silly rule not to allow direct root logins... but the rule is of very
little value - it does not truly make any kind of attack more difficult or
less likely to succeed, and having an extra setuid program (a fairly
complex one, and with several vulnerabilities in the past) is a high price
to pay.

But that is a specific case, and 'su' might make sense in some
configurations. Other programs - not necessarily. With 'sendmail', there
are several ways to allow users and programs to submit mails with no extra
privileges - the simplest hack I've seen, which is acceptable for low to
medium MTA loads, is to make a minor tweak to sendmail code to read
/etc/mail/user.cf when run as non-root, /etc/mail/sendmail.cf when run as
root. The first file contains minimal rulesets and relies all mail in
interactive mode to a daemon running on port 25. New Sendmail releases
also come with privilege separation, although it does use a setgid binary
and a local submission queue (which offers a better performance and does
not require a daemon listening on a port).

With many other vital setuid applications, it is very easy to make them
setgid instead, since almost all just need the right to read or write a
single file or access a single device or functionality, effectively
reducing the exposure when a compromise occurs; passwd, chfn, chsh, etc -
on systems with PAM, a single-file password management system can be
easily replaced with a more secure design that does not require more than
setgid, and, if compromised, cannot be used to modify other user's
parameters or add new accounts.

There are many ways to significantly improve local security without major
paradigm shifts or coding efforts, and some of them could be implemented
by default with no particular impact on the base functionality. It is just
that people and vendors do not feel like doing it, with very few
exceptions.

-- 
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2003-12-06 18:50 --

   http://lcamtuf.coredump.cx/photo/current/