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
--
AppArmor mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
