[email protected] writes:
>Experience over on the Windows side of the fence indicates that "remote bad
>guys get some local user first" is a *MAJOR* part of the current real-world
>threat model - the vast majority of successful attacks on end-user boxes these
>days start off with either "Get user to (click on link|open attachment)" or
>"Subvert the path to a website (either by hacking the real site or hijacking
>the DNS) and deliver a drive-by fruiting when the user visits the page".
AppArmor isn't trying to defend everyday users from getting phished or
social engineered; it is trying to protect servers from getting rooted
because of security holes in their network daemons. I find that a
laudable goal. Sure, it doesn't solve every security problem in the
world, but so what? A tool that could solve that one security problem
would still be a useful thing, even if it did nothing else.
I don't find the Windows stuff too relevant here. As I understand it,
AppArmor isn't aimed at defending Windows desktop users; it is aimed at
defending Linux servers. A pretty different environment, I'd say.
Ultimately, there are some things AppArmor may be good at, and there
are also sure to be some things it is bloody useless for. My hammer
isn't very good for screwing in screws, but I still find it useful.
I confess I don't understand the kvetching about AppArmor's goals.
What are you expecting, some kind of silver bullet?
A question I'd find more interesting is whether AppArmor is able to
meet its stated goals, under a reasonable threat model, and with what
degree of assurance, and at what cost. But I don't know whether that's
relevant for the linux-kernel mailing list.
On Sat, 02 Jun 2007 04:30:30 -0000, David Wagner said:
> I don't find the Windows stuff too relevant here.
I'm surprised. The only Windows-specific thing in the whole paragraph is that
the attack described is currently wildly successful. And there *have* been
known exploitable bugs in the Linux version of Firefox. In other words, all the
pieces are in place for exactly the same thing to work on Linux.
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. SQL injection? Happens all the time, and it
can't help much there either. Systems getting pwned because the sysadmin's
laptop got hacked? Pretty common, and another thing that AppArmor won't slow
down. But yes, I *will* grant that the next time there's a buffer overflow in
Apache, AppArmor will be able to help *that*....
> As I understand it,
> AppArmor isn't aimed at defending Windows desktop users; it is aimed at
> defending Linux servers. A pretty different environment, I'd say.
The only reason you're not seeing the same exact threat model against Linux
servers is because it's still a minority. It's *always* been true that one of
the most productive attacks on a server has been to find a desktop that you can
attack, and then abuse a trust relationship from the desktop to the server (and
has been, ever since the server was a IBM mainframe and the desktop was an RJE
station. Amazing how trusting OS/360 was of a card deck tossed into a remote
card reader... :)
> Ultimately, there are some things AppArmor may be good at, and there
> are also sure to be some things it is bloody useless for. My hammer
> isn't very good for screwing in screws, but I still find it useful.
The question is whether it's a hammer, a screwdriver, or that coping saw that
you never seem to find a use for...
> I confess I don't understand the kvetching about AppArmor's goals.
> What are you expecting, some kind of silver bullet?
Exactly the opposite - I'm worried that it will be treated as a silver bullet.
And historically, we've had an amazing amount of pushback againt things that
are intrusive and only provide a partial solution.
On Sat, 2 Jun 2007, [email protected] wrote:
> On Sat, 02 Jun 2007 04:30:30 -0000, David Wagner said:
>> I don't find the Windows stuff too relevant here.
>
> I'm surprised. The only Windows-specific thing in the whole paragraph is that
> the attack described is currently wildly successful. And there *have* been
> known exploitable bugs in the Linux version of Firefox. In other words, all the
> pieces are in place for exactly the same thing to work on Linux.
>
> 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.
> SQL injection? Happens all the time, and it
> can't help much there either. Systems getting pwned because the sysadmin's
> laptop got hacked? Pretty common, and another thing that AppArmor won't slow
> down. But yes, I *will* grant that the next time there's a buffer overflow in
> Apache, AppArmor will be able to help *that*....
>
>> As I understand it,
>> AppArmor isn't aimed at defending Windows desktop users; it is aimed at
>> defending Linux servers. A pretty different environment, I'd say.
>
> The only reason you're not seeing the same exact threat model against Linux
> servers is because it's still a minority. It's *always* been true that one of
> the most productive attacks on a server has been to find a desktop that you can
> attack, and then abuse a trust relationship from the desktop to the server (and
> has been, ever since the server was a IBM mainframe and the desktop was an RJE
> station. Amazing how trusting OS/360 was of a card deck tossed into a remote
> card reader... :)
if you are targeting one specific company or one specific server then you
are correct, however most attacks are not that targeted, they do things
like useing google to find random servers that are running vunerable
software and attack that (or just try the attack against random IP
addresses in case it happens to be running the vunerable software)
David Lang
On Sat, 02 Jun 2007 07:27:13 PDT, [email protected] 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.
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 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.
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.
> 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".
> 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.
On Sat, 2 Jun 2007, [email protected] wrote:
> On Sat, 02 Jun 2007 07:27:13 PDT, [email protected] 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
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.
Hi!
(Please preserve cc lists when replying on l-k).
> >Experience over on the Windows side of the fence indicates that "remote bad
> >guys get some local user first" is a *MAJOR* part of the current real-world
> >threat model - the vast majority of successful attacks on end-user boxes these
> >days start off with either "Get user to (click on link|open attachment)" or
> >"Subvert the path to a website (either by hacking the real site or hijacking
> >the DNS) and deliver a drive-by fruiting when the user visits the page".
>
> AppArmor isn't trying to defend everyday users from getting phished or
> social engineered; it is trying to protect servers from getting rooted
> because of security holes in their network daemons. I find that a
> laudable goal. Sure, it doesn't solve every security problem in the
> world, but so what? A tool that could solve that one security problem
AA solves less problems than SELinux does. Some people like AA more,
but I guess they should just learn SELinux.
And yes, I'm afraid this discussion is relevant on l-k, because we
should have very good reasons before merging duplicate functionality.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--- Pavel Machek <[email protected]> wrote:
> AA solves less problems than SELinux does.
And vi solves less problems than OpenOffice.
vi is good for a different set of purposes than OpenOffice.
AA and SELinux both aspire to being Security Solutions,
but that does not make either a subset of the other.
> Some people like AA more,
> but I guess they should just learn SELinux.
Knowing the people involved I would suggest that the AA people
did learn SELinux, and came to their own conclusions regarding
it's applicability to their needs, and that those conclusions
are not the same as yours.
> And yes, I'm afraid this discussion is relevant on l-k, because we
> should have very good reasons before merging duplicate functionality.
'cmon, you know better than to claim that this is duplicate
functionality. No one is arguing that. The arguments have been
that the conceptual basis of named based access control are flawwed.
As that argument has failed to move the AA adherants, the old sawhorse
that SELinux does everything, or could be made to if you sweated the
policy hard enough, got pulled out. No evidence to that effect,
mind you, but the old "waves paw" nonetheless.
SELinux is the finest implementation of Type Enforcement on the planet.
TE does not match everyone's definition of security. AA is an
alternative that clearly has as tough a roe to hoe as SELinux did
in 2001, when it was up against MLS system vendors who compared it
to Froot Loops. Alternatives, even those that you don't personally
care for, are good for you.
Casey Schaufler
[email protected]