Re: [apparmor] Note: NVIDIA drivers are mapping user-writable files by default

2018-02-16 Thread John Johansen 
On 02/16/2018 12:50 PM, Vincas Dargis wrote:
> On 2/16/18 10:19 PM, John Johansen wrote:
>> On 02/16/2018 12:09 PM, Vincas Dargis wrote:
>>> $ cat abstractions/nvidia
>>>
>>> if defined $nvidia_strict {
>>>    if not $nvidia_strict {
>>>  # allow possibly unsafe NVIDIA optimizations, see .
>>>  owner @{HOME}/#[0-9]* rwm,
>>>  owner @{HOME}/.glvnd[0-9]* rwm,
>>>  owner /tmp/.gl[0-9]* rwm,
>>>  owner /tmp/#[0-9]* rwm,
>>>  ...
>>>    }
>>> } else {
>>>    error $nvidia_strict is not defined, see abstractions/nvidia for more 
>>> info
>>> }
>>>
>>> If we could have parsing-time error/warning/assert statements, that would 
>>> force policy writer to explicitly decide on turning on or off specific 
>>> options, probably unavoidably reading comments on what do they mean, etc.
>>
>> yes parse time error, warning and asserts so policy can provide messages are 
>> on the todo list they just haven't been a high priority because conditionals 
>> have not been really used. That is about to change because policy versioning 
>> requires them
> 
> If we stick to this conditionals approach, I believe we are targeting fix for 
> this NVIDIA issue in no earlier than AppArmor 3.1 I guess?
> 
> This being said, can (and should) we do anything "now", for upcoming Ubuntu 
> 18.04 LTS, and anyone else being annoyed by these DENIED messages?
> 
> Maybe we just add appropriate `allow` rules into ``, 
> probably reducing security for some applications without real need too much, 
> but with the agreement that this temporary "over-permissiveness" is going to 
> be fixed in the future, by updating `` to have these 
> conditionals with error/assert messages?
> 
> Tails or anyone else could just patch  or specific 
> application profile to add explicit denies on the top if needed.

well error and warn are small patches we could certainly sneak into 3.0

I do think addressing it temporarily is the way to go, whether it is by doing 
the above without the error statement or just going with temporary 
"over-permissiveness"

another thought on the error and warn statements is that they could be

  #error message
and
  #warn message


so that they could be added now and just ignored as comments in earlier 
versions of apparmor

-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: [apparmor] Note: NVIDIA drivers are mapping user-writable files by default

2018-02-16 Thread Vincas Dargis 

On 2/16/18 10:19 PM, John Johansen wrote:

On 02/16/2018 12:09 PM, Vincas Dargis wrote:

$ cat abstractions/nvidia

if defined $nvidia_strict {
   if not $nvidia_strict {
     # allow possibly unsafe NVIDIA optimizations, see .
     owner @{HOME}/#[0-9]* rwm,
     owner @{HOME}/.glvnd[0-9]* rwm,
     owner /tmp/.gl[0-9]* rwm,
     owner /tmp/#[0-9]* rwm,
     ...
   }
} else {
   error $nvidia_strict is not defined, see abstractions/nvidia for more info
}

If we could have parsing-time error/warning/assert statements, that would force 
policy writer to explicitly decide on turning on or off specific options, 
probably unavoidably reading comments on what do they mean, etc.


yes parse time error, warning and asserts so policy can provide messages are on 
the todo list they just haven't been a high priority because conditionals have 
not been really used. That is about to change because policy versioning 
requires them


If we stick to this conditionals approach, I believe we are targeting 
fix for this NVIDIA issue in no earlier than AppArmor 3.1 I guess?


This being said, can (and should) we do anything "now", for upcoming 
Ubuntu 18.04 LTS, and anyone else being annoyed by these DENIED messages?


Maybe we just add appropriate `allow` rules into 
``, probably reducing security for some 
applications without real need too much, but with the agreement that 
this temporary "over-permissiveness" is going to be fixed in the future, 
by updating `` to have these conditionals with 
error/assert messages?


Tails or anyone else could just patch  or specific 
application profile to add explicit denies on the top if needed.


--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: [apparmor] Note: NVIDIA drivers are mapping user-writable files by default

