Hi, On Mon, Aug 11, 2003 at 02:58:05PM -0400, Matt Zimmerman wrote: > 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. True. Making kernel privileges a bit more fine grained is a good idea, but that's no panacea either because the gained complexity makes it also more error prone. Passing down file descriptors is often enough. About your example, it would indeed be nice if ports where exposed in the filesystem, like /dev/ip/tcp/<port>, to each of which you could assign an owner and a group. That way, the admin can control which uid and gid can bind to what. That installing new user software requires root is the fault of the system integrator, not of unix' design. In the case of Debian, it would be lovely if the user would have a tool to configure and build souce packages so that they could be installed in ~/bin, ~/etc, ~/lib. That installing new /system/ software, that is, software that must authenticate users and spans different uids (mail servers, print servers) requires root, will always be the case in some form or another. Really, there's absolutely nothing wrong with Unix' fundamental design. On the contrary, we just haven't followed the basic idea of files, file descriptors, process and uid separation far enough yet. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl
Attachment:
pgpByqeIzuPJW.pgp
Description: PGP signature