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