Bug 140576 - gnome-netstatus-applet vs proc_net_t
Summary: gnome-netstatus-applet vs proc_net_t
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-23 18:15 UTC by Ivan Gyurdiev
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-11-30 22:24:37 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ivan Gyurdiev 2004-11-23 18:15:19 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041114 Firefox/1.0

Description of problem:

audit(1101233895.299:11929079): avc:  denied  { search } for  pid=4907
exe=/usr/libexec/gnome-netstatus-applet name=net dev=proc
ino=-268435434 scontext=user_u:system_r:unconfined_t
tcontext=system_u:object_r:proc_net_t tclass=dir
audit(1101233895.299:11929079): syscall=5 exit=4294967283 a0=8054d79
a1=0 a2=1b6 a3=0 items=1 pid=4907 loginuid=-1 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500
audit(1101233895.299:11929079): item=0 name=/proc/net/dev

audit(1101233895.299:11929080): avc:  denied  { search } for  pid=4907
exe=/usr/libexec/gnome-netstatus-applet name=net dev=proc
ino=-268435434 scontext=user_u:system_r:unconfined_t
tcontext=system_u:object_r:proc_net_t tclass=dir
audit(1101233895.299:11929080): syscall=5 exit=4294967283 a0=8054e08
a1=0 a2=1b6 a3=0 items=1 pid=4907 loginuid=-1 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500
audit(1101233895.299:11929080): item=0 name=/proc/net/wireless


Version-Release number of selected component (if applicable):
selinux-policy-targeted-1.19.4-3

How reproducible:
Always

Steps to Reproduce:
See summary.  

Additional info:

Comment 1 Daniel Walsh 2004-11-23 20:07:18 UTC
Fixed in selinux-policy-targeted-1.19.4-4

Dan

Comment 2 Ivan Gyurdiev 2004-11-24 23:44:59 UTC
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.

Comment 3 Daniel Walsh 2004-11-26 11:49:27 UTC
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?

Comment 4 Ivan Gyurdiev 2004-11-26 16:19:33 UTC
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 

Comment 5 Ivan Gyurdiev 2004-11-26 16:21:29 UTC
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.


Comment 6 Daniel Walsh 2004-11-29 13:52:10 UTC
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

Comment 7 Ivan Gyurdiev 2004-11-29 14:31:09 UTC
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.

Comment 8 Daniel Walsh 2004-11-29 15:39:59 UTC
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


Comment 9 Ivan Gyurdiev 2004-11-29 16:00:59 UTC
"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.


Comment 10 Ivan Gyurdiev 2004-11-30 22:24:37 UTC
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. 



Comment 11 Daniel Walsh 2004-12-01 00:49:44 UTC
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

Comment 12 Ivan Gyurdiev 2004-12-01 02:23:56 UTC
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. 



Note You need to log in before you can comment on or make changes to this bug.