Hi all,
I was wondering how rpm works with Selinux, say I downloaded a third-party rpm package and installed it with rpm -i. Will rpm label the newly installed file properly or I have to relabel filesystem or do 'restorecon' manually ?
Any webpages I could read on this problem? Thanks a lot.
James
On Tue, 2005-05-31 at 14:50 -0400, James Z. Li wrote:
Hi all,
I was wondering how rpm works with Selinux, say I downloaded a third-party rpm package and installed it with rpm -i. Will rpm label the newly installed file properly or I have to relabel filesystem or do 'restorecon' manually ?
rpm will label the files according to their context as specified in the policy. Additionally, if a third party program is installed using the "install" command, that will also restorecon files automatically.
However, if you're installing third party programs, and they have no policy written for them, they might not work properly if they require elevated privileges.
On Tue, 2005-05-31 at 14:50 -0400, James Z. Li wrote:
Hi all,
I was wondering how rpm works with Selinux, say I downloaded a third-party rpm package and installed it with rpm -i. Will rpm label the newly installed file properly or I have to relabel filesystem or do 'restorecon' manually ?
Any webpages I could read on this problem? Thanks a lot.
rpm has been modified to set the security context on newly installed files in accordance with the policy (based on the file_contexts configuration). It originally incorporated a copy of the setfiles logic for this purpose, and has recently been changed in FC4/devel to use matchpathcon(3) instead, IIUC.
On Tue, 31 May 2005 15:11:30 -0400, Stephen Smalley wrote:
rpm has been modified to set the security context on newly installed files in accordance with the policy (based on the file_contexts configuration).
I thought RPMs could contain their own file contexts for each contained file, rather than relying on external regular expressions. Is this not the case? Was it ever the case? :)
On 5/31/05, Mike Hearn mike@navi.cx wrote:
On Tue, 31 May 2005 15:11:30 -0400, Stephen Smalley wrote:
rpm has been modified to set the security context on newly installed files in accordance with the policy (based on the file_contexts configuration).
I thought RPMs could contain their own file contexts for each contained file, rather than relying on external regular expressions. Is this not the case? Was it ever the case? :)
I am also interested in this. Is it possible to have some kind of checklist of file_context for each rpm package so that rpm will label each contained file according to the checklist.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Wed, Jun 01, 2005 at 12:53:46AM +0100, Mike Hearn wrote:
I thought RPMs could contain their own file contexts for each contained file, rather than relying on external regular expressions. Is this not the case? Was it ever the case? :)
No matter how tempting, that also sounds like a perfect way for a rogue package to subvert the whole SELinux scheme, overriding the preinstalled policy, right?
On Wed, 2005-06-01 at 04:01 +0200, Rudi Chiarito wrote:
No matter how tempting, that also sounds like a perfect way for a rogue package to subvert the whole SELinux scheme, overriding the preinstalled policy, right?
Actually, I think all a rogue package has to do to subvert the SELinux scheme is to install itself where the regexps expect, and it will get labeled as a privileged process.
It's certainly possible to restrict rpm on a SELinux system. I believe the current policy prevents it from writing to /etc/shadow, unless a tunable is on.
On the other hand I am suspicious whether this protection works at all - it probably allows the rpm to install an executable over an auth_write binary, at which point it can just install a hostile executable there, and the battle is lost.
I could be wrong though - I hadn't looked at the rpm policy until now...
On Tue, 2005-05-31 at 22:20 -0400, Ivan Gyurdiev wrote:
On Wed, 2005-06-01 at 04:01 +0200, Rudi Chiarito wrote:
No matter how tempting, that also sounds like a perfect way for a rogue package to subvert the whole SELinux scheme, overriding the preinstalled policy, right?
Actually, I think all a rogue package has to do to subvert the SELinux scheme is to install itself where the regexps expect, and it will get labeled as a privileged process.
It's certainly possible to restrict rpm on a SELinux system. I believe the current policy prevents it from writing to /etc/shadow, unless a tunable is on.
On the other hand I am suspicious whether this protection works at all - it probably allows the rpm to install an executable over an auth_write binary, at which point it can just install a hostile executable there, and the battle is lost.
I could be wrong though - I hadn't looked at the rpm policy until now...
...but that's why we import gpg keys and do rpm verification, right?
On Tue, 2005-05-31 at 22:20 -0400, Ivan Gyurdiev wrote:
Actually, I think all a rogue package has to do to subvert the SELinux scheme is to install itself where the regexps expect, and it will get labeled as a privileged process.
It's certainly possible to restrict rpm on a SELinux system. I believe the current policy prevents it from writing to /etc/shadow, unless a tunable is on.
On the other hand I am suspicious whether this protection works at all - it probably allows the rpm to install an executable over an auth_write binary, at which point it can just install a hostile executable there, and the battle is lost.
I could be wrong though - I hadn't looked at the rpm policy until now...
Yes, rpm is effectively unrestricted at present.
On Wed, 2005-06-01 at 04:01 +0200, Rudi Chiarito wrote:
No matter how tempting, that also sounds like a perfect way for a rogue package to subvert the whole SELinux scheme, overriding the preinstalled policy, right?
rpm is trusted at present in Fedora. There have been discussions of limiting it, e.g. having it transition to different domains and using different file contexts depending on some measure of the "trustworthiness" of the package, but no progress there yet. You just have the traditional signature verification support at present.
On Wed, 2005-06-01 at 00:53 +0100, Mike Hearn wrote:
On Tue, 31 May 2005 15:11:30 -0400, Stephen Smalley wrote:
rpm has been modified to set the security context on newly installed files in accordance with the policy (based on the file_contexts configuration).
I thought RPMs could contain their own file contexts for each contained file, rather than relying on external regular expressions. Is this not the case? Was it ever the case? :)
That was the original approach during FC2 development, but was later dropped. With multiple policies (strict, targeted, mls, ...), including potential customization by end users, it became problematic.
On Wed, 01 Jun 2005 07:31:10 -0400, Stephen Smalley wrote:
That was the original approach during FC2 development, but was later dropped. With multiple policies (strict, targeted, mls, ...), including potential customization by end users, it became problematic.
Oh, OK. When binary policy modules appear maybe it would be useful to do it again so third party RPMs can be a part of the SELinux world.
At the moment the focus seems to be on totally centralised policy for everything the user might want to run (or be secured) ... I can't see this scaling as SELinux enters the mainstream.
thanks -mike
On Wed, 01 Jun 2005 23:29:59 BST, Mike Hearn said:
At the moment the focus seems to be on totally centralised policy for everything the user might want to run (or be secured) ... I can't see this scaling as SELinux enters the mainstream.
Well, technically, if it isn't centralized, you don't have a prayer of any *real* enforcement. There's days when I think that Casey is right, and even the *current* strict scheme isn't centralized and top-down design enough.
The average user can't write policy, and can't evaluate policy - and neither can the average developer. Quite frankly, most of the time I'm ecstatic if I can get a user or developer to state a coherent and realistic threat model. As a result, it will be a *long* time before we can realistically support any model other than telling developers to ask for help on the mailing list. Hopefully with the binary-policy stuff, at least the "how to deploy the pieces" part will become easier.
There's additional good security reasons for the current model - the centralized policy is driven out of a centralized development tree, and the current open review structure both ensures double-checks and honesty among all concerned. It's hopefully pretty hard to sneak a backdoor (intentional or accidental) in when Dan Walsh, Russell Coker, and Stephen Smalley are all cross-checking each other - and everybody and their pet llama are sniping from the sidelines on this list :) On the other hand, there's no particular reason for anybody to trust a policy shipped with MobyFrobozz 0.9.4 if it hasn't been vetted by somebody.
(Aside to the RedHat/Fedora developers - I *like* the description Chris PeBenito gave of how Gentoo is packaging it - he gave the example of 'ntp' having a pre-req of 'selinux-ntp'. Having the "owners" of the two packages be different people would address most of the issues this sort of thing causes....)
And quite frankly, we're not 100% of the way to understanding how to even do a totally centralized policy - trying to expand out to other stuff might be foolhardy.
On Thu, 02 Jun 2005 01:29:00 -0400, Valdis.Kletnieks wrote:
Well, technically, if it isn't centralized, you don't have a prayer of any *real* enforcement. There's days when I think that Casey is right, and even the *current* strict scheme isn't centralized and top-down design enough.
I see your point, and I see the points about centralised analysis. That said, you seem to be saying you prefer an all or nothing situation. Maybe I'm wrong but I think a partly locked down program is still better than one running in unconfined_t right? Even if the policy was written by a non-expert.
At some point if policy isn't actually pushed upstream you'll hit the limits on the size of the policy you guys can maintain without constant tweaks to fix updates sucking up more time than adding new policy. Or worse, the policy will bit rot over time as apps start requiring new privileges in edge cases that aren't tested and so SELinux will cause more and more "bugs", and people will start switching it off.
thanks -mike
James Z. Li wrote:
Hi all,
I was wondering how rpm works with Selinux, say I downloaded a third-party rpm package and installed it with rpm -i. Will rpm label the newly installed file properly or I have to relabel filesystem or do 'restorecon' manually ?
Any webpages I could read on this problem? Thanks a lot.
James
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
It will label the file according the the file_context file installed on the machine. This may or may not be "correctly". Usually this is only a problem if the app is installed in a non standard directory.
Dan
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Ivan Gyurdiev -
Ivan Gyurdiev -
James Z. Li -
Mike Hearn -
Rudi Chiarito -
Stephen Smalley -
Valdis.Kletnieks＠vt.edu