Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

[david@lang.hm]

On Sat, 2 Jun 2007, Valdis.Kletnieks@vt.edu wrote:

> On Sat, 02 Jun 2007 07:27:13 PDT, david@lang.hm said:
>
> > > The type of hardening that AppArmor can provide network-facing daemons is only
> > > protecting the system against attacks that aren't even a large part of the
> > > threat model.   Exploiting a broken PHP script? Happens all the time, and
> > > AppArmor can't do much for it.
> >
> > actually, this is _exactly_ where AppArmor is the most useful. if the PHP
> > script is restricted by AppArmor it won't be able to go out and touch
> > things that it's not supposed to.
>
> OK. I'll bite.  AppArmor basically only mediates filename objects.

for now, the AppArmor folks have said that the next step is to move on to 
other objects (like network connections) after the initial step is 
accepted.

> What filename do you specify to stop it when the exploited PHP script is used
> bu a spammer to send mail to millions, when it was intended to send mail only
> to a specific set of people?  Wait, that's a tcp connection to localhost:25.
>
> What filename do you specifu to stop blog comment spam and other abuses of a
> content management system (remember that the PHP code *does* need write access
> to the files in question)?

it stops the PHP script from spawning a shell that would be considered a 
'local trusted user'

if you use SELinux and give the PHP script permission to write to your 
content management system then the PHP script can corrupt that system if 
it's exploited. AppArmor is the same way

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.

> It might be able to stop J Random SkriptKiddy from scribbling "Y0uz Ben Pwned"
> all over your home page, but it doesn't do much to control lots of other abuses
> of web apps.  To be fair, SELinux can't help a lot more, because the problem
> often ends up being abuse of an access privilege that the program *should*
> have - for example, if it's supposed to query the database, it's hard to stop it from making
> an inappropriate query at the level that AppArmor and SELinux work at.

it's not hard, it's impossible

how can you know if the command 'foo' sent to another program on your 
system will cause that system to erase everything it has access to or 
return 'bar'? you don't and no system tool can (and no system tool should)

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 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

> > if you are targeting one specific company or one specific server then you
> > are correct,
>
> There's a lot of that going around.  And they're the attacks that you need to
> worry about, because you're likely to end up as a headline.
>
> >              however most attacks are not that targeted,
>
> There's a big difference between "most attacks" and "most attacks you should
> worry about".

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.

> >                                                          they do things
> > like useing google to find random servers that are running vunerable
> > software and attack that
>
> Rmember that at a minimum, that also means that you're Goggleable as vulnerable
> to attacks that AppArmor can't stop.  And yes, Googling for vulnerable software
> *is* one of the primary ways that blog spammers find the vulerable blogs.
>
> If your site is run in such a way that you you have to worry about random
> attackers who use google, your site has *bigger* security issues, and thinking
> that AppArmor is going to improve things is exactly the sort of smoke screen
> magic bullet that we don't want putting in the kernel.

when the next exploit is found is network accessable server X, AppArmor 
can prevent it from doing anything to the system that server X wasn't 
already allowed to touch.

For example, this means that it probably won't be allowed to run bash and 
provide a shell to the outside attacker.

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.

if you can't see any advantage to this then you would be happy doing a 
chmod -R 777 / on your system (becouse normal user permissions are a much 
more restricted way of limiting the same type of access)

David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/