Peter Dolding wrote:
> On Nov 18, 2007 5:22 AM, Casey Schaufler <[EMAIL PROTECTED]> wrote:
>
>> --- Peter Dolding <[EMAIL PROTECTED]> wrote:
>>> On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote:
>>>
Peter Dolding wrote:
> Assign application to
On Nov 18, 2007 5:22 AM, Casey Schaufler <[EMAIL PROTECTED]> wrote:
>
>
> --- Peter Dolding <[EMAIL PROTECTED]> wrote:
>
> > On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> > > Peter Dolding wrote:
> > > >>> What is left unspecified here is 'how' a child 'with its own profile'
On Nov 18, 2007 5:22 AM, Casey Schaufler [EMAIL PROTECTED] wrote:
--- Peter Dolding [EMAIL PROTECTED] wrote:
On Nov 17, 2007 11:08 AM, Crispin Cowan [EMAIL PROTECTED] wrote:
Peter Dolding wrote:
What is left unspecified here is 'how' a child 'with its own profile'
is
confined
Peter Dolding wrote:
On Nov 18, 2007 5:22 AM, Casey Schaufler [EMAIL PROTECTED] wrote:
--- Peter Dolding [EMAIL PROTECTED] wrote:
On Nov 17, 2007 11:08 AM, Crispin Cowan [EMAIL PROTECTED] wrote:
Peter Dolding wrote:
Assign application to
a cgroup that contains there
--- Peter Dolding <[EMAIL PROTECTED]> wrote:
> On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> > Peter Dolding wrote:
> > >>> What is left unspecified here is 'how' a child 'with its own profile'
> is
> > >>> confined here. Are it is confined to just its own profile, it may
--- Peter Dolding [EMAIL PROTECTED] wrote:
On Nov 17, 2007 11:08 AM, Crispin Cowan [EMAIL PROTECTED] wrote:
Peter Dolding wrote:
What is left unspecified here is 'how' a child 'with its own profile'
is
confined here. Are it is confined to just its own profile, it may that
the
On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> Peter Dolding wrote:
> >>> What is left unspecified here is 'how' a child 'with its own profile' is
> >>> confined here. Are it is confined to just its own profile, it may that
> >>> the "complicit process" communication may need
Peter Dolding wrote:
>>> What is left unspecified here is 'how' a child 'with its own profile' is
>>> confined here. Are it is confined to just its own profile, it may that
>>> the "complicit process" communication may need to be wider specified to
>>> include this.
>>>
> Sorry have to
Peter Dolding wrote:
What is left unspecified here is 'how' a child 'with its own profile' is
confined here. Are it is confined to just its own profile, it may that
the complicit process communication may need to be wider specified to
include this.
Sorry have to bring this up.
On Nov 17, 2007 11:08 AM, Crispin Cowan [EMAIL PROTECTED] wrote:
Peter Dolding wrote:
What is left unspecified here is 'how' a child 'with its own profile' is
confined here. Are it is confined to just its own profile, it may that
the complicit process communication may need to be wider
> > What is left unspecified here is 'how' a child 'with its own profile' is
> > confined here. Are it is confined to just its own profile, it may that
> > the "complicit process" communication may need to be wider specified to
> > include this.
Sorry have to bring this up. cgroups why not?
What is left unspecified here is 'how' a child 'with its own profile' is
confined here. Are it is confined to just its own profile, it may that
the complicit process communication may need to be wider specified to
include this.
Sorry have to bring this up. cgroups why not? Assign
Re-sent with proper addressing ...
Rob Meijer wrote:
>> The
>> system is "defended" in that the worst the attacker can do to corrupt
>> the system is limited to the transitive closure of what the confined
>> processes are allowed to access.
>>
> The damage the atacker can do would be defined
Re-sent with proper addressing ...
Rob Meijer wrote:
The
system is defended in that the worst the attacker can do to corrupt
the system is limited to the transitive closure of what the confined
processes are allowed to access.
The damage the atacker can do would be defined by the
--- Joshua Brindle <[EMAIL PROTECTED]> wrote:
> Casey Schaufler wrote:
> > --- Crispin Cowan <[EMAIL PROTECTED]> wrote:
> >
> >
> >> Dr. David Alan Gilbert wrote:
> >> ...
> >>
> >> Can you explain why you want a non-privileged user to be able to edit
> >> policy? I would like to better
On Mon, Nov 12, 2007 at 03:50:59PM -0800, Crispin Cowan wrote:
> Dr. David Alan Gilbert wrote:
> > * Crispin Cowan ([EMAIL PROTECTED]) wrote:
> >
> >> I mostly don't see this as a serious limitation, because almost everyone
> >> has their own workstation, and thus has root on that workstation.
[EMAIL PROTECTED] wrote:
> a question for Crispin,
> is there a wildcard replacement for username? so that you could
> grant permission to /home/$user/.mozilla.. and grant each user
> access to only their own stuff? I realize that in this particular
> example the underlying DAC will handle
Casey Schaufler wrote:
--- Crispin Cowan <[EMAIL PROTECTED]> wrote:
Dr. David Alan Gilbert wrote:
...
Can you explain why you want a non-privileged user to be able to edit
policy? I would like to better understand the problem here.
Note that John Johansen is also interested in allowing
Alan Cox wrote:
>> but how can the system know if the directory the user wants to add is
>> reasonable or not? what if the user says they want to store their
>> documents in /etc?
>>
> A more clear example is wanting to wrap a specific tool with temporary
> rules. Those rules would depend
Dr. David Alan Gilbert wrote:
> * Crispin Cowan ([EMAIL PROTECTED]) wrote:
>
>> I mostly don't see this as a serious limitation, because almost everyone
>> has their own workstation, and thus has root on that workstation. There
>> are 2 major exceptions:
>>
>> * Schools, where the
Rogelio M. Serrano Jr. <[EMAIL PROTECTED]> wrote:
> Dr. David Alan Gilbert wrote:
>> Allowing a user to tweak (under constraints) their settings might allow
>> them to do something like create two mozilla profiles which are isolated
>> from each other, so that the profile they use for general web
Rogelio M. Serrano Jr. [EMAIL PROTECTED] wrote:
Dr. David Alan Gilbert wrote:
Allowing a user to tweak (under constraints) their settings might allow
them to do something like create two mozilla profiles which are isolated
from each other, so that the profile they use for general web surfing
Dr. David Alan Gilbert wrote:
* Crispin Cowan ([EMAIL PROTECTED]) wrote:
I mostly don't see this as a serious limitation, because almost everyone
has their own workstation, and thus has root on that workstation. There
are 2 major exceptions:
* Schools, where the workstations are thin
Alan Cox wrote:
but how can the system know if the directory the user wants to add is
reasonable or not? what if the user says they want to store their
documents in /etc?
A more clear example is wanting to wrap a specific tool with temporary
rules. Those rules would depend on the
Casey Schaufler wrote:
--- Crispin Cowan [EMAIL PROTECTED] wrote:
Dr. David Alan Gilbert wrote:
...
Can you explain why you want a non-privileged user to be able to edit
policy? I would like to better understand the problem here.
Note that John Johansen is also interested in allowing
[EMAIL PROTECTED] wrote:
a question for Crispin,
is there a wildcard replacement for username? so that you could
grant permission to /home/$user/.mozilla.. and grant each user
access to only their own stuff? I realize that in this particular
example the underlying DAC will handle it,
On Mon, Nov 12, 2007 at 03:50:59PM -0800, Crispin Cowan wrote:
Dr. David Alan Gilbert wrote:
* Crispin Cowan ([EMAIL PROTECTED]) wrote:
I mostly don't see this as a serious limitation, because almost everyone
has their own workstation, and thus has root on that workstation. There
are
--- Joshua Brindle [EMAIL PROTECTED] wrote:
Casey Schaufler wrote:
--- Crispin Cowan [EMAIL PROTECTED] wrote:
Dr. David Alan Gilbert wrote:
...
Can you explain why you want a non-privileged user to be able to edit
policy? I would like to better understand the problem here.
On Sat, November 10, 2007 22:04, Andi Kleen wrote:
> Crispin Cowan <[EMAIL PROTECTED]> writes:
>
> The document should be a good base for a merge.
>
>> * A confined process can operate on a file descriptor passed to it
>> by an unconfined process, even if it manipulates a file not in the
On Sat, November 10, 2007 22:04, Andi Kleen wrote:
Crispin Cowan [EMAIL PROTECTED] writes:
The document should be a good base for a merge.
* A confined process can operate on a file descriptor passed to it
by an unconfined process, even if it manipulates a file not in the
Dr. David Alan Gilbert wrote:
>
>
> Allowing a user to tweak (under constraints) their settings might allow
> them to do something like create two mozilla profiles which are isolated
> from each other, so that the profile they use for general web surfing
> is isolated from the one they use for
On Sat, 10 Nov 2007, John Johansen wrote:
On Sat, Nov 10, 2007 at 03:52:31PM -0800, [EMAIL PROTECTED] wrote:
On Sat, 10 Nov 2007, Dr. David Alan Gilbert wrote:
Allowing a user to tweak (under constraints) their settings might allow
them to do something like create two mozilla profiles which
On Sat, Nov 10, 2007 at 03:52:31PM -0800, [EMAIL PROTECTED] wrote:
> On Sat, 10 Nov 2007, Dr. David Alan Gilbert wrote:
>
>
> a question for Crispin,
> is there a wildcard replacement for username? so that you could grant
> permission to /home/$user/.mozilla.. and grant each user access
On Sat, Nov 10, 2007 at 05:27:51PM -0800, [EMAIL PROTECTED] wrote:
> On Sat, 10 Nov 2007, Alan Cox wrote:
>
>>> but how can the system know if the directory the user wants to add is
>>> reasonable or not? what if the user says they want to store their
>>> documents in /etc?
>>
>> A more clear
On Sat, Nov 10, 2007 at 06:17:30PM -0800, Casey Schaufler wrote:
>
> --- Crispin Cowan <[EMAIL PROTECTED]> wrote:
>
> > Dr. David Alan Gilbert wrote:
> > ...
> >
> > Can you explain why you want a non-privileged user to be able to edit
> > policy? I would like to better understand the problem
On Sat, Nov 10, 2007 at 01:28:25PM -0800, [EMAIL PROTECTED] wrote:
> On Sat, 10 Nov 2007, Andi Kleen wrote:
>
>> Crispin Cowan <[EMAIL PROTECTED]> writes:
>>
>> The document should be a good base for a merge.
>>
>>> * A confined process can operate on a file descriptor passed to it
>>>
On Sat, Nov 10, 2007 at 01:24:46PM -0800, Crispin Cowan wrote:
> Andi Kleen wrote:
> > Crispin Cowan <[EMAIL PROTECTED]> writes:
> >
> > The document should be a good base for a merge.
> >
> >
> >> * A confined process can operate on a file descriptor passed to it
> >> by an
--- Crispin Cowan <[EMAIL PROTECTED]> wrote:
> Dr. David Alan Gilbert wrote:
> ...
>
> Can you explain why you want a non-privileged user to be able to edit
> policy? I would like to better understand the problem here.
>
> Note that John Johansen is also interested in allowing non-privileged
>
On Sat, 10 Nov 2007, Alan Cox wrote:
but how can the system know if the directory the user wants to add is
reasonable or not? what if the user says they want to store their
documents in /etc?
A more clear example is wanting to wrap a specific tool with temporary
rules. Those rules would
> but how can the system know if the directory the user wants to add is
> reasonable or not? what if the user says they want to store their
> documents in /etc?
A more clear example is wanting to wrap a specific tool with temporary
rules. Those rules would depend on the exact file being edited
> I submit that the AppArmor model is valid, even if it totally failed all
> of David Gilbert's questions (I think AppArmor can actually provide
> about half of what he asked for).
The model looks valid. I have difficulty constructing many scenarios
where its useful but it appears valid providing
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
That I wrote:
> >If the adminisrator set something up with (2) as the starting point it
> >would seem reasonable for the user to be able to add the ability to edit
> >documents in extra directories for their style of organising documents
> >they work
On Sat, 10 Nov 2007, Dr. David Alan Gilbert wrote:
Can you explain why you want a non-privileged user to be able to edit
policy? I would like to better understand the problem here.
I think it might depend on how strict the users starting point is;
you could say:
1 This document editor can
* Crispin Cowan ([EMAIL PROTECTED]) wrote:
> Dr. David Alan Gilbert wrote:
> > * Crispin Cowan ([EMAIL PROTECTED]) wrote:
> >
> >> I don't get the problem: if you want your web browser to be able to
> >> access where you commonly store your documents, then give it that
> >> permission. The
Alan Cox wrote:
>> Can you explain why you want a non-privileged user to be able to edit
>> policy? I would like to better understand the problem here.
>>
> Because root doesn't trust users who in turn may not trust apps they run
> or wish to control things. I don't see a problem with that
> Can you explain why you want a non-privileged user to be able to edit
> policy? I would like to better understand the problem here.
Because root doesn't trust users who in turn may not trust apps they run
or wish to control things. I don't see a problem with that viewpoint in
terms of
Dr. David Alan Gilbert wrote:
> * Crispin Cowan ([EMAIL PROTECTED]) wrote:
>
>> I don't get the problem: if you want your web browser to be able to
>> access where you commonly store your documents, then give it that
>> permission. The above rule says that your web browser doesn't get to go
>>
* Crispin Cowan ([EMAIL PROTECTED]) wrote:
> * Manipulating AppArmor policy requires being both root privileged
> and not being confined by AppArmor, thus there is explicitly no
> capability for non-privileged users to change AppArmor policy.
It's a pity that there is no way to
* Crispin Cowan ([EMAIL PROTECTED]) wrote:
> Dr. David Alan Gilbert wrote:
> > * Crispin Cowan ([EMAIL PROTECTED]) wrote:
> > >> * Manipulating AppArmor policy requires being both root privileged
> >> and not being confined by AppArmor, thus there is explicitly no
> >> capability
Dr. David Alan Gilbert wrote:
> * Crispin Cowan ([EMAIL PROTECTED]) wrote:
> > * Manipulating AppArmor policy requires being both root privileged
>> and not being confined by AppArmor, thus there is explicitly no
>> capability for non-privileged users to change AppArmor policy.
>>
Andi Kleen wrote:
> Crispin Cowan <[EMAIL PROTECTED]> writes:
>
> The document should be a good base for a merge.
>
>
>> * A confined process can operate on a file descriptor passed to it
>> by an unconfined process, even if it manipulates a file not in the
>> confined process's
On Sat, 10 Nov 2007, Andi Kleen wrote:
Crispin Cowan <[EMAIL PROTECTED]> writes:
The document should be a good base for a merge.
* A confined process can operate on a file descriptor passed to it
by an unconfined process, even if it manipulates a file not in the
confined
Crispin Cowan <[EMAIL PROTECTED]> writes:
The document should be a good base for a merge.
> * A confined process can operate on a file descriptor passed to it
> by an unconfined process, even if it manipulates a file not in the
> confined process's profile. To block this attack,
Crispin Cowan [EMAIL PROTECTED] writes:
The document should be a good base for a merge.
* A confined process can operate on a file descriptor passed to it
by an unconfined process, even if it manipulates a file not in the
confined process's profile. To block this attack,
On Sat, 10 Nov 2007, Andi Kleen wrote:
Crispin Cowan [EMAIL PROTECTED] writes:
The document should be a good base for a merge.
* A confined process can operate on a file descriptor passed to it
by an unconfined process, even if it manipulates a file not in the
confined
Andi Kleen wrote:
Crispin Cowan [EMAIL PROTECTED] writes:
The document should be a good base for a merge.
* A confined process can operate on a file descriptor passed to it
by an unconfined process, even if it manipulates a file not in the
confined process's profile. To
Dr. David Alan Gilbert wrote:
* Crispin Cowan ([EMAIL PROTECTED]) wrote:
snip
* Manipulating AppArmor policy requires being both root privileged
and not being confined by AppArmor, thus there is explicitly no
capability for non-privileged users to change AppArmor policy.
* Crispin Cowan ([EMAIL PROTECTED]) wrote:
Dr. David Alan Gilbert wrote:
* Crispin Cowan ([EMAIL PROTECTED]) wrote:
snip
* Manipulating AppArmor policy requires being both root privileged
and not being confined by AppArmor, thus there is explicitly no
capability for
* Crispin Cowan ([EMAIL PROTECTED]) wrote:
snip
* Manipulating AppArmor policy requires being both root privileged
and not being confined by AppArmor, thus there is explicitly no
capability for non-privileged users to change AppArmor policy.
It's a pity that there is no way
Dr. David Alan Gilbert wrote:
* Crispin Cowan ([EMAIL PROTECTED]) wrote:
I don't get the problem: if you want your web browser to be able to
access where you commonly store your documents, then give it that
permission. The above rule says that your web browser doesn't get to go
change
Can you explain why you want a non-privileged user to be able to edit
policy? I would like to better understand the problem here.
Because root doesn't trust users who in turn may not trust apps they run
or wish to control things. I don't see a problem with that viewpoint in
terms of forbidding
Alan Cox wrote:
Can you explain why you want a non-privileged user to be able to edit
policy? I would like to better understand the problem here.
Because root doesn't trust users who in turn may not trust apps they run
or wish to control things. I don't see a problem with that viewpoint
* Crispin Cowan ([EMAIL PROTECTED]) wrote:
Dr. David Alan Gilbert wrote:
* Crispin Cowan ([EMAIL PROTECTED]) wrote:
I don't get the problem: if you want your web browser to be able to
access where you commonly store your documents, then give it that
permission. The above rule says
On Sat, 10 Nov 2007, Dr. David Alan Gilbert wrote:
Can you explain why you want a non-privileged user to be able to edit
policy? I would like to better understand the problem here.
I think it might depend on how strict the users starting point is;
you could say:
1 This document editor can
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
That I wrote:
If the adminisrator set something up with (2) as the starting point it
would seem reasonable for the user to be able to add the ability to edit
documents in extra directories for their style of organising documents
they work on; but
I submit that the AppArmor model is valid, even if it totally failed all
of David Gilbert's questions (I think AppArmor can actually provide
about half of what he asked for).
The model looks valid. I have difficulty constructing many scenarios
where its useful but it appears valid providing
but how can the system know if the directory the user wants to add is
reasonable or not? what if the user says they want to store their
documents in /etc?
A more clear example is wanting to wrap a specific tool with temporary
rules. Those rules would depend on the exact file being edited at
On Sat, 10 Nov 2007, Alan Cox wrote:
but how can the system know if the directory the user wants to add is
reasonable or not? what if the user says they want to store their
documents in /etc?
A more clear example is wanting to wrap a specific tool with temporary
rules. Those rules would
--- Crispin Cowan [EMAIL PROTECTED] wrote:
Dr. David Alan Gilbert wrote:
...
Can you explain why you want a non-privileged user to be able to edit
policy? I would like to better understand the problem here.
Note that John Johansen is also interested in allowing non-privileged
users to
On Sat, Nov 10, 2007 at 01:24:46PM -0800, Crispin Cowan wrote:
Andi Kleen wrote:
Crispin Cowan [EMAIL PROTECTED] writes:
The document should be a good base for a merge.
* A confined process can operate on a file descriptor passed to it
by an unconfined process, even if
On Sat, Nov 10, 2007 at 01:28:25PM -0800, [EMAIL PROTECTED] wrote:
On Sat, 10 Nov 2007, Andi Kleen wrote:
Crispin Cowan [EMAIL PROTECTED] writes:
The document should be a good base for a merge.
* A confined process can operate on a file descriptor passed to it
by an unconfined
On Sat, Nov 10, 2007 at 06:17:30PM -0800, Casey Schaufler wrote:
--- Crispin Cowan [EMAIL PROTECTED] wrote:
Dr. David Alan Gilbert wrote:
...
Can you explain why you want a non-privileged user to be able to edit
policy? I would like to better understand the problem here.
Note
On Sat, Nov 10, 2007 at 05:27:51PM -0800, [EMAIL PROTECTED] wrote:
On Sat, 10 Nov 2007, Alan Cox wrote:
but how can the system know if the directory the user wants to add is
reasonable or not? what if the user says they want to store their
documents in /etc?
A more clear example is wanting
On Sat, Nov 10, 2007 at 03:52:31PM -0800, [EMAIL PROTECTED] wrote:
On Sat, 10 Nov 2007, Dr. David Alan Gilbert wrote:
snip
a question for Crispin,
is there a wildcard replacement for username? so that you could grant
permission to /home/$user/.mozilla.. and grant each user access to
On Sat, 10 Nov 2007, John Johansen wrote:
On Sat, Nov 10, 2007 at 03:52:31PM -0800, [EMAIL PROTECTED] wrote:
On Sat, 10 Nov 2007, Dr. David Alan Gilbert wrote:
Allowing a user to tweak (under constraints) their settings might allow
them to do something like create two mozilla profiles which
Dr. David Alan Gilbert wrote:
Allowing a user to tweak (under constraints) their settings might allow
them to do something like create two mozilla profiles which are isolated
from each other, so that the profile they use for general web surfing
is isolated from the one they use for online
re-sent due to a typo in addressing.
AppArmor Security Goal
Crispin Cowan, PhD
MercenaryLinux.com
This document is intended to specify the security goal that AppArmor is
intended to achieve, so that users can evaluate whether AppArmor will
meet their needs, and kernel developers can evaluate
re-sent due to a typo in addressing.
AppArmor Security Goal
Crispin Cowan, PhD
MercenaryLinux.com
This document is intended to specify the security goal that AppArmor is
intended to achieve, so that users can evaluate whether AppArmor will
meet their needs, and kernel developers can evaluate
78 matches
Mail list logo
