[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