On Thu, May 09, 2013 at 02:41:19PM -0700, John Johansen wrote:
> On 05/09/2013 02:12 PM, Jamie Strandboge wrote:
> > Perhaps the problem is that the mixture of optional clauses in the
> > syntax which makes the placement of access rules awkward. Ie, we always
> > must have:
> >
> > dbus ,
> >
>
On Thu, May 09, 2013 at 03:27:24PM -0700, Tyler Hicks wrote:
> > dbus [address spec] acquire, # unchanged
> > dbus [address spec] -> [address spec], # unidirectional
> > dbus [address spec] <- [address spec], # unidirectional
> > dbus [address spec] <-> [address spec], # bidirectional
> I'm all
On 05/09/2013 03:15 PM, Seth Arnold wrote:
> On Thu, May 09, 2013 at 03:08:35PM -0700, John Johansen wrote:
>> it depends how you look at it. To me it is changing the meaning of ->
>> of course I am now convinced that -> is just wrong and we need different
>> syntax, because -> just seems to have t
On 2013-05-09 15:15:50, Seth Arnold wrote:
> On Thu, May 09, 2013 at 03:08:35PM -0700, John Johansen wrote:
> > it depends how you look at it. To me it is changing the meaning of ->
> > of course I am now convinced that -> is just wrong and we need different
> > syntax, because -> just seems to hav
On 2013-05-09 15:08:35, John Johansen wrote:
> On 05/09/2013 02:59 PM, Tyler Hicks wrote:
> > On 2013-05-09 14:51:38, John Johansen wrote:
> >> On 05/09/2013 02:39 PM, Tyler Hicks wrote:
> >>> On 2013-05-09 14:30:32, John Johansen wrote:
> On 05/09/2013 02:13 PM, Tyler Hicks wrote:
> > On
On Thu, May 09, 2013 at 03:08:35PM -0700, John Johansen wrote:
> it depends how you look at it. To me it is changing the meaning of ->
> of course I am now convinced that -> is just wrong and we need different
> syntax, because -> just seems to have too many potential different
> interpretations th
On 05/09/2013 02:59 PM, Tyler Hicks wrote:
> On 2013-05-09 14:51:38, John Johansen wrote:
>> On 05/09/2013 02:39 PM, Tyler Hicks wrote:
>>> On 2013-05-09 14:30:32, John Johansen wrote:
On 05/09/2013 02:13 PM, Tyler Hicks wrote:
> On 2013-05-09 14:04:20, Seth Arnold wrote:
>> On Thu, Ma
On 2013-05-09 14:51:38, John Johansen wrote:
> On 05/09/2013 02:39 PM, Tyler Hicks wrote:
> > On 2013-05-09 14:30:32, John Johansen wrote:
> >> On 05/09/2013 02:13 PM, Tyler Hicks wrote:
> >>> On 2013-05-09 14:04:20, Seth Arnold wrote:
> On Thu, May 09, 2013 at 01:45:04PM -0700, Tyler Hicks wr
On 2013-05-09 16:37:06, Jamie Strandboge wrote:
> On 05/09/2013 04:13 PM, Tyler Hicks wrote:
>
> > Take this rule for example:
> >
> > dbus bus=session -> name=com.example.service path=/com/example/service
> > interface=com.example.service receive,
> >
> > If we adjust our thinking a little i
On 05/09/2013 02:39 PM, Tyler Hicks wrote:
> On 2013-05-09 14:30:32, John Johansen wrote:
>> On 05/09/2013 02:13 PM, Tyler Hicks wrote:
>>> On 2013-05-09 14:04:20, Seth Arnold wrote:
On Thu, May 09, 2013 at 01:45:04PM -0700, Tyler Hicks wrote:
> I think that we're mostly ok. We just need t
On 05/09/2013 04:41 PM, John Johansen wrote:
> On 05/09/2013 02:12 PM, Jamie Strandboge wrote:
>> Since *always* applies to , maybe it makes sense to
>> have it be next to it. Ie:
>>
>> dbus [] [],
>>
>> such that:
>>
>> profile subject {
>> dbus name=well.known.address acquire,
>> dbus na
On 05/09/2013 02:26 PM, Jamie Strandboge wrote:
> On 05/09/2013 04:12 PM, Jamie Strandboge wrote:
>
>> Since *always* applies to , maybe it makes sense to
>> have it be next to it. Ie:
>>
>> dbus [] [],
>>
>> such that:
>>
>> profile subject {
>> dbus name=well.known.address acquire,
>> db
On 05/09/2013 02:12 PM, Jamie Strandboge wrote:
> On 05/09/2013 03:35 PM, John Johansen wrote:
>> On 05/09/2013 01:20 PM, Jamie Strandboge wrote:
>>> On 05/09/2013 02:41 PM, John Johansen wrote:
Lets look at it as local (subject) address and remote/peer address
profile subject {
On 2013-05-09 14:30:32, John Johansen wrote:
> On 05/09/2013 02:13 PM, Tyler Hicks wrote:
> > On 2013-05-09 14:04:20, Seth Arnold wrote:
> >> On Thu, May 09, 2013 at 01:45:04PM -0700, Tyler Hicks wrote:
> >>> I think that we're mostly ok. We just need to think about it a little
> >>> differently. H
On 05/09/2013 04:13 PM, Tyler Hicks wrote:
> Take this rule for example:
>
> dbus bus=session -> name=com.example.service path=/com/example/service
> interface=com.example.service receive,
>
> If we adjust our thinking a little it could mean, "a message that flows
> FROM anywhere TO com.examp
On 05/09/2013 04:12 PM, Jamie Strandboge wrote:
> On 05/09/2013 03:35 PM, John Johansen wrote:
>> On 05/09/2013 01:20 PM, Jamie Strandboge wrote:
>>> On 05/09/2013 02:41 PM, John Johansen wrote:
Lets look at it as local (subject) address and remote/peer address
profile subject {
On 05/09/2013 02:13 PM, Tyler Hicks wrote:
> On 2013-05-09 14:04:20, Seth Arnold wrote:
>> On Thu, May 09, 2013 at 01:45:04PM -0700, Tyler Hicks wrote:
>>> I think that we're mostly ok. We just need to think about it a little
>>> differently. Here's the current syntax:
>>>
>>> DBUS RULE = [ 'audit'
On 05/09/2013 02:04 PM, Seth Arnold wrote:
> On Thu, May 09, 2013 at 01:45:04PM -0700, Tyler Hicks wrote:
>> I think that we're mostly ok. We just need to think about it a little
>> differently. Here's the current syntax:
>>
>> DBUS RULE = [ 'audit' ] [ 'deny' ] 'dbus' [ DBUS BUS ] [ ( DBUS LOCAL
On 05/09/2013 04:12 PM, Jamie Strandboge wrote:
> Since *always* applies to , maybe it makes sense to
> have it be next to it. Ie:
>
> dbus [] [],
>
> such that:
>
> profile subject {
> dbus name=well.known.address acquire,
> dbus name=well.known.address receive,
> dbus send -> name=a
On 2013-05-09 14:04:20, Seth Arnold wrote:
> On Thu, May 09, 2013 at 01:45:04PM -0700, Tyler Hicks wrote:
> > I think that we're mostly ok. We just need to think about it a little
> > differently. Here's the current syntax:
> >
> > DBUS RULE = [ 'audit' ] [ 'deny' ] 'dbus' [ DBUS BUS ] [ ( DBUS LO
On 05/09/2013 03:35 PM, John Johansen wrote:
> On 05/09/2013 01:20 PM, Jamie Strandboge wrote:
>> On 05/09/2013 02:41 PM, John Johansen wrote:
>>>
>>> Lets look at it as local (subject) address and remote/peer address
>>>
>>> profile subject {
>>>
>>> dbus name=well.known.address acquire,
>>>
>>>
On 05/09/2013 01:45 PM, Tyler Hicks wrote:
> On 2013-05-09 13:35:11, John Johansen wrote:
>> On 05/09/2013 01:20 PM, Jamie Strandboge wrote:
>>> On 05/09/2013 02:41 PM, John Johansen wrote:
Lets look at it as local (subject) address and remote/peer address
profile subject {
On Thu, May 09, 2013 at 01:45:04PM -0700, Tyler Hicks wrote:
> I think that we're mostly ok. We just need to think about it a little
> differently. Here's the current syntax:
>
> DBUS RULE = [ 'audit' ] [ 'deny' ] 'dbus' [ DBUS BUS ] [ ( DBUS LOCAL
> CONDITIONS | -> DBUS REMOTE CONDITIONS ) ] [
On 2013-05-09 13:37:00, John Johansen wrote:
> On 05/09/2013 01:32 PM, Tyler Hicks wrote:
> > On 2013-05-09 15:20:56, Jamie Strandboge wrote:
> >> On 05/09/2013 02:41 PM, John Johansen wrote:
> >>>
> >>> Lets look at it as local (subject) address and remote/peer address
> >>>
> >>> profile subject
On 2013-05-09 13:35:11, John Johansen wrote:
> On 05/09/2013 01:20 PM, Jamie Strandboge wrote:
> > On 05/09/2013 02:41 PM, John Johansen wrote:
> >>
> >> Lets look at it as local (subject) address and remote/peer address
> >>
> >> profile subject {
> >>
> >> dbus name=well.known.address acquire,
On 05/09/2013 01:32 PM, Tyler Hicks wrote:
> On 2013-05-09 15:20:56, Jamie Strandboge wrote:
>> On 05/09/2013 02:41 PM, John Johansen wrote:
>>>
>>> Lets look at it as local (subject) address and remote/peer address
>>>
>>> profile subject {
>>>
>>> dbus name=well.known.address acquire,
>>>
>>>
On 05/09/2013 01:20 PM, Jamie Strandboge wrote:
> On 05/09/2013 02:41 PM, John Johansen wrote:
>>
>> Lets look at it as local (subject) address and remote/peer address
>>
>> profile subject {
>>
>> dbus name=well.known.address acquire,
>>
>> dbus name=well.known.address receive, #subject can r
On 2013-05-09 15:20:56, Jamie Strandboge wrote:
> On 05/09/2013 02:41 PM, John Johansen wrote:
> >
> > Lets look at it as local (subject) address and remote/peer address
> >
> > profile subject {
> >
> > dbus name=well.known.address acquire,
> >
> > dbus name=well.known.address receive, #s
On 05/09/2013 02:41 PM, John Johansen wrote:
>
> Lets look at it as local (subject) address and remote/peer address
>
> profile subject {
>
> dbus name=well.known.address acquire,
>
> dbus name=well.known.address receive, #subject can receive messages on
> this well.known.address
>
> d
On 05/09/2013 12:18 PM, Christian Boltz wrote:
> Hello,
>
> Am Donnerstag, 9. Mai 2013 schrieb John Johansen:
>> On 05/09/2013 07:16 AM, Christian Boltz wrote:
>>> Could we just switch it to the way that is also used for send?
>>> I'd propose
>>>
>>> dbus name=sender.com -> name=receiver.com r
Hello,
Am Donnerstag, 9. Mai 2013 schrieb John Johansen:
> On 05/09/2013 07:16 AM, Christian Boltz wrote:
> > Could we just switch it to the way that is also used for send?
> > I'd propose
> >
> > dbus name=sender.com -> name=receiver.com receive,
> >
> > Advantages are:
> > - we can keep th
On 05/09/2013 10:55 AM, Seth Arnold wrote:
> On Thu, May 09, 2013 at 02:58:40AM -0700, John Johansen wrote:
-static struct aa_fs_entry aa_fs_entry =
- AA_FS_DIR("apparmor", aa_fs_entry_apparmor);
+static struct aa_fs_entry aa_fs_entry[] = {
+ AA_FS_DIR("apparmor", aa_fs_entry_
On Thu, May 09, 2013 at 02:58:40AM -0700, John Johansen wrote:
> >> -static struct aa_fs_entry aa_fs_entry =
> >> - AA_FS_DIR("apparmor", aa_fs_entry_apparmor);
> >> +static struct aa_fs_entry aa_fs_entry[] = {
> >> + AA_FS_DIR("apparmor", aa_fs_entry_apparmor),
> >> + { }
> >> +};
> >
> > I di
On 05/09/2013 07:16 AM, Christian Boltz wrote:
> Hello,
>
> Am Mittwoch, 8. Mai 2013 schrieb John Johansen:
>> On 05/08/2013 05:23 PM, Tyler Hicks wrote:
>>> On 2013-05-08 14:43:59, John Johansen wrote:
>>> The arrow notation make sense in this example, but I just realized
>>> how confusing it is
Hello,
Am Mittwoch, 8. Mai 2013 schrieb John Johansen:
> On 05/08/2013 05:23 PM, Tyler Hicks wrote:
> > On 2013-05-08 14:43:59, John Johansen wrote:
> > The arrow notation make sense in this example, but I just realized
> > how confusing it is if we need to specify the receive permission
> > inste
On 05/08/2013 08:13 PM, Seth Arnold wrote:
> On Wed, May 01, 2013 at 02:30:56PM -0700, John Johansen wrote:
>> Add basic interface files to access namespace and profile information.
>> The interface files are created when a profile is loaded and removed
>> when the profile or namespace is removed.
On 05/08/2013 05:48 PM, Seth Arnold wrote:
> On Wed, May 01, 2013 at 02:30:54PM -0700, John Johansen wrote:
>> The default profile needs its replaced by information set as its on
>> the profile list and will have an fs interface (and the fs interface
>> files require a valid replacedby).
>>
>> Sign
On 05/09/2013 02:27 AM, John Johansen wrote:
> On 05/08/2013 02:37 PM, Seth Arnold wrote:
>> On Wed, May 01, 2013 at 02:30:47PM -0700, John Johansen wrote:
>>
<< snip >>
>> released (which means they take ns->unconfined->label for themselves),
>> and then ns->unconfined is replaced with ns->par
On 05/08/2013 05:40 PM, Seth Arnold wrote:
> On Wed, May 01, 2013 at 02:30:53PM -0700, John Johansen wrote:
>> --- a/security/apparmor/Kconfig
>> +++ b/security/apparmor/Kconfig
>> @@ -29,3 +29,14 @@ config SECURITY_APPARMOR_BOOTPARAM_VALUE
>>boot.
>>
>>If you are unsure how to an
On 05/07/2013 06:09 PM, Seth Arnold wrote:
> On Wed, May 01, 2013 at 02:30:48PM -0700, John Johansen wrote:
>> remove the use of replaced by chaining and move to profile invalidation
>> and lookup to handle task replacement.
>>
>> Replacement chaining can result in large chains of profiles being pi
On 05/08/2013 02:37 PM, Seth Arnold wrote:
> On Wed, May 01, 2013 at 02:30:47PM -0700, John Johansen wrote:
>
> I just noticed that these changes have swapped the order of two
> operations. Previously, ns->unconfined was updated to
> ns->parent->unconfined before all the profiles in the namespace
41 matches
Mail list logo
