On 2/6/18 9:25 PM, Jamie Strandboge wrote:
Anyway, do we _really_ want to allow mmap on writable files..?
Not usually, but in the case of actual shared memory files, there isn't
another choice atm. Some day we'll mediate shared memory with non-file
rules[1].
There is a choice to deny it. Since these... paths (not originally
intended to be a "physical file", except to these .gl*) are requested to
be mmap'ed for execution, some _real_ file named @{HOME}/#3141528 or
/tmp/.glMy1337Exploit could be loaded to enhance attack further. Or mine
Monero or smth. Or scan Thunderbird's memory for passwords.
I would, again, suggest to deny these with hope we would have a way
to
override denies in the future (John mentioned something in that
regard)
for some high performance 3D application really needs these NVIDIA
optimizations to be available, maybe in
`abstractions/nvidia-unsafe-optimizations`
abstraction.
I'm not sure this is the best way to handle this. Remember, explicit
deny rules are evaluated after deny rules so adding explicit deny rules
for these files means that an abstraction like nvidia-unsafe-
optimizations wouldn't be able to undo the deny (I guess this is what
you meant by overriding denies).
I've meant a new feature (we don't currently have) to override a `deny`,
like a higher priority level. JJ was talking about that possibility in
the future, in IRC I believe. If that get's designed I guess.
Maybe having something like `override allow @{HOME}/#[0-8]* rwm` would
override that default `deny @{HOME}/#[0-8]* rwm` in
`abstractions/nvidia`, for some exceptional cases, like in Blender
application where real time 3D graphics performance is _very_ important
(if it would ever have AppArmor profile.. but that's just an example).
I'm betting on this because it doesn't seem we have a lot of
graphic-intensive applications with AppArmor profile that might feel a
hit due to disabled optional NVIDIA optimizations.
Furthermore, as a user, if I had an nvidia card I would expect that the
nvidia abstraction would allow 3D acceleration to work and it sounds
like nvidia changed the way their shared memory works (again, I don't
have an nvidia system and basing this on the fact that these denials
are only showing up now).
3D acceleration works fine with denies. It is only a additional
optimization NVIDIA have implemented. It is even documented that it does
not work on systems like SELinux and GRSecurity.
From "Disabling executable memory optimizations" [0]:
quote
By default, the NVIDIA driver will attempt to use optimizations which
rely on being able to write to executable memory. This may cause
problems in certain system configurations (e.g., on SELinux when the
"allow_execmem" boolean is disabled or "deny_execmem" boolean is
enabled, and on grsecurity kernels configured with CONFIG_PAX_MPROTECT).
When possible, the driver will attempt to detect when it is running on
an unsupported configuration and disable these optimizations
automatically. If the __GL_WRITE_TEXT_SECTION environment variable is
set to 0, the driver will unconditionally disable these optimizations.
end quote.
So, if they disable them on SELinux and/or grsecurity kernels, we could
disable it by ourselves for AppArmor cases. Again, 3D acceleration works
fine with these denies (I use home-grew Wine and Steam profiles without
allowing these).
I would instead suggest that *if* we wanted
to split these accesses, we do something more like:
* abstractions/nvidia-strict: all the safe accesses
* abstractions/nvidia: #include nvidia-strict plus less desirable
accesses
In this manner, profiles continue to work with new nvidia accesses, but
profilers can choose to do something more strict if they desire.
So if profile includes `<abstractions/nvidia-strict>`, they would have
to add these
`deny @{HOME}/#[0-8]* rwm`,
`deny /tmp/.gl* rwm`
manually, in addition to the include?
If non-strict `abstractions/nvidia` include is left where it is now,
that means in current state, Thunderbird, Firefox, Totem, and now I see
Libreofice (running with `optirun`, to enabled discrete NVIDIA card, I
see deny for nvidia-specific /usr/bin/nvidia-modrpobe, so include is
needed there too) will have their security downgraded by default, and
these does not look like graphic intensive apps. Meanwhile, updating
these profiles would be too much a fuzz for a _optional_ NVIDIA
optimizations, IMHO. While for security, I'm fuzzing here to defend :) .
[1]https://bugs.launchpad.net/apparmor/+bug/1370218
[0]
https://download.nvidia.com/XFree86/Linux-x86_64/390.25/README/openglenvvariables.html#disableexecmem
--
AppArmor mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
