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'
--- 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 t
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 bring
> > 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? Assi
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
--- 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 unders
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. T
[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
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 non
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
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 "workstati
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
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 onli
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 t
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 examp
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 her
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
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
--- 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
> u
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 depend
> 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 a
> 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 re
* 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
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 vie
> 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
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
>> c
* 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 f
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 proce
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, c
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
39 matches
Mail list logo
