On Tue, 26 Aug 2003 00:26, Milan P. Stanic wrote: > [ OK, I'm going to think that we never will have secure system because > absolute security is against nature. ]
True, so let's just get what we can. > > Why? I've used OpenWall and PaX and not found any programs that fail to > > work correctly with them. > > I'm sure You know how easy to write one. If I and You don't know for > such program, that doesn't mean that there isn't some in the wild. Which is why there are methods of configuring programs to not have OpenWall and PaX apply to them. So if you suddenly have to support a program that does not work with your stack protection scheme then you just flip a bit in the ELF header and it'll work fine! The only problem you might have is users on a multi-user system putting their own binaries in their home directories, having such a problem and not knowing how to solve it. However this will be much less common than the following problems: User installs binary in their home directory and it breaks when you upgrade shared objects in a system upgrade. User installs binary that relies on certain data files being in fixed locations and breaks when you upgrade to the latest FHS. User installs binary that has their UID, home directory, or other data hard-coded. When you migrate users to a new system and change these their program breaks. I've seen all of these in production environments. But I've never seen a program not work with OpenWall and default settings. I conclude that for the majority of real administrators those issues will cause more problems and effort than OpenWall or PaX. -- 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
