Attention: Proprietary video driver users (ATI, Nvidia, etc.)

[Ivan Gyurdiev]

>>>> 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.