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

Vincas Dargis vindrg at gmail.com
Fri Feb 16 20:50:30 UTC 2018


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.



More information about the AppArmor mailing list