[opensuse-security] FYI AppArmor abstraction for AMD proprietary driver
This is an abstraction for those folks who prefer to use the proprietary AMD driver It needs to be added to every profile for X11 apps. It may be more convenient to copy the whole rule into abstractions/x to avoid changing existing profiles. To be honest, this is, what I did when I used fglrx.
Hello, Am Dienstag, 13. September 2016, 10:12:13 CEST schrieb Malte Gell:
This is an abstraction for those folks who prefer to use the proprietary AMD driver
It needs to be added to every profile for X11 apps.
It may be more convenient to copy the whole rule into abstractions/x to avoid changing existing profiles. To be honest, this is, what I did when I used fglrx.
I consider submitting this abstraction upstream, but before doing so, I have some questions. Note that I don't have any AMD graphics card, so some questions might sound silly or obvious to you ;-)
/proc/ati r,
I assume /proc/ati is a directory (at least the next rule indicates this). That would mean that the rule needs a trailing slash ("/proc/ati/ r,") - and could also mean that this rule isn't needed at all because in its current state, it doesn't allow anything. Can you please remove this rule and test if something complains?
/proc/ati/** r, /dev/ati rw,
Same questions as above for /dev/ati - the /dev/ati/* rule indicates this is a directory.
/dev/video* rw, /dev/ati/* rw, /etc/ati r,
Same questions once more, this time for /etc/ati ;-)
/etc/ati/** r, /etc/ati/authatieventsd.sh Ux,
What does this script do? We avoid Ux rules whenever possible (because they allow to execute something unconfined = without AppArmor restrictions), so you should have a *very* good reason to use Ux ;-)
/dev/shm/ rwkl,
Hmm, wkl permissions for the directory? That looks superfluous to me - r should be enough.
/dev/shm/* rwkl,
Reading and writing all files in /dev/shm/ (which is world-writeable like /tmp/) doesn't sound too neat. Would it be possible to restrict that rule by using a filename pattern and/or adding the "owner" conditional? Ideally you'll end up with something like owner /dev/shm/ati* rwkl, # filename pattern "ati*" is just a guess
/home/*/.AMD/ rwkl, /home/*/.AMD/** rwkl,
Interesting - does the AMD driver really need write access in the user's home directory? Or is it only needed by the config tool? (assuming there is a config tool ;-) If these rules are really needed, adding the "owner" conditional would be a good idea to ensure it doesn't touch someone else' home directory. Regards, Christian Boltz -- Die Idee war gut - der Code nicht. (Ralf wrde sagen: Es war so schlecht, dass ich es umschreiben musste bevor ich es wegwarf...) [Patrick Ben Koetter in postfix-users]
Am 09.10.2016 um 17:45 schrieb Christian Boltz:
Can you please remove this rule and test if something complains?
Well, I have switched to the open source driver in Leap kernel 4.1, thus can´t test it..... The open source driver has a bit less performance, but is stable and lacks some bugs, the proprietary driver has.
/dev/video* rw, /dev/ati/* rw, /etc/ati r,
Same questions once more, this time for /etc/ati ;-)
I just added these permissions to satisfy AppArmor. Without setting these, I had some AA log entries.
/etc/ati/** r, /etc/ati/authatieventsd.sh Ux,
What does this script do?
This script grants access to some AMD "event daemon", I guess this thing checks for updates or maybe some hardware events triggered by the GPU, but this is just a guess. I have attached the script, so you can take a look at it. It looks pretty harmless to me.
We avoid Ux rules whenever possible (because they allow to execute something unconfined = without AppArmor restrictions), so you should have a *very* good reason to use Ux ;-)
/dev/shm/ rwkl,
Hmm, wkl permissions for the directory? That looks superfluous to me - r should be enough.
True
/dev/shm/* rwkl,
Reading and writing all files in /dev/shm/ (which is world-writeable like /tmp/) doesn't sound too neat. Would it be possible to restrict that rule by using a filename pattern and/or adding the "owner" conditional?
I think adding "owner" should be fine. But, as mentioned, I switched to the open source driver recently....
/home/*/.AMD/ rwkl, /home/*/.AMD/** rwkl,
Interesting - does the AMD driver really need write access in the user's home directory? Or is it only needed by the config tool? (assuming there is a config tool ;-)
Yes, there is a config tool. This directory is a cache directory for OpenGL stuff. The proprietary nVidia driver also uses a user space cache directory with the name ~/.nv/
If these rules are really needed, adding the "owner" conditional would be a good idea to ensure it doesn't touch someone else' home directory.
Sure, using "owner" should be fine there. But, AMD is working on a new generation of proprietary driver, they haven´t their current (=old) proprietary time for 10 months now! Kernel 4.4 and above has an updated AMD driver named amdgpu which will also be the basis for the new AMD proprietary driver. Thus, people with the latest AMD GPUs actually use the latest kernels, because they have the necessary support the old proprietary driver does not have. In other words, folks who run the latest AMD GPU depend on the latest kernels and not the current (old) AMD prop stuff, thus the number of people using the current (= now old) AMD prop driver should be very, very small. IMHO it may be best to wait until AMD releases their new generation proprietary driver and then adjust this AA rule. To add this rule to Leap 42.2 may not make much sense, because people with latest AMD GPU depend on the latest open source driver anyways.... Best regards
Hello, Am Montag, 10. Oktober 2016, 00:15:51 CEST schrieb Malte Gell:
Am 09.10.2016 um 17:45 schrieb Christian Boltz:
Can you please remove this rule and test if something complains?
Well, I have switched to the open source driver in Leap kernel 4.1, thus can´t test it..... The open source driver has a bit less performance, but is stable and lacks some bugs, the proprietary driver has.
Stable and a bit slower sounds better than buggy ;-)
/dev/video* rw, /dev/ati/* rw, /etc/ati r,
Same questions once more, this time for /etc/ati ;-)
I just added these permissions to satisfy AppArmor. Without setting these, I had some AA log entries.
I'd be quite surprised if the directory rules without trailing slash helped ;-) (unless your profile is *very* old - the trailing slash requirement for directories was added to the apparmor.d manpage in April 2007)
/etc/ati/** r, /etc/ati/authatieventsd.sh Ux,
What does this script do?
This script grants access to some AMD "event daemon", I guess this thing checks for updates or maybe some hardware events triggered by the GPU, but this is just a guess. I have attached the script, so you can take a look at it. It looks pretty harmless to me.
It would still make sense not to run it unconfined, and create a profile for it instead. For example, I noticed several uses of unquoted $1, $2 and $3 which could lead to funny[tm] results (no, I didn't test what could happen ;-) [...]
/home/*/.AMD/ rwkl, /home/*/.AMD/** rwkl,
Interesting - does the AMD driver really need write access in the user's home directory? Or is it only needed by the config tool? (assuming there is a config tool ;-)
Yes, there is a config tool. This directory is a cache directory for OpenGL stuff. The proprietary nVidia driver also uses a user space cache directory with the name ~/.nv/
Right, I should have checked that in abstractions/nvidia myself ;-) (that said - a file cache for the screen content? seriously?)
If these rules are really needed, adding the "owner" conditional would be a good idea to ensure it doesn't touch someone else' home directory. Sure, using "owner" should be fine there.
But, AMD is working on a new generation of proprietary driver, they haven´t their current (=old) proprietary time for 10 months now! Kernel 4.4 and above has an updated AMD driver named amdgpu which will also be the basis for the new AMD proprietary driver. Thus, people with the latest AMD GPUs actually use the latest kernels, because they have the necessary support the old proprietary driver does not have.
In other words, folks who run the latest AMD GPU depend on the latest kernels and not the current (old) AMD prop stuff, thus the number of people using the current (= now old) AMD prop driver should be very, very small.
IMHO it may be best to wait until AMD releases their new generation proprietary driver and then adjust this AA rule. To add this rule to Leap 42.2 may not make much sense, because people with latest AMD GPU depend on the latest open source driver anyways....
I fully agree - this sounds like a moving target which isn't really used and tested, so waiting for a while is indeed a good idea. Feel free to send an updated amdfglrx abstraction once you use the [new version of the] propietary AMD driver again ;-) Regards, Christian Boltz -- Speak out freely, of course, but don't start dissing part of the community on their personal opinions. One may only do that with trolls ;) [Pascal Bleser in opensuse-factory] -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
participants (2)
-
Christian Boltz -
Malte Gell