Re: setuid/setgid binaries contained in the Debian repository.
On Mon, Aug 11, 2003 at 08:26:45PM +0200, Emile van Bergen wrote:
> On Mon, Aug 11, 2003 at 01:31:21PM -0400, Matt Zimmerman wrote:
>
> > How many attack vectors can you think of for a CPU's supervisor mode? How
> > about a setuid program on a Unix system? See the difference?
>
> The difference is small, therefore such setuid root wrappers must be
> treated with the same level of caution as CPU microcode. It must
> function correctly, otherwise all is lost.
The question I posed above shows that the difference is not small. It is
the difference between attacking the kernel and attacking a setuid program.
> I'm glad that Unix doesn't put all trusted stuff in the kernel, but
> allows you to implement low level security policies in userspace, by
> providing low level tools such as the call gate (setuid binaries). It
> fits the unix model very well. The OS components are the processes. The
> OS is built in userspace. The admin builds the OS, not the vendor.
Unix allows you to yank something very close to kernel privilege into
userspace, namely root. Root is a security disaster that flies in the face
of decades of security research by continuing to exist in its historical
form.
> That's what unix is all about, that's what makes it so versatile. And
> powerful. And dangerous.
I don't find Unix to be quite so romantic. It is a tool, and one of the
most valuable traits one can have in a tool is for it to be predictable.
The fact that vulnerabilities are nearly always introduced unintentionally
demonstrates that this approach to security does not result in
predictability.
> The point is, 'root' is probably more fundamentally dangerous than most
> people are inclined to think. It's not really the admin, it's the system
> creator's account.
While it would be reasonable to define root that way from an idealistic
perspective, 'root' means something quite different in practice. root
privileges are required in order to do many trivial things, such as starting
a web server which binds to TCP port 80, accessing a removable disk, or
installing new software, which do not necessarily have anything to do with
creating OR administering the system.
--
- mdz
Reply to: