Re: stack protection
On Mon, 25 Aug 2003 07:48, Milan P. Stanic wrote: Also I don't expect DJB to write replacements for dhcpd, dhclient, ftpd, cron, Maybe someone else should do that, I hope at least. What should be done for the few years that we probably have to wait for such programs to be written? 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! If attacker can poison DNS cache or fake DHCP server to do something nasty then the problem with SE Linux is just mitigated, not solved. Mitigating a problem so that it only allows DOS attacks or attacks of limited means (such as making a DNS or DHCP server return bogus data) rather than having it allow full administrative access is more than a little mitigation! If you trust DNS data then your security sucks anyway. If you don't trust DNS data then an attack that makes a DNS caching server return bogus data is no big deal. 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. I'm not against choice, I just don't like idea that that stack protection and similar code could become mainstream one day. Why? I've used OpenWall and PaX and not found any programs that fail to work correctly with them. Why not make them mainstream? There seems to be no cost. P.S. I appreciate you contribution to Linux (and Debian) security a lot, and I play with *your* SE Linux host when I have time. Thanks. -- 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
Re: stack protection
On Mon, Aug 25, 2003 at 04:14:12PM +1000, Russell Coker wrote: On Mon, 25 Aug 2003 07:48, Milan P. Stanic wrote: Also I don't expect DJB to write replacements for dhcpd, dhclient, ftpd, cron, Maybe someone else should do that, I hope at least. What should be done for the few years that we probably have to wait for such programs to be written? There are some of them: vsftpd, pure-ftpd, udhcp, uschedule ... to note just some. They are not 100% secure, but they are more secure than software written by ISC. [ I don't like to offend Paul Vixie or ISC programmers. They do good job in the beginnings of the Internet and probably in these days they didn't anticipate how hostile will become network for collaboration, sharing ideas and knowledge, extending freedom ... ] [ BTW, a good measure for security is: don't use ISC software! :-) ] [...] If attacker can poison DNS cache or fake DHCP server to do something nasty then the problem with SE Linux is just mitigated, not solved. Mitigating a problem so that it only allows DOS attacks or attacks of limited means (such as making a DNS or DHCP server return bogus data) rather than having it allow full administrative access is more than a little mitigation! I don't like to argue, but that is mitigation and not solution. With SE Linux problem can be mitigated a lot I agree, and I really like we have it now in Debian (due to Your effort), but this isn't solution. [ OK, I'm going to think that we never will have secure system because absolute security is against nature. ] [...] I'm not against choice, I just don't like idea that that stack protection and similar code could become mainstream one day. 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.
Re: stack protection
* Milan P. Stanic ([EMAIL PROTECTED]) [030825 16:50]: On Mon, Aug 25, 2003 at 04:14:12PM +1000, Russell Coker wrote: On Mon, 25 Aug 2003 07:48, Milan P. Stanic wrote: Also I don't expect DJB to write replacements for dhcpd, dhclient, ftpd, cron, Maybe someone else should do that, I hope at least. What should be done for the few years that we probably have to wait for such programs to be written? There are some of them: vsftpd, pure-ftpd, udhcp, uschedule ... to note just some. They are not 100% secure, but they are more secure than software written by ISC. ftp is deprecated. (I do usually recommend WebDAV as non-anon-ftp-replacement and http as anon-replacement.) 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
Re: stack protection
Milan P. Stanic [EMAIL PROTECTED] writes: On Mon, Aug 25, 2003 at 04:14:12PM +1000, Russell Coker wrote: On Mon, 25 Aug 2003 07:48, Milan P. Stanic wrote: Also I don't expect DJB to write replacements for dhcpd, dhclient, ftpd, cron, Maybe someone else should do that, I hope at least. What should be done for the few years that we probably have to wait for such programs to be written? There are some of them: vsftpd, pure-ftpd, udhcp, uschedule ... to note vsftp can't do fxp. MfG Goswin
Re: stack protection
On Mon, 25 Aug 2003, Milan P. Stanic wrote: There are some of them: vsftpd, pure-ftpd, udhcp, uschedule ... to note just some. They are not 100% secure, but they are more secure than software written by ISC. I'm personally only really familiar with ISC's dhcpd3-server, but have you even read the code written by Ted Lemon? Just randomly slandering programmers when you are not intimately familiar with their code isn't something that should be done lightly. As far as I can remember, the last exploit in dhcpd3-server happened well over 2 years ago. While I've never heard of an exploit in udhcp, I'm relatively sure it's not as widely scrutinized as dhcpd3-server. [ I don't like to offend Paul Vixie or ISC programmers. They do good job in the beginnings of the Internet and probably in these days they didn't anticipate how hostile will become network for collaboration, sharing ideas and knowledge, extending freedom ... ] Many of ISC's programs (bind, dhcp) current versions have been completely rewritten from scratch, or nearly from scratch. The people who wrote them are quite well aware of the current state of hostile networks. [ BTW, a good measure for security is: don't use ISC software! :-) ] In many cases, there isn't an alternative for ISC's software. I have yet to find a dhcp server that is as featureful and robust as ISC's dhcp server. If you're serving a network of 5 computers, udhcpd might work for you, but some people use debian to run dhcpd for networks of thousands of nodes with hundreds of subnets. Don Armstrong -- When I was a kid I used to pray every night for a new bicycle. Then I realised that the Lord doesn't work that way so I stole one and asked Him to forgive me. -- Emo Philips. http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu pgpvYPTl8Re3A.pgp Description: PGP signature
Re: stack protection
On Mon, Aug 25, 2003 at 10:56:38AM -0700, Don Armstrong wrote: I'm personally only really familiar with ISC's dhcpd3-server, but have you even read the code written by Ted Lemon? Just randomly slandering programmers when you are not intimately familiar with their code isn't something that should be done lightly. In my original post you could read: (You quote it, see bellow) - [ I don't like to offend Paul Vixie or ISC programmers. They do good job in the beginnings of the Internet and probably in these days they didn't anticipate how hostile will become network for collaboration, sharing ideas and knowledge, extending freedom ... ] - So, I think I'm not slandering them or at least that isn't my intention. I apologize if I did. As far as I can remember, the last exploit in dhcpd3-server happened well over 2 years ago. While I've never heard of an exploit in udhcp, I'm relatively sure it's not as widely scrutinized as dhcpd3-server. Do you follow DSA? -- Debian Security Advisory DSA 231-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze January 17th, 2003 http://www.debian.org/security/faq Debian Security Advisory DSA 245-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze January 28th, 2003 http://www.debian.org/security/faq -- [ I don't like to offend Paul Vixie or ISC programmers. They do good job in the beginnings of the Internet and probably in these days they didn't anticipate how hostile will become network for collaboration, sharing ideas and knowledge, extending freedom ... ] Many of ISC's programs (bind, dhcp) current versions have been completely rewritten from scratch, or nearly from scratch. The people who wrote them are quite well aware of the current state of hostile networks. AFAIK only bind is rewritten, but Dan J. Bernstein explained how they rewrote it. Some of the bugs were the same in version 8 (old code) and 9 (new rewritten code). ;-) Document could be found somewhere on DJB site: http://cr.yp.to/ [ I don't like to refer to DJB, but can't remember anything better ] [ BTW, a good measure for security is: don't use ISC software! :-) ] In many cases, there isn't an alternative for ISC's software. I have yet to find a dhcp server that is as featureful and robust as ISC's dhcp server. If you're serving a network of 5 computers, udhcpd might work for you, but some people use debian to run dhcpd for networks of thousands of nodes with hundreds of subnets. I'm using ISC's dhcp to. But this doesn't mean I must praise it and I can't see bugs.
Re: stack protection
On Mon, 25 Aug 2003, Milan P. Stanic wrote: So, I think I'm not slandering them or at least that isn't my intention. I apologize if I did. Slander wasn't the correct word. It's just not a good idea to malign a whole set of coders and programs without solid reasoning behind it. As far as I can remember, the last exploit in dhcpd3-server happened well over 2 years ago. Do you follow DSA? Debian Security Advisory DSA 231-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze January 17th, 2003 http://www.debian.org/security/faq This exploit is in minires, not dhcp3-server itself. [minires is a library used by dhcp3-server to provide NSUPDATE used in Dynamic DNS.] It also was found during an internal audit by ISC itself... Debian Security Advisory DSA 245-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze January 28th, 2003 http://www.debian.org/security/faq This is a DOS in dhcp3-relay, not in dhcp3-server itself. I'm using ISC's dhcp to. But this doesn't mean I must praise it and I can't see bugs. Heh. There are bugs in it, but many of them have been characterized, and they are typically fixed fairly rapidly. I can only remember a few really nasty ones, but you'd only run into them in rather strange setups.[1] Don Armstrong 1: Before the pool system got rewritten, the abandoned leases where not reclaimed in the proper order [eg, oldest abandoned lease to newest abandoned lease.] I only ran into it because I was operating on a large network with pools at near capacity. -- Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu pgpOheK2BtqXU.pgp Description: PGP signature
Re: stack protection
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
Re: stack protection
On Sun, Aug 24, 2003 at 01:40:28PM +1000, Russell Coker wrote: [...] 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. Someone could say that for Linux comparing it with WinXX. Also I don't expect DJB to write replacements for dhcpd, dhclient, ftpd, cron, Maybe someone else should do that, I hope at least. [...] 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! If attacker can poison DNS cache or fake DHCP server to do something nasty then the problem with SE Linux is just mitigated, not solved. 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. I'm not against choice, I just don't like idea that that stack protection and similar code could become mainstream one day. P.S. I appreciate you contribution to Linux (and Debian) security a lot, and I play with *your* SE Linux host when I have time.
Re: stack protection
Milan P. Stanic [EMAIL PROTECTED] writes: On Sun, Aug 24, 2003 at 01:40:28PM +1000, Russell Coker wrote: 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. I'm not against choice, I just don't like idea that that stack protection and similar code could become mainstream one day. Properly designed the stack protection, array bounds checking and pointer validating routines can be put into queue slots that would otherwise go idle on modern cpus. One might even fit it in along with other instructions and not even blow up the programm size with every check. For most programm it realy doesn't hurt and for everything thats dangerous (suid, servers, other root stuff) making it the default might be the right[tm] way. Compared to the binaries now you probably waste as much on the checks as you save if you optimize for your cpu. MfG Goswin
Re: stack protection
On Sat, 23 Aug 2003 07:02, Milan P. Stanic wrote:
On Thu, Aug 21, 2003 at 09:39:53AM +0200, Xavier Roche wrote:
Note that some options are sometimes incompatible with some packages:
restrictions on kmem ('Deny writing to /dev/kmem, /dev/mem, and
/dev/port') prevent lm_sensors from working properly with my server. But
cat /dev/zero /dev/mem is a feature and not a bug, but today
more and more people disagree.
Allowing the system administrator to write to /dev/mem as part of debugging
the kernel is a feature.
Allowing the dhcp server to write to /dev/mem because it's UID 0 and Unix
security sucks is a bug.
--
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
Re: stack protection
On Sat, Aug 23, 2003 at 03:13:25PM +1000, Russell Coker wrote:
On Sat, 23 Aug 2003 07:02, Milan P. Stanic wrote:
On Thu, Aug 21, 2003 at 09:39:53AM +0200, Xavier Roche wrote:
Note that some options are sometimes incompatible with some packages:
restrictions on kmem ('Deny writing to /dev/kmem, /dev/mem, and
/dev/port') prevent lm_sensors from working properly with my server. But
cat /dev/zero /dev/mem is a feature and not a bug, but today
more and more people disagree.
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.
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.
Re: stack protection
On Sat, Aug 23, 2003 at 11:36:04AM +0200, Milan P. Stanic wrote: | 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. No. The problem is an insecure design that forces the DHCP server to have root priviledges. A finer-grained security would give the DHCP server /just/ enough rights to send and receive the network packets it wants and only fiddle with the files that it actually needs (/var/lib/dhcp/). | 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. A kernel with the ability to lock down processes even further would mean that a buggy DHCP server couldn't be exploited to e.g. scribble all over /dev/mem. This is what systems like grsecurity or SE Linux are trying to do. Which is not to say that less-buggy software is a bad goal; but the reality is that programmers are human, and /do/ make mistakes. Cameron.
Re: stack protection
Brian May [EMAIL PROTECTED] writes: On Fri, Aug 22, 2003 at 10:05:13PM +0200, Goswin von Brederlow wrote: Depending on the size of udev it might be on the initrd or not. If its not then you need a lot of /dev entries to mount the real root device and get udev started or a extra script that created node on the fly from /proc/something. Actually, no you don't. The real root is created on the fly with mknod with the major,minor numbers supplied from the kernel (/proc/sys/kernel/real-root-dev). See /usr/share/initrd-tools/init for details. (at least thats how I read the code, I don't claim to be an expert on this file, under certain circumstances it would appear to parse the /proc/cmdline directly). If you know what the root is. For debix I have a minimal ramdisk that will search for cdroms and tries to find the right CDrom in them. Once I have the cdrom size is not realy a problem anymore. But what devices do i have to make for all the cdroms, esspecially the custom ones like the old cdrom on a soundblaster versions. Having /dev/cdroms is realy a big help searching for a CD. I hope the same can be done with sysfs. I guess its time to try to get a linux 2.6 to compile, boot and run long enough to look around again. MfG Goswin
Re: stack protection
* 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
Re: stack protection
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
Re: stack protection
On Sun, Aug 24, 2003 at 01:19:38AM +1000, Russell Coker wrote: 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. Complexity and security doesn't mix well. [...] 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. 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. :-) [...] 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. 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. 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. SE Linux (and Linux kernel) is the program. Programs have bugs. Some of the bugs can be used as security exploit. If there isn't known exploit now (I don't know but what knows NSA or black hat community?) doesn't mean it will not emerge tomorrow. 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.
Re: stack protection
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
Re: stack protection
On Thu, 21 Aug 2003 22:38, rintek wrote: As for Adamantix people helping out, they haven't even posted to this mailing list yet, so I have no great expectations for them to help in future. Please have a look at your email Yes, I lived in the Netherlands for 2 years of the time I spent working on SE Linux and Debian. During that time I also did some preliminary work on RSBAC support for Debian (which I dropped because it seemed that no-one was interested). Now finally they get in contact to me after I've moved back to Australia (it seems that most Adamantix work is based around the Netherlands). PS Someone please tell rintek that their MUA is broken. -- 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
Re: stack protection
Russell Coker [EMAIL PROTECTED] writes:
On Fri, 22 Aug 2003 11:35, Goswin von Brederlow wrote:
A paper on udev was presented at OLS this year, at the URL below
you can find a copy in PDF format. Basically it is a way of
providing some of the features of devfs but based around using
hotplug to create device nodes using mknod under a regular
directory. So there is no mountable /dev.
Which means you need certain userspace tools for it to work at all
and if they fail you are screwed. Also how do you boot without a
/dev? You need a dummy dev containing any possible root device.
Now that you mention the mounting /dev going away this realy
sucks.
MOUNTING /dev is going away. So you will have /dev be a regular
directory on a regular file system with device nodes in it. For
booting things will work the same way that they worked when Linux
was first released.
Which means you need about 100 device nodes so you can boot of any
of the 65536 disks you could have connected?
Or can you get around till udev starts with a very few nodes with
fixed major/minor?
Doesn't sysfs basically do most of what devfs. Doesn't it know about
all devices?
I believe that udev uses sysfs among other things.
I just ment that instead of devfs knowing about all devices now sysfs
knows about all devices. So theoretically nothing is gained.
Practically sysfs might be better implemented.
Also could sysfs be made to provide a minimal /dev with at least nodes
for the root device and consoles?
On Fri, 22 Aug 2003 11:48, Brian May wrote:
One of the concepts behind devfs is that we could move away from
the current mapping of /dev/device -- {major,minor} -- kernel
driver system, and instead have the /dev/device map straight to
the driver (or something like that, I am just reciting this from
memory).
Yes, that would have been the eventual aim. devfs=only was a step
in that direction.
Have they abandoned this approach?
It seems so.
http://archive.linuxsymposium.org/ols2003/Proceedings/
As for why it's better than udev. There have been bugs in
devfs in the past related to race conditions. Also devfs
requires that the kernel knows about all the device nodes,
whether this is a bug or an excellent feature is a matter of
opinion.
Instead of the kernel knowing about device nodes, it needs to know
about the {major,minor} mappings.
Correct. Therefore we need 32bit device numbers instead.
I wonder if it wouldn't be possible to have the devfs
register/unregister calls for device nodes happen in the parts f the
kernel handling major/minor registration instead of in each individual
driver. How do major/minor pairs get registered with sysfs?
MfG
Goswin
Re: udev [Was: Re: stack protection]
On Aug 22, Goswin von Brederlow [EMAIL PROTECTED] wrote: I'm basically just intrested in whats needed in /dev/ to get udev started and what userspace tools udev needs on a initrd. Whatever is already needed to make your system boot. So far udev will only create nodes for plug and play devices. For automatic discovery d-i will have to use sysfs, I also ITP'ed the library needed to access it. -- ciao, | Marco | [1403 maRDRgM9usPiQ]
Re: stack protection
On Fri, Aug 22, 2003 at 11:39:21AM +0200, Goswin von Brederlow wrote: Which means you need about 100 device nodes so you can boot of any of the 65536 disks you could have connected? Why? The kernel currently has hardcoded logic to convert the root=... string into a major,minor number, it doesn't use /dev for this. Once user space has started, it can populate /dev as required. Or did I miss something here? -- Brian May [EMAIL PROTECTED]
Re: stack protection
Brian May [EMAIL PROTECTED] writes: On Fri, Aug 22, 2003 at 11:39:21AM +0200, Goswin von Brederlow wrote: Which means you need about 100 device nodes so you can boot of any of the 65536 disks you could have connected? Why? The kernel currently has hardcoded logic to convert the root=... string into a major,minor number, it doesn't use /dev for this. Once user space has started, it can populate /dev as required. Or did I miss something here? Depending on the size of udev it might be on the initrd or not. If its not then you need a lot of /dev entries to mount the real root device and get udev started or a extra script that created node on the fly from /proc/something. Might burden the installer. Mfg Goswin
Re: stack protection
* Goswin von Brederlow ([EMAIL PROTECTED]) [030822 22:15]: Depending on the size of udev it might be on the initrd or not. If its not then you need a lot of /dev entries to mount the real root device and get udev started or a extra script that created node on the fly from /proc/something. According to http://www.kroah.com/linux/talks/ols_2003_udev_talk/ http://archive.linuxsymposium.org/ols2003/Proceedings/All-Reprints/Reprint-Kroah-Hartman-OLS2003.pdf this is very small. But - I'm not even near a kernel expert. 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
Re: stack protection
On Thu, Aug 21, 2003 at 09:39:53AM +0200, Xavier Roche wrote:
Note that some options are sometimes incompatible with some packages:
restrictions on kmem ('Deny writing to /dev/kmem, /dev/mem, and
/dev/port') prevent lm_sensors from working properly with my server. But
cat /dev/zero /dev/mem is a feature and not a bug, but today
more and more people disagree.
cite Doug Gwin
UNIX was not designed to stop you from doing stupid things,
because that would also stop you from doing clever things.
/cite
Re: stack protection
On Fri, Aug 22, 2003 at 10:05:13PM +0200, Goswin von Brederlow wrote: Depending on the size of udev it might be on the initrd or not. If its not then you need a lot of /dev entries to mount the real root device and get udev started or a extra script that created node on the fly from /proc/something. Actually, no you don't. The real root is created on the fly with mknod with the major,minor numbers supplied from the kernel (/proc/sys/kernel/real-root-dev). See /usr/share/initrd-tools/init for details. (at least thats how I read the code, I don't claim to be an expert on this file, under certain circumstances it would appear to parse the /proc/cmdline directly). -- Brian May [EMAIL PROTECTED]
Re: stack protection
On Thu, Aug 21, 2003 at 12:57:06PM +1000, Russell Coker wrote: Who is interested in stack protection? I think it would be good to have some experiments of stack protected packages for Debian. Probably the best way to do this would be to start with ssh-stack and sysklogd-stack being uploaded to experimental. I don't have time to do this, but I would like to help test it. What stack protection are you talking about here? Any references? -- Brian May [EMAIL PROTECTED]
Re: stack protection
On Thu, 21 Aug 2003 14:56, Brian May wrote: On Thu, Aug 21, 2003 at 12:57:06PM +1000, Russell Coker wrote: Who is interested in stack protection? I think it would be good to have some experiments of stack protected packages for Debian. Probably the best way to do this would be to start with ssh-stack and sysklogd-stack being uploaded to experimental. I don't have time to do this, but I would like to help test it. What stack protection are you talking about here? Any references? Propolice sounds good: http://www.trl.ibm.com/projects/security/ssp/ From the GCC changelog: * Add the stack protector patch, but don't apply it by default. Edit debian/rules.patch to apply it (closes: #171699, #189494). It sounds like we need a propolice enabled GCC. There are other stack protection mechanisms too, but propolice seems the most popular. Some investigation would need to be done into the relative merits of the various options (propolice has much better support apparently which will be a major factor). -- 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
Re: stack protection
On Thu, 21 Aug 2003, Russell Coker wrote:
Who is interested in stack protection?
I think it would be good to have some experiments of stack protected packages
for Debian.
Also is there any interest in uploading a kernel-image package with the grsec
PaX support built in?
grsec is IMHO a better idea, as it offers a global protection against
various exploit types (execution of code in stack, for example) and
related threats (restriction in /proc is really useful too, ulimit
enforcement, symlink/fifo/chroot restrictions .. )
Note that some options are sometimes incompatible with some packages:
restrictions on kmem ('Deny writing to /dev/kmem, /dev/mem, and
/dev/port') prevent lm_sensors from working properly with my server. But
with reasonnable settings grsecurity is working like a charm.
Ah, when dealing about security, it might be also a good idea to allow
more easily Debian to run with / in read-only. There was a thread in
-devel some time ago (see 'Update re: read-only root filesystem' thread
and http://panopticon.csustan.edu/thood/readonly-root.html)
A read-only / with grsecurity easily offers a good protection (even if not
absolute) [other details could be checked, like non-executable /var, and
so on.. but it depends on the system partitionning]
Major issues for a ro-/ are maybe:
- using devfs for /dev (kernel 2.4 and package devfsd installed)
- using tmpfs for /tmp (kernel 2.4?)
- transforming several /etc files as symlinks and moving them to some
other place (/var/etc ?)
I was wondering if a script-only-package could do that, with a 'Depends:
kernel-xx(2.4), devfsd' and proper install scripts? Might be difficult to
do, but maybe not impossible?
apt-get install read-only-root :)
Re: stack protection
On Thu, 21 Aug 2003 17:39, Xavier Roche wrote: Major issues for a ro-/ are maybe: - using devfs for /dev (kernel 2.4 and package devfsd installed) Devfs is getting less support now, it might not be the best time to start depending on it. -- 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
Re: stack protection
Russell Coker wrote: It sounds like we need a propolice enabled GCC. I have talked to Matthias Klose, one of the GCC maintainers, about this. He included the patch so he could built ProPolice-enables packages of gcc and g++ but he's currently too busy with other things. He might accept a patch that builds these packages but we really need to hurry if we want these compilers released with sarge. Maybe some of the Adamantix developers will help? However, ProPolice has not been ported to all architectures yet, see http://www.research.ibm.com/trl/projects/security/ssp/statuschart.html for details. There are other stack protection mechanisms too, but propolice seems the most popular. Some investigation would need to be done into the relative merits of the various options (propolice has much better support apparently which will be a major factor). I think ProPolice is the best choice, first because Adamantix has tested it for quite some time. Second, ProPolice offers the best protection according to http://www.research.ibm.com/trl/projects/security/ssp/node4.html#SECTION00045000 and finally it even offers the best performance (http://www.research.ibm.com/trl/projects/security/ssp/node5.html). IMHO innovations in Debian have been rare in the past 2 years (compared to other major distributions), so maybe this is a chance for Debian... Stefan
Re: stack protection
Xavier Roche [EMAIL PROTECTED] writes: On Thu, 21 Aug 2003, Russell Coker wrote: Major issues for a ro-/ are maybe: - using devfs for /dev (kernel 2.4 and package devfsd installed) Alternatively you can copy /dev to a ramdisk. And please don't use devfsd. That somewhat cancles out half of the merits of devfs. You also might want to look at udev since that looks like its replaing devfs in the future. - using tmpfs for /tmp (kernel 2.4?) Or your own /tmp partition as any good admin would have made. :) - transforming several /etc files as symlinks and moving them to some other place (/var/etc ?) Thats pending some year old patches on util-linux (for mount, /etc/mtab) unless you want to link to /proc/mounts. Anything else is already patched for this or has no reason to stay in /etc. I was wondering if a script-only-package could do that, with a 'Depends: kernel-xx(2.4), devfsd' and proper install scripts? Might be difficult to do, but maybe not impossible? apt-get install read-only-root :) Didn't someone package something up that will divert and link some files already? MfG Goswin
Re: stack protection
Russell Coker [EMAIL PROTECTED] writes: Devfs is getting less support now, it might not be the best time to start depending on it. Indeed, it's looking likely that GregKH's `udev' will replace devfs sometime in the future. [It was amusing to see Christoph Hellwig's recent patch on the lkml changing devfs from `EXPERIMENTAL' directly to `OBSOLETE' (and he has a fairly good record of getting devfs patches accepted by Linus). :-/ ] -Miles -- Is it true that nothing can be known? If so how do we know this? -Woody Allen
Re: stack protection
Hi On Thu, Aug 21, 2003 at 02:56:34PM +1000, Brian May wrote: On Thu, Aug 21, 2003 at 12:57:06PM +1000, Russell Coker wrote: Who is interested in stack protection? x86 only? Pro police is the most platform independent iirc. I think it would be good to have some experiments of stack protected packages for Debian. Probably the best way to do this would be to start with ssh-stack and sysklogd-stack being uploaded to experimental. I don't have time to do this, but I would like to help test it. What stack protection are you talking about here? If you need further reference the easiest way would be to check the bugtraq flamew^Wdiscussion archives right now, as there is quite a big thread with people who have programmed/used ProPolice, Stackguard, PaX and W^X (the stuff OpenBSD uses at the moment). If you filter out the 90% rant and the my-big-dick-software-is-best-at-protecting-your-stack noise, you will find some useful things about stack protection, and the features of each solution... Any references? damn. why didn't I write the above here... MfG/Regards, Alexander -- Alexander Reelsen http://tretmine.org [EMAIL PROTECTED]
Re: stack protection
On Thu, 21 Aug 2003 19:13, Stefan Gybas wrote: However, ProPolice has not been ported to all architectures yet, see http://www.research.ibm.com/trl/projects/security/ssp/statuschart.html for details. Not being ported to all architectures is not a problem IMHO. Such stack protection should not be relied on, it's just there to make automated attacks much more difficult. As i386 is the target for almost all of the automated attacks merely supporting i386 will do most of the good that such a tool can do. As for Adamantix people helping out, they haven't even posted to this mailing list yet, so I have no great expectations for them to help in future. -- 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
Re: stack protection
Who is interested in stack protection? I am. I think it would be good to have some experiments of stack protected packages for Debian. Probably the best way to do this would be to start with ssh-stack and sysklogd-stack being uploaded to experimental. I don't have time to do this, but I would like to help test it. I think it would be good too, but I would rather speak about 'security enhanced packages' in general. Nowadays, we are able to achieve way better things than just stack protection (see end of message). Also is there any interest in uploading a kernel-image package with the grsec PaX support built in? Do you mean a grsec kernel with some security options (such as PaX) enabled by default? Yes, it would be a good thing, and it's even necessary to have kernel based stuff to achieve good protection. gsecurity is a good choice because it includes PaX and adds some nice tricks (chroot() hardening, /proc restritions..) and a full ACL system. Here's (basically) what PaX can provide: - A non-executable pages semantic for alpha, i386, parisc, ppc, sparc, sparc64, which means the ability to build readable/writeable but non executable pages on those architectures which is achieved by some nice tricks on i386 (because there is no hardware support). - Use of this new semantic in the kernel (this is called MPROTECT feature), this will ensure that memory is writable (x)or executable but not both. This is achieved as a modification to mmap() and mprotect() interface, and as a result, you cannot create non executable anonymous mapping, and file mapping are NEVER executable/writable at the same time. (This means that you have a non executable stack, non executable heap and much more). - Address space layout randomization: (to prevent return-to-libc attacks), this tries to randomize the base adresses of stack, heap, mmaped libraries. This require no userland modification. But it does more, it will even randomize the main ELF executable (like .text section) and this is where 'security hardened' packages could be usefull. Because this randomization, to be done the proper way (without any performance impact) needs relocation information which is not available in most ELF files (which are ET_EXEC), but is in ET_DYN ELF files. Without this relocation, PaX can do a kind of 'emulation' (called RANDEXEC) which has a performance impact. Those ET_DYN ELF executables can (rather) easily be produced using a propolice gcc with some modified specfiles. This hardened gcc is already available for gentoo (thanks to pappy/solar). Debian could have a hardened gcc package, and have some binary packages (such as sshd) compiled with it. Compatibility: first, not all architectures are supported by PaX' NOEXEC. Second there are a few applications relying on the fact that the heap is executable (X, java..), PaX features can be disabled 'per executable', but not (for now) 'disabled by default and enabled 'per executable'. The 'security hardened' packages are no use for NOEXEC anyway (which does'nt need anything userspace), so this could be let disabled by default in the secure kernel, and we could enable ASLR only in PaX. Anyway, imho, this kernel stuff should be treated separately, but grsecurity is a good choice for a secure kernel, because it's ACL are needed to prevent some attacks for which PaX cannot do anything. For the 'security hardened' binary packages: building ET_DYN executables will improve security if PaX ASLR is enabled in kernel, but it will work just like a good old ET_EXEC if it is not. So I think it would be a good idea to build ET_DYN executable in 'security enhanced' packages. So, a security enhanced package, built using propolice + beeing ET_DYN will have all the features of propolice, and, if PaX ASLR is loaded in kernel, it will achieve another good protection layer. Julien
Re: stack protection
Russell Coker wrote: On Thu, 21 Aug 2003 19:13, Stefan Gybas wrote: However, ProPolice has not been ported to all architectures yet, see http://www.research.ibm.com/trl/projects/security/ssp/statuschart.html for details. Not being ported to all architectures is not a problem IMHO. Such stack protection should not be relied on, it's just there to make automated attacks much more difficult. As i386 is the target for almost all of the automated attacks merely supporting i386 will do most of the good that such a tool can do. As for Adamantix people helping out, they haven't even posted to this mailing list yet, so I have no great expectations for them to help in future. Please have a look at your email groetjes, Age Huisman
Re: stack protection
Op do 21-08-2003, om 09:49 schreef Russell Coker: On Thu, 21 Aug 2003 17:39, Xavier Roche wrote: Major issues for a ro-/ are maybe: - using devfs for /dev (kernel 2.4 and package devfsd installed) Devfs is getting less support now, it might not be the best time to start depending on it. Let's turn that into 'it might be a good time to stop depending on it'. Debian-installer heavily depends on devfs... -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: stack protection
On Thu, Aug 21, 2003 at 07:16:46PM +0900, Miles Bader wrote: Russell Coker [EMAIL PROTECTED] writes: Devfs is getting less support now, it might not be the best time to start depending on it. Indeed, it's looking likely that GregKH's `udev' will replace devfs sometime in the future. Dare I ask the obvious question: what is udev? Why is it better then devfs? -- Brian May [EMAIL PROTECTED]
Re: stack protection
On Thu, 21 Aug 2003 22:41, Brian May wrote: On Thu, Aug 21, 2003 at 07:16:46PM +0900, Miles Bader wrote: Russell Coker [EMAIL PROTECTED] writes: Devfs is getting less support now, it might not be the best time to start depending on it. Indeed, it's looking likely that GregKH's `udev' will replace devfs sometime in the future. Dare I ask the obvious question: what is udev? Why is it better then devfs? A paper on udev was presented at OLS this year, at the URL below you can find a copy in PDF format. Basically it is a way of providing some of the features of devfs but based around using hotplug to create device nodes using mknod under a regular directory. So there is no mountable /dev. http://archive.linuxsymposium.org/ols2003/Proceedings/ As for why it's better than udev. There have been bugs in devfs in the past related to race conditions. Also devfs requires that the kernel knows about all the device nodes, whether this is a bug or an excellent feature is a matter of opinion. I would prefer that devfs was kept as it's worked well for me. But that it seems that things are moving away from it. -- 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
Re: stack protection
On Aug 21, Xavier Roche [EMAIL PROTECTED] wrote: - using devfs for /dev (kernel 2.4 and package devfsd installed) devfs will probably disappear. It's better to look at udev (which I'm packaging). - transforming several /etc files as symlinks and moving them to some other place (/var/etc ?) There have been long threads about this, a ro-root is almost possible with minimal local changes. -- ciao, | Marco | [1392 ug4klQcM3go0s]
Re: stack protection
On Thu, Aug 21, 2003 at 10:41:16PM +1000, Brian May wrote: Indeed, it's looking likely that GregKH's `udev' will replace devfs sometime in the future. Dare I ask the obvious question: what is udev? Why is it better then devfs? It's mostly in user-space, lighter-weight, and more configurable. It relies on a clever use of other existing kernel features (ramfs, hotplug callouts, sysfs) rather than being a big chunk of special purpose code wired into kernel space. Also, the naming policy is entirely in user-space, there are no wacky device naming conventions in the kernel where they can cause big flamewars. -Miles -- `Suppose Korea goes to the World Cup final against Japan and wins,' Moon said. `All the past could be forgiven.' [NYT]
Re: stack protection
rintek wrote: Russell Coker wrote: On Thu, 21 Aug 2003 19:13, Stefan Gybas wrote: However, ProPolice has not been ported to all architectures yet, see http://www.research.ibm.com/trl/projects/security/ssp/statuschart.html for details. Not being ported to all architectures is not a problem IMHO. Such stack protection should not be relied on, it's just there to make automated attacks much more difficult. As i386 is the target for almost all of the automated attacks merely supporting i386 will do most of the good that such a tool can do. As for Adamantix people helping out, they haven't even posted to this mailing list yet, so I have no great expectations for them to help in future. Please have a look at your email groetjes, Age Huisman Russel , sorry i didn't say to look for what mail Peter Busser , the project leader of Adamantix has send you a email groetjes , Age Huisman
Re: stack protection
Russell Coker [EMAIL PROTECTED] writes: On Thu, 21 Aug 2003 22:41, Brian May wrote: On Thu, Aug 21, 2003 at 07:16:46PM +0900, Miles Bader wrote: Russell Coker [EMAIL PROTECTED] writes: Devfs is getting less support now, it might not be the best time to start depending on it. Indeed, it's looking likely that GregKH's `udev' will replace devfs sometime in the future. Dare I ask the obvious question: what is udev? Why is it better then devfs? A paper on udev was presented at OLS this year, at the URL below you can find a copy in PDF format. Basically it is a way of providing some of the features of devfs but based around using hotplug to create device nodes using mknod under a regular directory. So there is no mountable /dev. Which means you need certain userspace tools for it to work at all and if they fail you are screwed. Also how do you boot without a /dev? You need a dummy dev containing any possible root device. Now that you mention the mounting /dev going away this realy sucks. http://archive.linuxsymposium.org/ols2003/Proceedings/ As for why it's better than udev. There have been bugs in devfs in the past related to race conditions. Also devfs requires that the kernel knows about all the device nodes, whether this is a bug or an excellent feature is a matter of opinion. I would prefer that devfs was kept as it's worked well for me. But that it seems that things are moving away from it. Doesn't sysfs basically do most of what devfs. Doesn't it know about all devices? MfG Goswin PS: I realy haven't looked into 2.5/2.6 kernels yet due to their lack of compiling, booting or running for longer than a minute.
Re: stack protection
Wouter Verhelst [EMAIL PROTECTED] writes: Op do 21-08-2003, om 09:49 schreef Russell Coker: On Thu, 21 Aug 2003 17:39, Xavier Roche wrote: Major issues for a ro-/ are maybe: - using devfs for /dev (kernel 2.4 and package devfsd installed) Devfs is getting less support now, it might not be the best time to start depending on it. Let's turn that into 'it might be a good time to stop depending on it'. Debian-installer heavily depends on devfs... But baring space problems it should be simple to add udev support with a devfs naming scheme. Anything past starting udev would not have to be changed. MfG Goswin
udev [Was: Re: stack protection]
Marco d'Itri [EMAIL PROTECTED] writes: On Aug 21, Xavier Roche [EMAIL PROTECTED] wrote: - using devfs for /dev (kernel 2.4 and package devfsd installed) devfs will probably disappear. It's better to look at udev (which I'm packaging). Could you give a quick overview about how to replace devfs with udev? Do you have to make a /dev/ dir containing a minimum of devices like the rootfs, console and ramdisks? I'm basically just intrested in whats needed in /dev/ to get udev started and what userspace tools udev needs on a initrd. MfG Goswin
Re: stack protection
On Fri, Aug 22, 2003 at 03:35:04AM +0200, Goswin von Brederlow wrote:
A paper on udev was presented at OLS this year, at the URL below you
can find a copy in PDF format. Basically it is a way of providing
some of the features of devfs but based around using hotplug to
create device nodes using mknod under a regular directory. So there
is no mountable /dev.
Which means you need certain userspace tools for it to work at all and
if they fail you are screwed. Also how do you boot without a /dev? You
need a dummy dev containing any possible root device.
Now that you mention the mounting /dev going away this realy sucks.
One of the concepts behind devfs is that we could move away from
the current mapping of /dev/device -- {major,minor} -- kernel driver
system, and instead have the /dev/device map straight to the driver
(or something like that, I am just reciting this from memory).
Have they abandoned this approach?
http://archive.linuxsymposium.org/ols2003/Proceedings/
As for why it's better than udev. There have been bugs in devfs in
the past related to race conditions. Also devfs requires that the
kernel knows about all the device nodes, whether this is a bug or an
excellent feature is a matter of opinion.
Instead of the kernel knowing about device nodes, it needs to know
about the {major,minor} mappings.
--
Brian May [EMAIL PROTECTED]
Re: stack protection
On Thu, Aug 21, 2003 at 10:57:17PM +1000, Russell Coker wrote: http://archive.linuxsymposium.org/ols2003/Proceedings/ As for why it's better than udev. There have been bugs in devfs in the past related to race conditions. Also devfs requires that the kernel knows about all the device nodes, whether this is a bug or an excellent feature is a matter of opinion. After reading the article, it would seem a key problem is that the kernel enforces the name of the devices. (actually I like this; it means you can refer the the same device with the same name on different systems, and removes the need to reconfigure each program, for instance, to tell it where the sound device is). Since this is the approach being taken, I wonder how long the root=... linux command line parameter will remain as it exists now? In 2.4.x at least, it hardcodes non-devfs device name passing, eg /dev/hda1 and /dev/md1 work, but /dev/md/1 maps to major=9 minor0 (or /dev/md0). This mapping from root= to major,minor takes place before the initrd image runs. -- Brian May [EMAIL PROTECTED]
Re: stack protection
On Fri, 22 Aug 2003 11:35, Goswin von Brederlow wrote:
A paper on udev was presented at OLS this year, at the URL below you
can find a copy in PDF format. Basically it is a way of providing
some of the features of devfs but based around using hotplug to
create device nodes using mknod under a regular directory. So there
is no mountable /dev.
Which means you need certain userspace tools for it to work at all and
if they fail you are screwed. Also how do you boot without a /dev? You
need a dummy dev containing any possible root device.
Now that you mention the mounting /dev going away this realy sucks.
MOUNTING /dev is going away. So you will have /dev be a regular directory on
a regular file system with device nodes in it. For booting things will work
the same way that they worked when Linux was first released.
Doesn't sysfs basically do most of what devfs. Doesn't it know about
all devices?
I believe that udev uses sysfs among other things.
On Fri, 22 Aug 2003 11:48, Brian May wrote:
One of the concepts behind devfs is that we could move away from
the current mapping of /dev/device -- {major,minor} -- kernel driver
system, and instead have the /dev/device map straight to the driver
(or something like that, I am just reciting this from memory).
Yes, that would have been the eventual aim. devfs=only was a step in that
direction.
Have they abandoned this approach?
It seems so.
http://archive.linuxsymposium.org/ols2003/Proceedings/
As for why it's better than udev. There have been bugs in devfs in
the past related to race conditions. Also devfs requires that the
kernel knows about all the device nodes, whether this is a bug or an
excellent feature is a matter of opinion.
Instead of the kernel knowing about device nodes, it needs to know
about the {major,minor} mappings.
Correct. Therefore we need 32bit device numbers instead.
--
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
