Re: Security patches
On Fri, 19 Dec 2003, Russell Coker wrote: In terms of LSM protection against this, if you use SE Linux then all aspects of file access and module loading are controlled by the policy. I am going to write a policy that implements something similar to BSD secure levels so that you can put a server into a mode where all kmem and module load access is disabled. That should be all you need. I think there is a LSM BSD secure levels module around (that has nothing to do with SE Linux), which should be much easier an install for those who want to play with BSD secure levels in Linux. Russel, do you know if there is any talk about changing the kernel itself so that it cannot write to its own exec pages? That would kill the stealth capabilities of _all_ kernel-changing rootkits but ones that change the on-disk kernel image or initrd image itself... (and having those on RO media is quite straightforward, anyway). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security patches
On Fri, 19 Dec 2003 20:18, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Fri, 19 Dec 2003, Russell Coker wrote: In terms of LSM protection against this, if you use SE Linux then all aspects of file access and module loading are controlled by the policy. I am going to write a policy that implements something similar to BSD secure levels so that you can put a server into a mode where all kmem and module load access is disabled. That should be all you need. I think there is a LSM BSD secure levels module around (that has nothing to do with SE Linux), which should be much easier an install for those who want to play with BSD secure levels in Linux. It has been floating around. AFAIK it was never released in a fully working form, and it definately has not been included in the kernel.org kernel. Russel, do you know if there is any talk about changing the kernel itself so that it cannot write to its own exec pages? That would kill the stealth capabilities of _all_ kernel-changing rootkits but ones that change the on-disk kernel image or initrd image itself... (and having those on RO media is quite straightforward, anyway). Smart-ass answer: It's called the HURD. Serious answer: The kernel has to be able to manage all aspects of virtual memory, so protecting it from itself is impossible. If we went to some sort of HAL scheme similar to NT then we could do some of this (but it doesn't seem to do NT much good). If we went to a full micro-kernel then we could have only the micro-kernel itself being granted such access, but then it wouldn't be Linux any more. SE Linux could be ported to the HURD. Much (most?) of the early work that SE Linux is based on was done on micro-kernelled OSs. I have no time to do the serious stuff (restricting which ports a process can use when communicating with other processes and the micro-kernel, or porting the security server to be a daemon/translator), but I can help with some of the testing and writing policy. It should be possible to make SE HURD more secure than SE Linux. I am sure that the NSA people would be intersted in such a project, I doubt that they would have any time to contribute to it, but I'm sure that they would give some good advice if asked. -- 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
CVS server in a user-mode-linux
Hello Debian-security list, I have experimented with running an anonymous CVS server inside user-mode-linux. So far this seems to work well and hopefully should enhance security a bit. The host kernel has the skas patch. I use hostfs to mount only the repositories inside the UML. I have limited the UML memory to 128Mb. Performance are quite sufficient for the server usage since load stay close to 0. The only problem is that the server need write access to the repository in order to create locks (which are directories, IIUC). I have not yet find a way to only allows the server to create locks, but to change nothing else. Do you have any ideas to improve the security ? Cheers, [Please CC me] -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CVS server in a user-mode-linux
On Fri, Dec 19, 2003 at 05:46:11PM +0100, Bill Allombert wrote: Hello Debian-security list, I have experimented with running an anonymous CVS server inside user-mode-linux. So far this seems to work well and hopefully should enhance security a bit. The host kernel has the skas patch. I use hostfs to mount only the repositories inside the UML. I have limited the UML memory to 128Mb. Performance are quite sufficient for the server usage since load stay close to 0. The only problem is that the server need write access to the repository in order to create locks (which are directories, IIUC). I have not yet find a way to only allows the server to create locks, but to change nothing else. You can use a separate lock directory by setting LockDir in CVSROOT/config. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CVS server in a user-mode-linux
On Fri, Dec 19, 2003 at 05:46:11PM +0100, Bill Allombert wrote: The only problem is that the server need write access to the repository in order to create locks (which are directories, IIUC). I have not yet find a way to only allows the server to create locks, but to change nothing else. you can disable locking by setting CVSREADONLYFS. just take a look at the *bsd anonymous cvs servers. bastian -- Hailing frequencies open, Captain. signature.asc Description: Digital signature
Re: CVS server in a user-mode-linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have experimented with running an anonymous CVS server inside user-mode-linux. [...] The only problem is that the server need write access to the repository in order to create locks (which are directories, IIUC). I have not yet find a way to only allows the server to create locks, but to change nothing else. Do you have any ideas to improve the security ? You can start cvs with the -R option to run it in read-only mode. You can alternatively put 'LockDir=/tmp/foo' in your config file inside CVSROOT. - -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE/42FfVYan35+NCKcRAkr8AJwPjPS/GIMhvqwBzU3SZmgFgT9bNQCaA3CM Ew7Xku4lwDN6EOllceB+sr4= =1Mqs -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security patches
On Fri, 19 Dec 2003, Russell Coker wrote: In terms of LSM protection against this, if you use SE Linux then all aspects of file access and module loading are controlled by the policy. I am going to write a policy that implements something similar to BSD secure levels so that you can put a server into a mode where all kmem and module load access is disabled. That should be all you need. I think there is a LSM BSD secure levels module around (that has nothing to do with SE Linux), which should be much easier an install for those who want to play with BSD secure levels in Linux. Russel, do you know if there is any talk about changing the kernel itself so that it cannot write to its own exec pages? That would kill the stealth capabilities of _all_ kernel-changing rootkits but ones that change the on-disk kernel image or initrd image itself... (and having those on RO media is quite straightforward, anyway). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Security patches
On Fri, 19 Dec 2003 20:18, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Fri, 19 Dec 2003, Russell Coker wrote: In terms of LSM protection against this, if you use SE Linux then all aspects of file access and module loading are controlled by the policy. I am going to write a policy that implements something similar to BSD secure levels so that you can put a server into a mode where all kmem and module load access is disabled. That should be all you need. I think there is a LSM BSD secure levels module around (that has nothing to do with SE Linux), which should be much easier an install for those who want to play with BSD secure levels in Linux. It has been floating around. AFAIK it was never released in a fully working form, and it definately has not been included in the kernel.org kernel. Russel, do you know if there is any talk about changing the kernel itself so that it cannot write to its own exec pages? That would kill the stealth capabilities of _all_ kernel-changing rootkits but ones that change the on-disk kernel image or initrd image itself... (and having those on RO media is quite straightforward, anyway). Smart-ass answer: It's called the HURD. Serious answer: The kernel has to be able to manage all aspects of virtual memory, so protecting it from itself is impossible. If we went to some sort of HAL scheme similar to NT then we could do some of this (but it doesn't seem to do NT much good). If we went to a full micro-kernel then we could have only the micro-kernel itself being granted such access, but then it wouldn't be Linux any more. SE Linux could be ported to the HURD. Much (most?) of the early work that SE Linux is based on was done on micro-kernelled OSs. I have no time to do the serious stuff (restricting which ports a process can use when communicating with other processes and the micro-kernel, or porting the security server to be a daemon/translator), but I can help with some of the testing and writing policy. It should be possible to make SE HURD more secure than SE Linux. I am sure that the NSA people would be intersted in such a project, I doubt that they would have any time to contribute to it, but I'm sure that they would give some good advice if asked. -- 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
CVS server in a user-mode-linux
Hello Debian-security list, I have experimented with running an anonymous CVS server inside user-mode-linux. So far this seems to work well and hopefully should enhance security a bit. The host kernel has the skas patch. I use hostfs to mount only the repositories inside the UML. I have limited the UML memory to 128Mb. Performance are quite sufficient for the server usage since load stay close to 0. The only problem is that the server need write access to the repository in order to create locks (which are directories, IIUC). I have not yet find a way to only allows the server to create locks, but to change nothing else. Do you have any ideas to improve the security ? Cheers, [Please CC me] -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
Re: CVS server in a user-mode-linux
On Fri, Dec 19, 2003 at 05:46:11PM +0100, Bill Allombert wrote: Hello Debian-security list, I have experimented with running an anonymous CVS server inside user-mode-linux. So far this seems to work well and hopefully should enhance security a bit. The host kernel has the skas patch. I use hostfs to mount only the repositories inside the UML. I have limited the UML memory to 128Mb. Performance are quite sufficient for the server usage since load stay close to 0. The only problem is that the server need write access to the repository in order to create locks (which are directories, IIUC). I have not yet find a way to only allows the server to create locks, but to change nothing else. You can use a separate lock directory by setting LockDir in CVSROOT/config.
Re: CVS server in a user-mode-linux
On Fri, Dec 19, 2003 at 05:46:11PM +0100, Bill Allombert wrote: The only problem is that the server need write access to the repository in order to create locks (which are directories, IIUC). I have not yet find a way to only allows the server to create locks, but to change nothing else. you can disable locking by setting CVSREADONLYFS. just take a look at the *bsd anonymous cvs servers. bastian -- Hailing frequencies open, Captain. signature.asc Description: Digital signature
Re: CVS server in a user-mode-linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have experimented with running an anonymous CVS server inside user-mode-linux. [...] The only problem is that the server need write access to the repository in order to create locks (which are directories, IIUC). I have not yet find a way to only allows the server to create locks, but to change nothing else. Do you have any ideas to improve the security ? You can start cvs with the -R option to run it in read-only mode. You can alternatively put 'LockDir=/tmp/foo' in your config file inside CVSROOT. - -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE/42FfVYan35+NCKcRAkr8AJwPjPS/GIMhvqwBzU3SZmgFgT9bNQCaA3CM Ew7Xku4lwDN6EOllceB+sr4= =1Mqs -END PGP SIGNATURE-
