Bug 140576
Summary: | gnome-netstatus-applet vs proc_net_t | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ivan Gyurdiev <ivg231> |
Component: | selinux-policy-targeted | Assignee: | Daniel Walsh <dwalsh> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-11-30 22:24:37 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Ivan Gyurdiev
2004-11-23 18:15:19 UTC
Fixed in selinux-policy-targeted-1.19.4-4 Dan I'll close this bug once my mirror of choice syncs. Hey - I thought the targeted policy was all about important system daemons. What's up with this? -rwxr-xr-x root root system_u:object_r:ldconfig_exec_t /sbin/ldconfig How is this consistent with what the targeted policy's goal is? Now my Nvidia installer breaks every time because the libs have the wrong context - not cool. ldconfig_exec_t is needed to keep the /etc/ld.so.cache file in the right context so the protected daemons do not need extra privs. In certain situations, daemons need more access to /etc/ld.so.cache then they need to etc_t, so we added this to maintain that context. What problems are you seeing in ldconfig? The latest policy should allow it to unlink etc_t, which was the only problem I ever saw in badly labeled systems? audit(1101484099.052:0): avc: denied { write } for pid=17032 exe=/sbin/ldconfig path=/var/log/nvidia-installer.log dev=dm-0 ino=1168503 scontext=root:system_r:ldconfig_t tcontext=system_u:object_r:var_log_t tclass=file audit(1101484099.053:0): avc: denied { read } for pid=17032 exe=/sbin/ldconfig path=/proc/version dev=proc ino=-268435453 scontext=root:system_r:ldconfig_t tcontext=system_u:object_r:proc_t tclass=file audit(1101484099.943:0): avc: denied { read } for pid=17032 exe=/sbin/ldconfig name=libXvMCNVIDIA.so.1.0.6629 dev=dm-0 ino=1025927 scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file audit(1101484100.084:0): avc: denied { getattr } for pid=17032 exe=/sbin/ldconfig path=/usr/X11R6/lib/libXvMCNVIDIA.so.1.0.6629 dev=dm-0 ino=1025927 scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file audit(1101484104.088:0): avc: denied { getattr } for pid=17032 exe=/sbin/ldconfig path=/usr/lib/libnvidia-tls.so.1.0.6629 dev=dm-0 ino=1025876 scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file audit(1101484106.107:0): avc: denied { read } for pid=17032 exe=/sbin/ldconfig name=libGLcore.so.1.0.6629 dev=dm-0 ino=1025470 scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file audit(1101484108.736:0): avc: denied { getattr } for pid=17032 exe=/sbin/ldconfig path=/usr/lib/libGL.so.1.0.6629 dev=dm-0 ino=1023517 scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file audit(1101484110.275:0): avc: denied { read } for pid=17032 exe=/sbin/ldconfig name=libnvidia-tls.so.1.0.6629 dev=dm-0 ino=1025876 scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file audit(1101484110.867:0): avc: denied { read } for pid=17032 exe=/sbin/ldconfig name=libGL.so.1.0.6629 dev=dm-0 ino=1023517 scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file audit(1101484111.444:0): avc: denied { getattr } for pid=17032 exe=/sbin/ldconfig path=/usr/lib/libGLcore.so.1.0.6629 dev=dm-0 ino=1025470 scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file audit(1101484111.783:0): avc: denied { getattr } for pid=17032 exe=/sbin/ldconfig path=/usr/lib/tls/libnvidia-tls.so.1.0.6629 dev=dm-0 ino=1025884 scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file audit(1101484111.783:0): avc: denied { read } for pid=17032 exe=/sbin/ldconfig name=libnvidia-tls.so.1.0.6629 dev=dm-0 ino=1025884 scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file In other words, I need to restorecon or Nvidia does not work. I thought the target policy was designed to address the 3rd party problem. I can add allow ldconfig_t proc_t:file read; libnvidia-tls.so.1.0.6629 should be shlib_t, it is mislabeled. Why is ldconfig trying to write to /var/log/nvidia-installer.log Why do I have to deal with this in the first place - I don't want the targeted policy affecting my Nvidia drivers. What happens when I download random app X that wants to install libraries in /lib, or /usr/lib, or /usr/local/lib - it doesn't matter where, they're all owned by lib_t by default, not shlib_t. As far as the log file, seems something like this: [root@cobra ~]# ldconfig > /var/log/log2 would do it. If the random apps are installed via rpm, they should be labeled correctly, if they are installed via make install, then you will need to relabel the shared libraries, This is one of the requirements of SELinux. I know that ldconfig > /var/log/log2 will cause the problem, but I just do not want to allow ldconfig to write anywhere. BTW a hack to get around this would be ldconfig | cat > /var/log/log2. I can add the ability for ldconfig to write to /var/log for targeted policy if this is a common case. Dan "If the random apps are installed via rpm, they should be labeled correctly, if they are installed via make install, then you will need to relabel the shared libraries, This is one of the requirements of SELinux." When I asked whether SELinux was supposed to be transparent for the end user, I was told the answer is no, and that I need to use the targeted policy. Now I am using the targeted policy, and it's STILL breaking third party apps. I guess I've misunderstood what the targeted policy was about - it was my impression that it would not break compatibility with other applications. Closing bug... It seems to me that when SElinux targeted affects random third party apps in addition to the few daemons it's supposed to be guarding, this is a cause for concern. I see you disagree. I'm just curious what will happen once all those Nvidia users try to update their kernel and have to reinstall their driver from shellscript. No I agree that this is a problem, and am thinking that the install command might need some SELinux changes to make it work better. If install had the "restorecon" built into it, do you think this would help this problem? Dan You could make it so that the default context (if none is provided, and without the -P option) is determined by restorecon. However that changes the default behavior from parent dir. inheritance, and I'm not sure if that's a good idea - seems like a significant change. |