On Sat, 23 Aug 2003 19:36, Milan P. Stanic 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.
UID does not have to be the only method of determining access rights. In SE Linux you have the Identity (based on the login name for interactive sessions and cron jobs, or system_u otherwise) which determines which roles are permitted. You have the Role which determines which domains are permitted, for an Identity that is permitted to use multiple roles there are methods of changing roles during a session or of determining which Role to use when logging in. Then you have the Domain which determines the access rights. When you login to do administrative work by default you will have the context root:sysadm_r:sysadm_t as the Identity:Role:Domain. This will deny you access to block devices, when you run mount or mkfs they run in different domains which have the access needed to do their job. Then when you run a daemon it runs in a domain that has only the access needed for it's operation, dhcpd_t can do raw network access and bind to UDP port 67. named_t can bind to port 53 for TCP and UDP and port 953 for TCP. Neither named nor dhcpd can access files under user home directories, read /etc/shadow, etc. Which is a very good thing as both have a bad history. > > 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. > > 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. Writing perfect software is impossible. For a good defence you want to have multiple levels. Medieval castles never had a single level of defence, they were built on a hill, they were surrounded by a moat, they had outer walls and then a fortified keep inside so that even filling in the moat and smashing the outer walls would not let an attacker win. If you have only a single level of security then any hole that is found will make you lose. If you have several levels of security then ideally it will not be possible to successfully attack you unless holes are found in all levels simultaneously, which is a much more difficult and less likely event. Writing quality software is good. Having stack protection is good too (the original topic of this thread). But it still doesn't provide as much protection as you will really want, SE Linux is still necessary even if you run top quality software. Most Unix daemons are not of the highest quality, consider that they added a "-b" switch to start-stop-daemon. Think about the quality of coding that goes into a daemon that doesn't even call the daemon(0,0) library call or have equivalent code! PS The ptrace exploit code that was released did not work on SE Linux systems. The reason was that the socket access necessary to trigger the module load in the exploit code was denied to the user_t domain because it was not needed (everything that is not needed is denied by default). It might have been possible to write an exploit to work on SE Linux, but no-one did so. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
