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

John Johansen john.johansen at canonical.com
Fri Feb 16 22:12:58 UTC 2018


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 <link>.
>>>      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 `<abstractions/nvidia>`, 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 `<abstractions/nvidia>` to have these conditionals with error/assert messages?
> 
> Tails or anyone else could just patch <abstractions/nvidia> 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



More information about the AppArmor mailing list