2018-02-16 Thread John Johansen 
On 02/16/2018 12:09 PM, Vincas Dargis wrote:
> On 2/16/18 9:33 PM, John Johansen wrote:
>> On 02/16/2018 06:44 AM, Vincas Dargis wrote:
>>> Could you give example how this tunable + conditional would look like?
>>>
>> see below
>>
>>> Would this be per-machine or per policy decision (probably the latter)?
>>>
>> it could be setup either way, it would depend on how you setup the 
>> conditionals and tunable variable. With that said the tools 
>> (logprof,genprof,...) don't currently get along with conditionals.
>>
>> there are a couple ways to set this up, and there would certainly need to be 
>> some documentation/comments in the nvidia include as to how to 
>> enabled/disable.
>>
>> Assuming that strict is optional (you could always flip the logic with a 
>> negation and rename the var) Basically it would be something like
>>
>>    $ cat abstractions/nvidia
>>    # set $nvidia_strict to add
>>    if defined $nvidia_strict {
>>  ...
>>    }
>>    ... >
>>    $ cat profile
>>    include 
>>
>>    #opt in to strict nvidia mediation
>>    $nvidia_strict=true
>>
>>    profile example {
>>   include 
>>
>>   ...
>>    }
>>
>>
>> If you wanted to do it globally
>>    $ cat global/tunable
>>    # change value to true to enable nvidia strict enforcement
>>    $nvidia_strict=false
>>    ...
>>
>> and your nvidia include logic would drop the "defined" bit
>>
>>    $ cat abstractions/nvidia
>>    # set $nvidia_strict to add
>>    if $nvidia_strict {
>>  ...
>>    }
>>    ...
> 
> OK so I see two mechanisms, "if defined $var" and "if $var". I guess we could 
> avoid "forgot to read documentation" issue with this construct (not sure how 
> negation would look like, just a guess):
> 

yeah basically, if you know the var is going to be defined you can get away 
with an if $var, but if you are going to allow the profile to define then the 
if defined is needed because the parser will throw an error about on undefined 
var being used other wise

