On Sat, 02 Jun 2007 12:51:27 PDT, [email protected] said: > this is Security 101 (or even more basic), if you grant a program access > to do something you can't prevent that program from doing that something. And Security 102 is "most of the *real* trouble starts when authorized programs access authorized things in unintended ways". > if you want to control what commands one program can send to another you > need a security proxy between them. that isn't what AppArmor or SELinux > are trying to do so don't blame them for not doing it. I'm not blaming them. I'm blaming the people who are trying to sell AppArmor as doing much more than a small bandaid on the totality of the security issue. There's *lots* of attacks. AppArmor only addresses a very small segment of them, and it's quite arguably not even addressing the ones you should worry about. > > I'm not convinced that it's solving enough *actual* problems, given that we've > > rejected a lot of other "helps a little in some cases" code for kernel > > inclusion. > > you seem to want a 'only let the system do what the programmer intended' > command, and anything less isn't solving the actual problem. by that logic > we shouldn't bother with passwords either, since they don't completely > solve the problem No, I'm saying that we've had a *lot* of partial solutions, from Grsecurity to signed-modules, that didn't go in to the tree because they were too intrusive for the partial security they provided. > you first want to knock off all the things in that 'most attacks' catagory > so that you can pay close attention to the threats that are targeted > directly at you. Quite frankly, if you've configured your system properly, and kept things patched, and all the other things you should be doing *anyhow*, the vast majority of "most attacks" really shouldn't be much more than "The daily report showed another 2,395 probes for that year-old exploit". Remember - if you're getting hit by a "background noise" random attempt, it is almost certainly *not* a 0-day, because any attacker who's clued enough to *have* a 0-day has enough sense to save it for when he has a targeted attack planned. So there's 2 possibilities: 1) It's a random attack, and it's a *known* attack and other things (patches, IPS, and so on) should already be mitigating the attack. 2) You're a specific target, and the fact that AppArmor stopped the attack just means that a different attack will be made. > For example, this means that it probably won't be allowed to run bash and > provide a shell to the outside attacker. No, but I can mmap an area, make it executable, and download a block of executable code and branch to it, giving me a shell anyhow. > It also means that locally exploitable bugs are less likely to be able to > be combined with remotely exploitable bugs into complete machine takeovers > becouse the remotely exploitable server would have to have permission to > access the locally exploitable software. Right. Instead, the locally exploitable bug is combined with an exploitable browser bug instead. :) > if you can't see any advantage to this then you would be happy doing a Oddly enough, I don't see an advantage to only closing off half the avenues of attack. If you go digging through the SELinux and LSM archives, you'll probably find me arguing against the SELinux 'targeted' policy, for many of the same reasons. And the 'targeted' policy does a better containment of things than the AppArmor model. > chmod -R 777 / on your system (becouse normal user permissions are a much > more restricted way of limiting the same type of access) Bad analogy. You meant "chmod -R 777 /var /etc because the file permissions on the /lib and /usr trees are enough to stop most random attacks". Yes, normal access permissions, being DAC, *are* a very limited way of applying MAC. And if you go back and read the LSM archives, the decision was made to apply permissions/ACLS DAC first, and then apply LSM MAC, mostly for performance and least-surprise reasons. There's absolutely no big theoretical reason why you couldn't chmod 777 everything, if you loaded an LSM that implemented the necessary MAC.
Attachment:
pgpwWVJNUbghl.pgp
Description: PGP signature
- References:
- Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- From: Casey Schaufler <[email protected]>
- Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- From: [email protected] (David Wagner)
- Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- From: Pavel Machek <[email protected]>
- Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- From: [email protected]
- Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- From: [email protected] (David Wagner)
- Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- From: [email protected]
- Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- From: [email protected]
- Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- From: [email protected]
- Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- From: [email protected]
- Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- Prev by Date: Re: Add INPUT support to toshiba_acpi
- Next by Date: Re: [PATCH 0/2] xt_u32 - match arbitrary bits and bytes of a packet
- Previous by thread: Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- Next by thread: Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- Index(es):
 |