* Milan P. Stanic ([EMAIL PROTECTED]) [030823 11:50]: > On Sat, Aug 23, 2003 at 03:13:25PM +1000, Russell Coker wrote: > > Allowing the system administrator to write to /dev/mem as part of debugging > > the kernel is a feature.
> UID 0 must have rights to do everything. root can "format" filesystem, > by mistake or by intention. Can you explain that to me why? Why must there be a user id that can do everything? (The only thing UID 0 can't do is to exclude itself from access to a piece of the system.) Why is it necessary that UID 0 can tamper with kernel space in cirumvention of the interfaces from the kernel on a production system after startup? Why is it necessary that the same UID that can bind to low ports can also read any files? It's convinient that UID 0 can do that at startup, at development, at debugging or at system initalization. But not in a running production environment. > > Allowing the dhcp server to write to /dev/mem because it's UID 0 and Unix > > security sucks is a bug. > The problem isn't with UID 0, but with bugs in software. Why does each server need to be started by UID 0 and therefor the startup programm can do everything? Why does my news server need root, or a dhcp server, or ...? I can't understand that. I do understand that it is easier to have an almighty UID 0. But I really would like a system where the existence of UID 0 is no longer necessary but optional. > I think that the problem cannot be solved in wrong place. It isn't > possible to have secure DHCP server by fixing kernel, but by writing > secure (OK, with less bugs) DHCP server. I've never seen a programm that's really secure. There are programms with more bugs or with less bugs. So it's always strictly necessary to make programms "fail safe", so that failing does as less harm as possible. A error in a dhcp server should just make dhcp fail, and have no negative impact on security. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