and your guess on inverting the logic is corrent

  if not $foo {

you can also do

  if not defined $foo {


> $ cat abstractions/nvidia
> 
> if defined $nvidia_strict {
>   if not $nvidia_strict {
>     # allow possibly unsafe NVIDIA optimizations, see .
>     owner @{HOME}/#[0-9]* rwm,
>     owner @{HOME}/.glvnd[0-9]* rwm,
>     owner /tmp/.gl[0-9]* rwm,
>     owner /tmp/#[0-9]* rwm,
>     ...
>   }
> } else {
>   error $nvidia_strict is not defined, see abstractions/nvidia for more info
> }
> 
> If we could have parsing-time error/warning/assert statements, that would 
> force policy writer to explicitly decide on turning on or off specific 
> options, probably unavoidably reading comments on what do they mean, etc.

yes parse time error, warning and asserts so policy can provide messages are on 
the todo list they just haven't been a high priority because conditionals have 
not been really used. That is about to change because policy versioning 
requires them


-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: [apparmor] Note: NVIDIA drivers are mapping user-writable files by default

2018-02-16 Thread Vincas Dargis 

On 2/16/18 9:33 PM, John Johansen wrote:

On 02/16/2018 06:44 AM, Vincas Dargis wrote:

Could you give example how this tunable + conditional would look like?


see below


Would this be per-machine or per policy decision (probably the latter)?


it could be setup either way, it would depend on how you setup the conditionals 
and tunable variable. With that said the tools (logprof,genprof,...) don't 
currently get along with conditionals.

there are a couple ways to set this up, and there would certainly need to be 
some documentation/comments in the nvidia include as to how to enabled/disable.

Assuming that strict is optional (you could always flip the logic with a 
negation and rename the var) Basically it would be something like

   $ cat abstractions/nvidia
   # set $nvidia_strict to add
   if defined $nvidia_strict {
 ...
   }
   ... >
   $ cat profile
   include 

   #opt in to strict nvidia mediation
   $nvidia_strict=true

   profile example {
  include 

  ...
   }


If you wanted to do it globally
   $ cat global/tunable
   # change value to true to enable nvidia strict enforcement
   $nvidia_strict=false
   ...

and your nvidia include logic would drop the "defined" bit

   $ cat abstractions/nvidia
   # set $nvidia_strict to add
   if $nvidia_strict {
 ...
   }
   ...


OK so I see two mechanisms, "if defined $var" and "if $var". I guess we 
could avoid "forgot to read documentation" issue with this construct 
(not sure how negation would look like, just a guess):


$ cat abstractions/nvidia

if defined $nvidia_strict {
  if not $nvidia_strict {
# allow possibly unsafe NVIDIA optimizations, see .
owner @{HOME}/#[0-9]* rwm,
owner @{HOME}/.glvnd[0-9]* rwm,
owner /tmp/.gl[0-9]* rwm,
owner /tmp/#[0-9]* rwm,
...
  }
} else {
  error $nvidia_strict is not defined, see abstractions/nvidia for more 
info

}

If we could have parsing-time error/warning/assert statements, that 
would force policy writer to explicitly decide on turning on or off 
specific options, probably unavoidably reading comments on what do they 
mean, etc.


--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: [apparmor] Note: NVIDIA drivers are mapping user-writable files by default

2018-02-16 Thread John Johansen 
On 02/16/2018 06:44 AM, Vincas Dargis wrote:
> On 2/11/18 11:38 PM, John Johansen wrote:
>> On 02/11/2018 02:42 AM, Vincas Dargis wrote:
>>> So to wrap up, plan would be:
>>>
>>> 1. Move `abstactions/nvidia` content into `nvidia-strict`. `nvidia-strict` 
>>> should have comment that it does not provide some NVIDIA optimizations and 
>>> some `deny` rules are recommended to be added manually. Else, suggest to 
>>> use `nvidia` if really needed.
>>>
>>> 2. Create new `abstractions/nvidia` that includes `nvidia-strict`. Add a 
>>> _big_ warning documenting that it provides NVIDIA optimization that could 
>>> potentially reduce security, suggest to use `nvidia-strict` for 
>>> non-performance-critical applications instead.
>>>
>>> In the future:
>>>
>>> 3. Deny these optimizations in `nvidia-strict` by default, add overrides 
>>> into `nvidia` abstraction when that's becomes possible.
>>>
>>> ACK?
>>>
>>> Any more alternatives?
>>>
>>> [0] https://gitlab.com/apparmor/apparmor/wikis/home#description
>>>
>>
>> I'm not against the plan, I do worry about being too strict causing 
>> problems, and I think the tunable + conditional might (I am not sure yet) a 
>> better way to go
> 
> Could you give example how this tunable + conditional would look like?
> 
see below

> Would this be per-machine or per policy decision (probably the latter)?
> 
it could be setup either way, it would depend on how you setup the conditionals 
and tunable variable. With that said the tools (logprof,genprof,...) don't 
currently get along with conditionals.

there are a couple ways to set this up, and there would certainly need to be 
some documentation/comments in the nvidia include as to how to enabled/disable.

Assuming that strict is optional (you could always flip the logic with a 
negation and rename the var) Basically it would be something like

  $ cat abstractions/nvidia
  # set $nvidia_strict to add
  if defined $nvidia_strict {
...
  }
  ...

  $ cat profile
  include 

  #opt in to strict nvidia mediation
  $nvidia_strict=true

  profile example {
 include 

 ...
  }


If you wanted to do it globally
  $ cat global/tunable
  # change value to true to enable nvidia strict enforcement
  $nvidia_strict=false
  ...

and your nvidia include logic would drop the "defined" bit

  $ cat abstractions/nvidia
  # set $nvidia_strict to add
  if $nvidia_strict {
...
  }
  ...

  

> 
> Now for the Jamie suggestion:
> 
> On 2/12/18 7:40 PM, Jamie Strandboge wrote:
>> This is what I initially recommended but based on your later
>> investigations I later recommended something different. I now suggest
>> simply:
>>
>> 1. update the nvidia abstraction to have comment that it does not
>> provide some NVIDIA optimizations and to either add `deny` rules
>> manually to silence the denials or add allow rules if want the
>> optimizations. Both sets of rules would be commented out in the nvidia
>> abstraction under the aforementioned comment.
>>
> 
> Sorry, I misunderstood your suggestion. So it's basically approach using 
> documentation only?
> 
> There could be another approach without "deny and then override" that John 
> didn't show affection for:
> 
> 1.  Left unchanged, except maybe adding info about 
> missing permissions for possibly unsafe optimization, hint how to fix that
> 
> 2.a new  abstraction that includes 
>  and allows rules for optimizations.
> 
> 2.b new  abstraction that includes 
>  and denies optmiziations.
> 
> usr.bin.thunderbird could be updated to change "nvidia" into 
> "nvidia-without-optimizations" and "usr.lib.ioquake3.ioquake3" could be 
> updated to include "nvidia-with-optimizations" instead.
> 
> Now I'm still interested in that "tunable + conditiona"l, though I would like 
> to see how that would work. It smells like something more modern and cleaner 
> approach? :)


-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: [apparmor] Note: NVIDIA drivers are mapping user-writable files by default

2018-02-16 Thread Vincas Dargis 

On 2/11/18 11:38 PM, John Johansen wrote:

On 02/11/2018 02:42 AM, Vincas Dargis wrote:

So to wrap up, plan would be:

1. Move `abstactions/nvidia` content into `nvidia-strict`. `nvidia-strict` 
should have comment that it does not provide some NVIDIA optimizations and some 
`deny` rules are recommended to be added manually. Else, suggest to use 
`nvidia` if really needed.

2. Create new `abstractions/nvidia` that includes `nvidia-strict`. Add a _big_ 
warning documenting that it provides NVIDIA optimization that could potentially 
reduce security, suggest to use `nvidia-strict` for non-performance-critical 
applications instead.

In the future:

3. Deny these optimizations in `nvidia-strict` by default, add overrides into 
`nvidia` abstraction when that's becomes possible.

ACK?

Any more alternatives?

[0] https://gitlab.com/apparmor/apparmor/wikis/home#description



I'm not against the plan, I do worry about being too strict causing problems, 
and I think the tunable + conditional might (I am not sure yet) a better way to 
go


Could you give example how this tunable + conditional would look like?

Would this be per-machine or per policy decision (probably the latter)?


Now for the Jamie suggestion:

On 2/12/18 7:40 PM, Jamie Strandboge wrote:
> This is what I initially recommended but based on your later
> investigations I later recommended something different. I now suggest
> simply:
>
> 1. update the nvidia abstraction to have comment that it does not
> provide some NVIDIA optimizations and to either add `deny` rules
> manually to silence the denials or add allow rules if want the
> optimizations. Both sets of rules would be commented out in the nvidia
> abstraction under the aforementioned comment.
>

Sorry, I misunderstood your suggestion. So it's basically approach using 
documentation only?


There could be another approach without "deny and then override" that 
John didn't show affection for:


1.  Left unchanged, except maybe adding info about 
missing permissions for possibly unsafe optimization, hint how to fix that


2.a new  abstraction that 
includes  and allows rules for optimizations.


2.b new  abstraction that 
includes  and denies optmiziations.


usr.bin.thunderbird could be updated to change "nvidia" into 
"nvidia-without-optimizations" and "usr.lib.ioquake3.ioquake3" could be 
updated to include "nvidia-with-optimizations" instead.


Now I'm still interested in that "tunable + conditiona"l, though I would 
like to see how that would work. It smells like something more modern 
and cleaner approach? :)


--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: [apparmor] IPC and sockets

2018-02-16 Thread Viacheslav Salnikov 
Many thanks, friends!

You gave me information I was looking for.

2018-02-15 21:37 GMT+02:00 John Johansen :

> On 02/15/2018 07:21 AM, Viacheslav Salnikov wrote:
> > OK, let me be more specific:
> >
> > does AppArmor complain about communication through the unix domain
> sockets into dmesg?
> >
> yes
>
> > All I've got - AppArmor can restrict access to named unix socket as a
> file - because it is a file - without using "deny unix". Actually, deny
> unix does not work for me with named sockets.
> >
> >
> currently the unix fs sockets can only be mediated as files without typing
> info. This will be extended, but there hasn't been a decision as to whether
> it is done through a file conditional
>
> something like
>
>   type=af_unix /foo rw,
>
> or whether its through the socket rules
>
>
-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor