On 01/26/2016 07:54 PM, Seth Arnold wrote:
> On Tue, Jan 26, 2016 at 03:17:19PM -0600, Tyler Hicks wrote:
2. stack_onexec, stack delayed until exec applied pre-exec transitions
A -- stack_onexec B -- exec apply stack -- A//&B -- exec trans --> C//&D
>
>> Do you feel like #2 is still us
On Tue, Jan 26, 2016 at 03:17:19PM -0600, Tyler Hicks wrote:
> > > 2. stack_onexec, stack delayed until exec applied pre-exec transitions
> > > A -- stack_onexec B -- exec apply stack -- A//&B -- exec trans --> C//&D
> Do you feel like #2 is still useful? I don't want to put words in John's
> mo
On 2016-01-13 20:08:38, Seth Arnold wrote:
> On Tue, Jan 12, 2016 at 03:10:28PM -0800, John Johansen wrote:
> > now lets look at the stack on exec case. The stack addition is delayed
> > until exec. The current profile will have the stack added on top, the
> > question is when and how.
> >
> > 1.
On Mon, Jan 25, 2016 at 05:54:32PM -0600, Tyler Hicks wrote:
> I think the use of the 'stack' keyword here would make things confusing
> in other areas of the policy language where the 'stack' keyword could
> not be used but a we're still referring to a stack of profiles.
>
> Stealing one of the e
On 2016-01-14 00:46:24, John Johansen wrote:
> On 01/13/2016 08:08 PM, Seth Arnold wrote:
> > On Tue, Jan 12, 2016 at 03:10:28PM -0800, John Johansen wrote:
> >> now lets look at the stack on exec case. The stack addition is delayed
> >> until exec. The current profile will have the stack added on
On 01/13/2016 08:08 PM, Seth Arnold wrote:
> On Tue, Jan 12, 2016 at 03:10:28PM -0800, John Johansen wrote:
>> now lets look at the stack on exec case. The stack addition is delayed
>> until exec. The current profile will have the stack added on top, the
>> question is when and how.
>>
>> 1. stack
On Tue, Jan 12, 2016 at 03:10:28PM -0800, John Johansen wrote:
> now lets look at the stack on exec case. The stack addition is delayed
> until exec. The current profile will have the stack added on top, the
> question is when and how.
>
> 1. stack_onexec as stack + change_onexec: stack is comput
On 01/12/2016 10:40 PM, John Johansen wrote:
> On 01/12/2016 10:10 PM, Tyler Hicks wrote:
>> Thanks, John - I hadn't given a lot of thought to the policy changes
>> required and this email was very helpful.
>>
>> On 2016-01-12 15:10:28, John Johansen wrote:
>>> On 01/11/2016 06:27 PM, Seth Arnold w
On 01/12/2016 10:10 PM, Tyler Hicks wrote:
> Thanks, John - I hadn't given a lot of thought to the policy changes
> required and this email was very helpful.
>
> On 2016-01-12 15:10:28, John Johansen wrote:
>> On 01/11/2016 06:27 PM, Seth Arnold wrote:
>>> On Mon, Jan 11, 2016 at 05:41:43PM -0800,
Thanks, John - I hadn't given a lot of thought to the policy changes
required and this email was very helpful.
On 2016-01-12 15:10:28, John Johansen wrote:
> On 01/11/2016 06:27 PM, Seth Arnold wrote:
> > On Mon, Jan 11, 2016 at 05:41:43PM -0800, John Johansen wrote:
> +Stacking another profi
On 01/11/2016 06:27 PM, Seth Arnold wrote:
> On Mon, Jan 11, 2016 at 05:41:43PM -0800, John Johansen wrote:
+Stacking another profile via aa_stack_profile() is permanent and the
process is not
+permitted to revert to the previous confinement context. Unlike
+aa_change_profile(2
On 01/12/2016 01:23 PM, Jamie Strandboge wrote:
> On 01/11/2016 06:17 PM, Tyler Hicks wrote:
> ...
>
>> Unlike
>> +aa_change_profile(2), confined programs wanting to use aa_stack_profile()
>> need
>> +no special rules in their profile to stack a new profile since the operation
>> +does not broade
On 01/11/2016 06:17 PM, Tyler Hicks wrote:
...
> Unlike
> +aa_change_profile(2), confined programs wanting to use aa_stack_profile()
> need
> +no special rules in their profile to stack a new profile since the operation
> +does not broaden the allowed permissions.
> +
Is this true? Won't the prof
Hello,
Am Dienstag, 12. Januar 2016 schrieb Tyler Hicks:
> More boilerplate from aa_change_profile(2). That's what I get for
> copying from a man page that is incorrect. :)
Please send a patch to fix aa_change_profile.pod to ensure you get a
correct copy next time ;-)
Regards,
Christian Boltz
On 2016-01-11 18:27:24, Seth Arnold wrote:
> On Mon, Jan 11, 2016 at 05:41:43PM -0800, John Johansen wrote:
> > >> +Stacking another profile via aa_stack_profile() is permanent and the
> > >> process is not
> > >> +permitted to revert to the previous confinement context. Unlike
> > >> +aa_change_p
On 2016-01-11 17:02:29, Seth Arnold wrote:
> Thanks for getting this started; some comments inline:
>
> On Mon, Jan 11, 2016 at 06:17:47PM -0600, Tyler Hicks wrote:
> > +=pod
> > +
> > +=head1 NAME
> > +
> > +aa_stack_profile, aa_stack_onexec - combine multiple profiles to confine a
> > task
> >
On Mon, Jan 11, 2016 at 05:41:43PM -0800, John Johansen wrote:
> >> +Stacking another profile via aa_stack_profile() is permanent and the
> >> process is not
> >> +permitted to revert to the previous confinement context. Unlike
> >> +aa_change_profile(2), confined programs wanting to use aa_stack_
On 01/11/2016 05:02 PM, Seth Arnold wrote:
> Thanks for getting this started; some comments inline:
>
> On Mon, Jan 11, 2016 at 06:17:47PM -0600, Tyler Hicks wrote:
>> +=pod
>> +
>> +=head1 NAME
>> +
>> +aa_stack_profile, aa_stack_onexec - combine multiple profiles to confine a
>> task
>> +
>> +=
Thanks for getting this started; some comments inline:
On Mon, Jan 11, 2016 at 06:17:47PM -0600, Tyler Hicks wrote:
> +=pod
> +
> +=head1 NAME
> +
> +aa_stack_profile, aa_stack_onexec - combine multiple profiles to confine a
> task
> +
> +=head1 SYNOPSIS
> +
> +B<#include Esys/apparmor.hE>
> +
>
Modeled after the aa_change_profile(2) man page, this profile defines
the libapparmor and kernel interfaces for the in-progress profile
stacking feature.
Signed-off-by: Tyler Hicks
---
libraries/libapparmor/doc/Makefile.am | 2 +-
libraries/libapparmor/doc/aa_stack_profile.pod | 229 +
20 matches
Mail list logo
