[<prev] [next>] [day] [month] [year] [list]
Message-ID: <4436B767.4020003@aesec.com>
Date: Fri Apr 7 21:49:11 2006
From: Ed.Reed at aesec.com (Ed Reed (Aesec))
Subject: [Apparmor-dev] Re: Re: [SC-L] Re: [Owasp-dotnet]
RE: 4 Questions:Latest IE vulnerability, Firefox vs IE security, User vs
Admin risk profile, and browsers coded in 100% Managed Verifiable code
Indeed, one compelling use of AppArmor is to create root-subset profiles
for hard links to /bin/bash so as to effectively partition
administrative privs.
Even root users, when executing within a confined profile, are
constrained - that's the mandatory access control aspect of AppArmor.
You can literally give someone a profiled shell with root privs and let
them try to do something the profile doesn't allow. If you don't give
them "ls", they'll be unable to list their current directory, anywhere,
as long as they're confined.
You can use this to create profiles for backup operators, help desk
technicians, Human Resources user creation tasks, or my favorite -
Oracle Database Administrators - who have root privs to do stuff they
need to do to their Oracle files and directories, and even processes -
but who cannot bounce the machine or reformat disks or do other stuff
they have no need to do.
It's one approach to an RBAC-sort of control.
Ed
Matt Lidestri wrote:
> Hello,
>
> I have used AppArmor a bit, and must say that I like it a lot. I have
> used it on a few servers, and in some security competitions. As a
> HIPS, it is easy to use and fairly effective (from what I have seen).
>
> I just saw your question and it sparked my curiousity. From some
> quick googling, I presume that cap_setuid allows a process or call to
> be passed as another user (we'll say root for now). I wondered if
> root was exempt from the AppArmor rules (although I doubted it), so I
> configured my VMed webserver to access a denied config file for
> mod_security, and then started apache as root. It failed with an
> error from AppArmor claiming that access was denied to the
> configuration file. I restored the permissions in AppArmor and
> received a different error, apparently the Apache developers were
> smart enough to disallow apache to be run as root. Nonetheless,
> AppArmor would not even let it get this far, so even root privileges
> cannot override AppArmor profiles.
>
> Regards,
> Matt
>
>
>
> On 4/6/06, *Brian Eaton* <eaton.lists@...il.com
> <mailto:eaton.lists@...il.com>> wrote:
>
> On 4/5/06, Crispin Cowan <crispin@...ell.com
> <mailto:crispin@...ell.com>> wrote:
> > Pascal Meunier wrote:
> > > but as you posted an example profile with "capability
> setuid", I must
> > > admit I am curious as to why an email client needs that.
> > Well now that is a very good question, but it has nothing to do
> with
> > AppArmor. The AppArmor learning mode just records the actions
> that the
> > application performs. With or without AppArmor, the Thunderbird mail
> > client is using cap_setuid. AppArmor gives you the opportunity
> to *deny*
> > that capability, so you can try blocking it and find out. But for
> > documentation on why Thunderbird needs it, you would have to look at
> > mozilla.org <http://mozilla.org> not the AppArmor pages.
>
> Does cap_setuid give a program enough authority to break out of the
> AppArmor profile?
>
> Regards,
> Brian
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>
>
>
> --
> Matt Lidestri
> ------------------------------------------------------------------------
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Apparmor-dev mailing list
> Apparmor-dev@...ge.novell.com
> http://forge.novell.com/mailman/listinfo/apparmor-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060407/11ed1d0b/attachment.html
Powered by blists - more mailing lists