> > 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
33 matches
Mail list logo
