[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