Crispin Cowan wrote:... Security can (and should) be implemented in a layered approach. Not allowing stacking means that, rather than creating modules which complement each other, certain layers need to be migrated into the mainline kernel code. This would be ok if every situation had the same security requirements; however, they do not. For example small LSMs that provide hooks for Malware scanners (like dazuko), certain security improvements (such as RaceGuard, PaX ...) and POSIX capabilities could be stacked with other larger lsms (traditional access control, IDS, firewalls) rather than copying these techniques into all the large lsms (such as SELinux and AppArmor) or putting them into the mainline kernel. Obviously it would be easier to maintain one capability lsm which stacks, than capabilities being implemented in every access control lsm. It may be possible to compile stacked LSMs together (I don't know), but modules provide greater flexibility and either way stacking should be pursued. I agree with Crispin, restore modules. Then discussions of suitable ways of providing stacking can occur / continue. Cliffe wrote: Just to clarify, I was agreeing with Al that layers for the sake of layers does not improve security if the layers are flawed. I was not implying that the specific LSMs that are being proposed currently (AppArmor etc) are flawed. I personally think that AppArmor provides security improvements which are particularly suitable in some situations. However, if you do have defense in depth then a flaw in one layer may be compensated by another layer. For example if you have a system wide firewall that does not allow any incoming traffic to enter a system, and an AppArmor profile denies all network traffic to a specific application, then a flaw in the firewall which would ordinarily result in a compromise of the systems policy would not cause that specific application to be exposed. Granted this may be a poor example, but it does illustrate that layers provide security improvements. Of course this kind of setup does provide management and usability challenges but that is an area for improvement. Anyway I hope that my opinion is helpful, Cliffe. -- Z. Cliffe Schreuders BSc Comp Sci (Hons) & Int Comp PhD Candidate, Casual Tutor School of IT Murdoch University -
| Ondrej Zary | pata_it821x completely broken |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Greg KH | Re: [PATCH 5/7] FUSE: implement ioctl support |
| Andi Kleen | Re: 2.6.27-rc1: critical thermal shutdown on thinkpad x60 |
git: | |
| Jakub Narebski | Re: VCS comparison table |
| Jakub Narebski | Re: git-push through git protocol |
| Michael Smith | Re: [rfc] git submodules howto |
| Olaf Hering | how to find outstanding patches in non-linux-2.6 repositories? |
| GVG GVG | ssh_exchange_identification: Connection closed by remote host |
| Richard Stallman | Real men don't attack straw men |
| Stuart Henderson | Re: pfctl |
| Tomas Bodzar | command history in ksh missed when I set $EDITOR |
| Jim Winstead Jr. | Re: Root Disk/Book Disk Compatibility |
| Ian Kluft | RESULT: comp.os.linux reorganization, all groups pass (part 3/3) |
| Robert Osterlund | Re: Sharing a swap partition: Linux and Windows? |
| Ian Kluft | 2nd CFV and VOTE ACK: comp.os.linux reorganization |
