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!
> >> 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 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 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
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]>,
[EMAIL PROTECTED], linux-security-module@vger.kernel.org,
[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 Morri
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
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 <[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
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
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
> 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
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 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, 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 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
48 matches
Mail list logo
