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.
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.
>
>
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
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
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
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 lengths to
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 this, it's
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 -- until your
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
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 -- until your httpd is
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.
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
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
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
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.
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.
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
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, 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 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, 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
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
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
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
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
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)
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
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
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
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
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
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 mechanism
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 something
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 .htaccess) and
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 application and
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 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) attaches security
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 a
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
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 security
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
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 will
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 understand it,
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
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 attacks
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
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
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
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
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.
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
--- 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
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
t;
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 wrote:
O
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
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 flows
[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 wrote:
On Mon, 16 Apr 2007, John Johansen
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
--- 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
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 framework
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.
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 not require
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
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
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
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
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 people can play
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
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
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
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
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
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
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)
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
--- 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
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
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
> 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
> 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
> 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
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
Karl MacMillan wrote:
>I don't think that the ease-of-use issue is clear cut. The hard part of
>understanding both SELinux policies and AppArmor profiles is
>understanding what access should be allowed. [...]
>Whether the access is allowed with the SELinux or
>AppArmor language seems like a small
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
> 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
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
--- 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
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
1 - 100 of 134 matches
Mail list logo
