Both ATI and Nvidia's proprietary video driver installation utilities
replace the Red Hat supplied libGL library with their own libGL.
Could SELinux be used to prevent this and, more generally, disallow
replacement of rpm-controlled files even by the root user ?
Yes it should be possible to do this. However, you need some way to distinguish
updates of those libraries when done normally as opposed to being done by
ATI or Nvidia code. What you would probably like to do is only let rpm
change those files. However if ATI and Nvidia are supplying rpms, selinux
isn't going to be able to tell the difference.
The goal here is not to prevent Nvidia-supplied rpms to run on Linux.
The goal is to prevent shell-based installers from modifying files that
are "controlled" by the rpm database.
Nvidia rpms would not create a problem on Fedora, since any conflicts
with other rpms would be exposed by the package manager.
Another issue is that files only have one tag for selinux and if you use
a tag that indicates just that it was installed by rpm, that isn't going to
play nice with other selinux policies. You might be able to get away with
restricting how files with a number of different types are updated. You
may cover some files you don't want doing this, but I think you could get
close.
I think this is the correct way to do it. I don't follow why you
couldn't get close...
You'd enumerate all the contexts for files under /lib, /usr/lib, etc..
places which would be declared "controlled" by rpm.
Then you create a new attribute called "managed" or something like that,
and mark all those types with that attribute.
Then you write policy to allow rpm to manage those types. You write an
assertion to make sure nothing but rpm manages those files. Then audit
and remove all rules from policy that violate that assertion. I haven't
written policy in a while, but shouldn't this work?
Another approach would be to have rpm not allow rpms to stomp on files
from other rpms if they weren't signed by the same key (perhaps --force
would override that).
That solves a completely different problem from the original question.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
