On Sun, 10 Jun 2007, Pavel Machek wrote:
I'm not sure if AppArmor can be made good security for the general case,
but it is a model that works in the limited http environment
(eg .htaccess) and is something people can play with and hack on and may
be possible to configure to be very secure.
Pe
Hi!
> I'm not sure if AppArmor can be made good security for the general case,
> but it is a model that works in the limited http environment
> (eg .htaccess) and is something people can play with and hack on and may
> be possible to configure to be very secure.
>
> >>>Perhaps
On Sat, 9 Jun 2007, Pavel Machek wrote:
Hi!
I'm not sure if AppArmor can be made good security for the general case,
but it is a model that works in the limited http environment
(eg .htaccess) and is something people can play with and hack on and may
be possible to configure to be very secure.
Hi!
> >> I'm not sure if AppArmor can be made good security for the general case,
> >> but it is a model that works in the limited http environment
> >> (eg .htaccess) and is something people can play with and hack on and may
> >> be possible to configure to be very secure.
> >>
> > Perhaps -
Hi!
> >> Maybe you'd like to confine the PHP interpreter to limit what it can do.
> >> That might be a good application for something like AppArmor. You don't
> >> need comprehensive information flow control for that kind of use, and
> >> it would likely just get in the way.
> >
> >SELinux can do
Hi!
> >> Some may infer otherwise from your document.
> >>
> > Not only that, the implication that secrecy is only useful to
> > intelligence agencies is pretty funny.
> That was not the claim. Rather, that intelligence agencies have a very
> strong need for privacy, and will go to greater le
Crispin Cowan wrote:
David Wagner wrote:
James Morris wrote:
[...] you can change the behavior of the application and then bypass
policy entirely by utilizing any mechanism other than direct filesystem
access: IPC, shared memory, Unix domain sockets, local IP networking,
remote ne
Crispin Cowan wrote:
David Wagner wrote:
James Morris wrote:
[...] you can change the behavior of the application and then bypass
policy entirely by utilizing any mechanism other than direct filesystem
access: IPC, shared memory, Unix domain sockets, local IP networking,
remote ne
David Wagner wrote:
> James Morris wrote:
>
>> [...] you can change the behavior of the application and then bypass
>> policy entirely by utilizing any mechanism other than direct filesystem
>> access: IPC, shared memory, Unix domain sockets, local IP networking,
>> remote networking etc.
>>
On Fri, 2007-04-20 at 11:45 -0700, David Lang wrote:
> On Thu, 19 Apr 2007, Stephen Smalley wrote:
>
> > already happened to integrate such support into userland.
> >
> > To look at it in a slightly different way, the AA emphasis on not
> > modifying applications could be viewed as a limitation.
On Thu, 19 Apr 2007, Stephen Smalley wrote:
already happened to integrate such support into userland.
To look at it in a slightly different way, the AA emphasis on not
modifying applications could be viewed as a limitation. Ultimately,
users have security goals that go beyond just what the OS
On Thu, 2007-04-19 at 20:54 +, David Wagner wrote:
> Stephen Smalley wrote:
> >Integrity protection requires information flow control; you can't
> >protect a high integrity process from being corrupted by a low integrity
> >process if you don't control the flow of information. Plenty of attac
On Thu, 19 Apr 2007, Stephen Smalley wrote:
> Lastly, if you want to judge AA as a jail mechanism, I think you'll find
> it fails there too. So where does that leave it? An easy-to-use yet
> inadequate solution for MAC or jail.
It's not easy to use.
--
James Morris
<[EMAIL PROTECTED]>
-
To u
On Thu, 2007-04-19 at 20:08 +, David Wagner wrote:
> Stephen Smalley wrote:
> >Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM
> >Vol 16 No 10) means information flow control, which you have agreed
> >AppArmor does not and cannot provide.
>
> Right, that's how I underst
Stephen Smalley wrote:
>Integrity protection requires information flow control; you can't
>protect a high integrity process from being corrupted by a low integrity
>process if you don't control the flow of information. Plenty of attacks
>take the form of a untrusted process injecting data that wi
Crispin Cowan wrote:
> How is it that you think a buffer overflow in httpd could allow an
> attacker to break out of an AppArmor profile?
James Morris wrote:
> [...] you can change the behavior of the application and then bypass
> policy entirely by utilizing any mechanism other than direct file
On Thu, 19 Apr 2007, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > Perhaps -- until your httpd is compromised via a buffer overflow or
> > simply misbehaves due to a software or configuration flaw, then the
> > assumptions being made about its use of pathnames and their
Stephen Smalley wrote:
>Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM
>Vol 16 No 10) means information flow control, which you have agreed
>AppArmor does not and cannot provide.
Right, that's how I understand it, too.
However, I think some more caveats are in order. In
In article <[EMAIL PROTECTED]> you wrote:
> Perhaps -- until your httpd is compromised via a buffer overflow or
> simply misbehaves due to a software or configuration flaw, then the
> assumptions being made about its use of pathnames and their security
> properties are out the window.
Hu? Even
On Tue, 2007-04-17 at 16:09 -0700, Crispin Cowan wrote:
> David Safford wrote:
> > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
> >
> >> On Mon, 16 Apr 2007, John Johansen wrote:
> >>
> >>> Label-based security (exemplified by SELinux, and its predecessors in
> >>> MLS systems) at
On Tue, 2007-04-17 at 20:05 +0200, Andi Kleen wrote:
> Karl MacMillan <[EMAIL PROTECTED]> writes:
>
> > No - the real fix is to change the applications or to run under a policy
> > that confines all applications. Most of the problems with resolv.conf,
> > mtab, etc. stem from admin processes (e.g
On Thu, 2007-04-19 at 16:35 +, David Wagner wrote:
> James Morris wrote:
> >On Wed, 18 Apr 2007, Crispin Cowan wrote:
> >> How is it that you think a buffer overflow in httpd could allow an
> >> attacker to break out of an AppArmor profile?
> >
> >Because you can change the behavior of the app
On Wed, 2007-04-18 at 13:15 -0700, David Lang wrote:
> On Wed, 18 Apr 2007, James Morris wrote:
>
> > On Tue, 17 Apr 2007, Alan Cox wrote:
> >
> >> I'm not sure if AppArmor can be made good security for the general case,
> >> but it is a model that works in the limited http environment
> >> (eg .h
On Wed, 2007-04-18 at 12:41 -0700, Crispin Cowan wrote:
> James Morris wrote:
> > On Tue, 17 Apr 2007, Alan Cox wrote:
> >
> >> I'm not sure if AppArmor can be made good security for the general case,
> >> but it is a model that works in the limited http environment
> >> (eg .htaccess) and is so
James Morris wrote:
>On Wed, 18 Apr 2007, Crispin Cowan wrote:
>> How is it that you think a buffer overflow in httpd could allow an
>> attacker to break out of an AppArmor profile?
>
>Because you can change the behavior of the application and then bypass
>policy entirely by utilizing any mechani
On Wed, 18 Apr 2007, Crispin Cowan wrote:
> James Morris wrote:
> > On Tue, 17 Apr 2007, Alan Cox wrote:
> >
> >> I'm not sure if AppArmor can be made good security for the general case,
> >> but it is a model that works in the limited http environment
> >> (eg .htaccess) and is something peopl
On Wed, 18 Apr 2007, James Morris wrote:
On Tue, 17 Apr 2007, Alan Cox wrote:
I'm not sure if AppArmor can be made good security for the general case,
but it is a model that works in the limited http environment
(eg .htaccess) and is something people can play with and hack on and may
be possib
On Wed, 18 Apr 2007, Crispin Cowan wrote:
Please explain why labels are necessary for effective confinement. Many
systems besides AppArmor have used non-label schemes for effective
confinement: TRON, Janus, LIDS, Systrace, BSD Jail, EROS, PSOS, KeyOS,
AS400, to name just a few. This claim seems
James Morris wrote:
> On Tue, 17 Apr 2007, Alan Cox wrote:
>
>> I'm not sure if AppArmor can be made good security for the general case,
>> but it is a model that works in the limited http environment
>> (eg .htaccess) and is something people can play with and hack on and may
>> be possible to c
James Morris wrote:
On Tue, 17 Apr 2007, Alan Cox wrote:
I'm not sure if AppArmor can be made good security for the general case,
but it is a model that works in the limited http environment
(eg .htaccess) and is something people can play with and hack on and may
be possible to configure to be
On Wed, April 18, 2007 14:15, Joshua Brindle wrote:
>> Having said that, I feel a path based solution could have great
>> potential
>> if it could be used in conjunction with the object capability model,
>> that
>> I would consider a simple and practical alternative integrity model that
>> does no
On Tue, 17 Apr 2007, Alan Cox wrote:
> I'm not sure if AppArmor can be made good security for the general case,
> but it is a model that works in the limited http environment
> (eg .htaccess) and is something people can play with and hack on and may
> be possible to configure to be very secure.
P
On Wed, 18 Apr 2007, David Lang wrote:
> SELinux is designed to be able to make the box safe against root, AA is
> designed to let the admin harden exposed apps without having to think about
> the other things on the system.
This is not correct.
SELinux was designed as an access control framewor
--- Joshua Brindle <[EMAIL PROTECTED]> wrote:
> Biba and BLP are only incompatible if they are using the same label, if
> each object has a confidentiality and integrity label they work fine
> together
Joshua is correct here, although the original Biba observation was
that flipping BLP upside
Rob Meijer wrote:
On Tue, April 17, 2007 23:55, Karl MacMillan wrote:
On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
On Mon, 16 Apr 2007, John Johansen wrote:
Label-based security (exemplified by SELinux, and its predecessors in
MLS systems) attaches security policy to
ED]>
Cc: James Morris <[EMAIL PROTECTED]>, John Johansen <[EMAIL PROTECTED]>,
linux-kernel@vger.kernel.org, [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: AppArmor FAQ
On Tue, April 17, 2007 23:55, Karl MacMillan wrote:
On Mon, 2007-04-16 at 20:20 -0400, James Morris wrot
On Tue, April 17, 2007 23:55, Karl MacMillan wrote:
> On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
>> On Mon, 16 Apr 2007, John Johansen wrote:
>>
>> > Label-based security (exemplified by SELinux, and its predecessors in
>> > MLS systems) attaches security policy to the data. As the data
James Morris wrote:
>This is not what the discussion is about. It's about addressing the many
>points in the FAQ posted here which are likely to cause misunderstandings,
>and then subsequent responses of a similar nature.
Thank you. Then I misunderstood, and I owe you an apology. Thank you
f
On Wed, 18 Apr 2007, David Wagner wrote:
> These systems probably have different tradeoffs. Consequently, it seems
> to me that arguing over whether SELinux is superior to AppArmor makes
> about as much sense as arguing over whether emacs is superior to vim,
> or whether Python is superior to Per
James Morris wrote:
>On Tue, 17 Apr 2007, David Wagner wrote:
>> Maybe you'd like to confine the PHP interpreter to limit what it can do.
>> That might be a good application for something like AppArmor. You don't
>> need comprehensive information flow control for that kind of use, and
>> it would
James Morris wrote:
>I would challenge the claim that AppArmor offers any magic bullet for
>ease of use.
There are, of course, no magic bullets for ease of use.
I would not make such a strong claim. I simply stated that it
is plausible that AppArmor might have some advantages in some
deployment
On Tue, 17 Apr 2007, David Wagner wrote:
> Maybe you'd like to confine the PHP interpreter to limit what it can do.
> That might be a good application for something like AppArmor. You don't
> need comprehensive information flow control for that kind of use, and
> it would likely just get in the w
On Tue, 17 Apr 2007, David Wagner wrote:
> be more usable than SELinux. Even if SELinux is more "complete"
> than AppArmor, I might still prefer ease of use over completeness
> and understandability.
I would challenge the claim that AppArmor offers any magic bullet for
ease of use. There are pl
Karl MacMillan wrote:
>My private ssh keys need to be protected regardless
>of the file name - it is the "bag of bits" that make it important not
>the name.
I think you picked a bad example. That's a confidentiality policy.
AppArmor can't make any guarantees about confidentiality. Neither can
S
On Tue, 2007-04-17 at 16:09 -0700, Crispin Cowan wrote:
> David Safford wrote:
> > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
> >
>
> The meaning of a file is how other processes interpret it. Until then,
> /etc/resolv.conf is just a quaint bag of bits. What makes it special is
>
On Tue, 2007-04-17 at 15:55 -0700, Crispin Cowan wrote:
> Karl MacMillan wrote:
> > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
> >
> >> On Mon, 16 Apr 2007, John Johansen wrote:
> >>
> >>> Label-based security (exemplified by SELinux, and its predecessors in
> >>> MLS systems) a
Karl MacMillan wrote:
> On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
>
>> On Mon, 16 Apr 2007, John Johansen wrote:
>>
>>> Label-based security (exemplified by SELinux, and its predecessors in
>>> MLS systems) attaches security policy to the data. As the data flows
>>> through the
--- Karl MacMillan <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-04-17 at 13:19 -0700, Casey Schaufler wrote:
> > --- Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > > although this can often be done with PAM plugins, which is a standard
> way
> > > > to do this kind of thing in modern Unix & Linux OSs.
David Safford wrote:
> On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
>
>> On Mon, 16 Apr 2007, John Johansen wrote:
>>
>>> Label-based security (exemplified by SELinux, and its predecessors in
>>> MLS systems) attaches security policy to the data. As the data flows
>>> through the
On Wed, 2007-04-18 at 00:12 +0200, Andi Kleen wrote:
> > The vast majority of applications are not
> > modified to be SELinux aware - only a small handful of security aware
> > applications are modified.
>
> All applications that can edit /etc/resolv.conf? That's nearly
> everything. You yoursel
On Tue, 2007-04-17 at 20:10 +0200, Andi Kleen wrote:
> On Tue, Apr 17, 2007 at 01:47:39PM -0400, James Morris wrote:
> > Normal applications need zero modification under SELinux.
> >
> > Some applications which manage security may need to be made SELinux-aware,
>
> Anything that can touch /etc/r
> I have a different reaction. Given that the ease of use vs
> completeness issues are not completely understood, I would think
> it would make more sense to include both in the kernel. Wasn't that
> the whole point of the LSM interface, to let competing approaches
> bloom and compete on their me
> The vast majority of applications are not
> modified to be SELinux aware - only a small handful of security aware
> applications are modified.
All applications that can edit /etc/resolv.conf? That's nearly
everything. You yourself gave the example; I'm not making anything up.
-Andi (sensing a
> But easy to use security is probably better than complicated security
> because normal people will more likely use it.
Easy to use security is only better if it *works*, and preferably its
excessively secure. Ineffective security is actually worse than no
security.
Real world examples include p
On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
> On Mon, 16 Apr 2007, John Johansen wrote:
>
> > Label-based security (exemplified by SELinux, and its predecessors in
> > MLS systems) attaches security policy to the data. As the data flows
> > through the system, the label sticks to the da
nguage
and policy files more or less inscrutable. In comparison, from
the AppArmor FAQ, I can imagine that I might be able to understand
enough to hack AppArmor policies after 5 minutes of reading a
man page. Whether I'm likely to know what the policy ought to be
is indeed a tough question,
On Tue, 2007-04-17 at 13:19 -0700, Casey Schaufler wrote:
> --- Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > although this can often be done with PAM plugins, which is a standard way
> > > to do this kind of thing in modern Unix & Linux OSs.
> >
> > PAM plugins in vi and emacs? Scary idea.
> >
>
On Tue, 2007-04-17 at 23:16 +0200, Andi Kleen wrote:
> > For SELinux to be effective it has to have a complete policy definition.
> > This would prevent the OpenOffice access (unless OpenOffice is in the
> > modify_resolv_conf_t domain) above.
>
> This would mean no fully functional root user anym
> For SELinux to be effective it has to have a complete policy definition.
> This would prevent the OpenOffice access (unless OpenOffice is in the
> modify_resolv_conf_t domain) above.
This would mean no fully functional root user anymore. My understanding
is rather that at least in the Fedora de
On Tue, 17 Apr 2007, Casey Schaufler wrote:
> those names it cares about. SELinux in the absence of a correct and
> complete policy could be considered dangerous.
It should be noted that SELinux is only recommended as an addition to DAC,
not a replacement, so that it can only further restrict ex
--- Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 17, 2007 at 01:47:39PM -0400, James Morris wrote:
> > Normal applications need zero modification under SELinux.
> >
> > Some applications which manage security may need to be made SELinux-aware,
>
> Anything that can touch /etc/resolv.con
On Tue, Apr 17, 2007 at 01:47:39PM -0400, James Morris wrote:
> Normal applications need zero modification under SELinux.
>
> Some applications which manage security may need to be made SELinux-aware,
Anything that can touch /etc/resolv.conf? That's potentially a lot of binaries
if you consider
On Tue, 17 Apr 2007, Andi Kleen wrote:
> You nicely show one of the major disadvantages of the label model vs the path
> model here: it requires modification of a lot of applications.
This is incorrect.
Normal applications need zero modification under SELinux.
Some applications which manage s
Karl MacMillan <[EMAIL PROTECTED]> writes:
> No - the real fix is to change the applications or to run under a policy
> that confines all applications. Most of the problems with resolv.conf,
> mtab, etc. stem from admin processes (e.g., editors or shell scripts)
> all running under the same uncon
On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
> On Mon, 16 Apr 2007, John Johansen wrote:
>
> > Label-based security (exemplified by SELinux, and its predecessors in
> > MLS systems) attaches security policy to the data. As the data flows
> > through the system, the label sticks to the da
On Tue, 2007-04-17 at 11:03 -0400, David Safford wrote:
> On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
> > On Mon, 16 Apr 2007, John Johansen wrote:
> >
> Actually, this is pretty much how z/OS/RACF works. Labels and pathnames
> for all files are stored in one database. There are advanta
On Mon, 16 Apr 2007, John Johansen wrote:
> Label-based security (exemplified by SELinux, and its predecessors in
> MLS systems) attaches security policy to the data. As the data flows
> through the system, the label sticks to the data, and so security
> policy with respect to this data stays inta
Here we present our direct responses to the most frequent questions from
the AppArmor from the 2006 post.
Use of Pathnames For Access Control
---
Some people in the security field believe that pathnames are an
inappropriate security mechanism. This depends on what
68 matches
Mail list logo
