From: todd at hostopia.com (Todd Burroughs)
Subject: Partial Solution to SUID Problems

On Fri, 5 Dec 2003, Ciro wrote:

> On Thu, 4 Dec 2003, Gino Thomas wrote:
> >
> > I asked some ppl the same question, answers vary. On one hand some ppl
> > trust the suids and claim that messing up with them will open new
> > problems and that there are also many other ways to get root (kernel,
> > libc, daemons,...) on the other hand ppl agreed with me that if i don't

If, by "messing up with them", you mean "turning off the suid bit", that
cannot decrease security.  If they think otherwise, they do not know
what they talk about.  Any program that is suid or sgid can either do
nothing for or decrease your security.  I cannot think of any possible
way that keeping suid/sgid could increase your security.  There are some
exceptions if you want to give people partial root access, like 'sudo'.

I'm open to suggestions otherwise, but doubt anyone would disagree.

> The thing that screams "bad idea" or at least "inconvienient pain in the
> neck" to me is that, on the off chance that a wide-spread exploit is
> found and you have to "make world" or whatever, it puts them right back
> and you have to do it again.

I was going to mention this, it is a "bit" of a pain when you replace
something and it gets put back "where it belongs".  I've broken 'su'
on our systems before when it got updated.  One of our programmers was
pissed because she thought I cut her off root ;-)

Another problem that you *must* be aware of is that if you do something
like an 'rpm' update ('make world' would likely do the same), it may
update things where they are supposed to be and they won't be suid, but
you still have your vulnerable suid program that is actually suid on the
"suid partition".  It'll generally break things and you'll notice though.
If the distros did this, you wouldn't have to worry about it.  I find
that the convenience of being able to look at the actual suid programs
by doing "mount; ls -l /suid_stuff" outweighs this.  It's annoying at
update time though...

For the most part, you shouldn't need all those suid programs anyway.
Most boxes I administer have 'su' and 'sendmail' (sgid).

On a workstation, I usually don't bother with this, but on a server I think
it helps.  It *is* a pain when I update the programs I want s[ug]id, as I
have to manually fix this.  It's nice that the ones that might get installed
by updates or other admins doing things will not actually be s[ug]id, unless
they put them on the "suid partition".

This does not protect you against being rooted, but I find that it does
make it easier to monitor and control.  Many of the libc and other
exploits require that you run a suid program, this makes it easier to
control which ones actually work.

When you have a lot of servers and admins of various skill and security
knowlege (if you know anything about security, you know how hard it is
for people to understand even simple security), I've found this very
helpful in controlling what programs are actually s[ug]id on my servers.

The latest Linux kernel thing is nasty, I've spent the week making
kernels, rebooting and finding/fixing minor problems unrelated to
security...  Security against this: don't give shell access, if you
host websites, CGI, PHP, etc. etc., keep suids away from people and fix
things fast.  Our web servers get patched real quick ;-)

Todd Burroughs

---
The Internet has given us unprecedented opportunity to communicate and
share on a global scale without borders; fight to keep it that way.

Powered by blists - more mailing lists