On Sun, 24 Aug 2003 08:22, Milan P. Stanic wrote: > > 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. > > Complexity and security doesn't mix well.
The LSM model involves the security modules (such as SE Linux) being called only after the Unix permissions have been checked. So SE Linux can not permit an operation that Unix permissions deny. > > Writing perfect software is impossible. > > I agree, but writing secure (not perfectly secure) software may be > nearly possible. > I don't like to start flame war, but must mention djbdns and qmail. Yes, however they have less functionality than the alternatives that most people want to use. Also I don't expect DJB to write replacements for dhcpd, dhclient, ftpd, cron, etc in the near future. > > 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. > > "Denial of Service" was the most successful method to defeat it. :-) True. But DOS attacks are easy to implement on any system regardless of how it's secured. In a castle the occupants would starve to death if they were under siege for long enough, that isn't going to happen to your Linux server. > > 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. > > Having capability to execute code in any place is flexibility of the > OS. If the kernel forbids execution code on the stack, such kernel > forbids using legitimate programming method and I think if it goes this > way we will have OS (kernel) which puts limits and bounds. PaX and OpenWall seem to work well, every program that I tested with them worked in the same way it always worked. > > 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! > > That couldn't be solved by SE Linux (or similar code) but just > mitigated a little. No, it means that a badly written daemon running as UID 0 can not trash your system. So a sound server that has a bug can at worst play sounds and record sounds in a malicious manner, and refuse to do what it is supposed to do. Much better than allowing it to write to /etc/shadow! > I'm not against SE Linux, RSBAC GRSec, LIDS etc. I'm using some them > on servers and playing with all of them. I just like to say that putting > limits in the (our loved (Debian)/Linux) is not good thing, IMO. Why is it a limit? We are not talking about making any of these mandatory for Debian users. We want to give them a choice of all of the above. -- 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
