selinux prelink avc's

[dragoran]

audit(1147793154.831:353): avc:  denied  { execute_no_trans } for  
pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 
scontext=system_u:system_r:prelink_t:s0 
tcontext=system_u:object_r:lib_t:s0 tclass=file
audit(1147793154.831:354): avc:  denied  { execute_no_trans } for  
pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 
scontext=system_u:system_r:prelink_t:s0 
tcontext=system_u:object_r:lib_t:s0 tclass=file
audit(1147793155.019:355): avc:  denied  { execute_no_trans } for  
pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 
scontext=system_u:system_r:prelink_t:s0 
tcontext=system_u:object_r:lib_t:s0 tclass=file
audit(1147793155.447:356): avc:  denied  { execute_no_trans } for  
pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 
scontext=system_u:system_r:prelink_t:s0 
tcontext=system_u:object_r:lib_t:s0 tclass=file
audit(1147793156.255:357): avc:  denied  { execute_no_trans } for  
pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 
scontext=system_u:system_r:prelink_t:s0 
tcontext=system_u:object_r:lib_t:s0 tclass=file
I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5
whats gonig on? is a file misslabeled or is this a policy bug?

[dragoran]

dragoran wrote:
>  audit(1147793154.831:353): avc:  denied  { execute_no_trans } for  
>  pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 
>  scontext=system_u:system_r:prelink_t:s0 
>  tcontext=system_u:object_r:lib_t:s0 tclass=file
>  audit(1147793154.831:354): avc:  denied  { execute_no_trans } for  
>  pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 
>  scontext=system_u:system_r:prelink_t:s0 
>  tcontext=system_u:object_r:lib_t:s0 tclass=file
>  audit(1147793155.019:355): avc:  denied  { execute_no_trans } for  
>  pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 
>  scontext=system_u:system_r:prelink_t:s0 
>  tcontext=system_u:object_r:lib_t:s0 tclass=file
>  audit(1147793155.447:356): avc:  denied  { execute_no_trans } for  
>  pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 
>  scontext=system_u:system_r:prelink_t:s0 
>  tcontext=system_u:object_r:lib_t:s0 tclass=file
>  audit(1147793156.255:357): avc:  denied  { execute_no_trans } for  
>  pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 
>  scontext=system_u:system_r:prelink_t:s0 
>  tcontext=system_u:object_r:lib_t:s0 tclass=file
>  I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5
>  whats gonig on? is a file misslabeled or is this a policy bug?
>
>  -- 
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
>  
hello?
any solution for this problem?

[dragoran]

dragoran wrote:
>  dragoran wrote:
> > audit(1147793154.831:353): avc:  denied  { execute_no_trans } for  
> > pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 
> > scontext=system_u:system_r:prelink_t:s0 
> > tcontext=system_u:object_r:lib_t:s0 tclass=file
> > audit(1147793154.831:354): avc:  denied  { execute_no_trans } for  
> > pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 
> > scontext=system_u:system_r:prelink_t:s0 
> > tcontext=system_u:object_r:lib_t:s0 tclass=file
> > audit(1147793155.019:355): avc:  denied  { execute_no_trans } for  
> > pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 
> > scontext=system_u:system_r:prelink_t:s0 
> > tcontext=system_u:object_r:lib_t:s0 tclass=file
> > audit(1147793155.447:356): avc:  denied  { execute_no_trans } for  
> > pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 
> > scontext=system_u:system_r:prelink_t:s0 
> > tcontext=system_u:object_r:lib_t:s0 tclass=file
> > audit(1147793156.255:357): avc:  denied  { execute_no_trans } for  
> > pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163 
> > scontext=system_u:system_r:prelink_t:s0 
> > tcontext=system_u:object_r:lib_t:s0 tclass=file
> > I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5
> > whats gonig on? is a file misslabeled or is this a policy bug?
> >
> > -- 
> > fedora-selinux-list mailing list
> > fedora-selinux-list(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >
> >
>  hello?
>  any solution for this problem?
>
>  
it happend again...
am I the only  one seeing this?
audit(1148393411.538:2907): avc:  denied  { execute_no_trans } for  
pid=16856 comm="prelink" name="ld-2.4.so" dev=md0 ino=8060939 
scontext=system_u:system_r:prelink_t:s0 
tcontext=system_u:object_r:lib_t:s0 tclass=file
audit(1148393411.794:2908): avc:  denied  { execmod } for  pid=16859 
comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" dev=md0 ino=29797475

scontext=system_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 
tclass=file
audit(1148393411.814:2909): avc:  denied  { execmod } for  pid=16860 
comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.8762" dev=md0 
ino=30869146 scontext=system_u:system_r:prelink_t:s0 
tcontext=root:object_r:lib_t:s0 tclass=file
audit(1148393412.438:2910): avc:  denied  { unlink } for  pid=13702 
comm="prelink" name="prelink.cache" dev=md0 ino=7012828 
scontext=system_u:system_r:prelink_t:s0 
tcontext=user_u:object_r:etc_t:s0 tclass=file
prelink seems to be completly broken and nobody seems to notice it?

[Paul Howarth]

On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote:
>  dragoran wrote:
>  > dragoran wrote:
>  >> audit(1147793154.831:353): avc:  denied  { execute_no_trans } for  
>  >> pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163
>
>  >> scontext=system_u:system_r:prelink_t:s0 
>  >> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  >> audit(1147793154.831:354): avc:  denied  { execute_no_trans } for  
>  >> pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163
>
>  >> scontext=system_u:system_r:prelink_t:s0 
>  >> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  >> audit(1147793155.019:355): avc:  denied  { execute_no_trans } for  
>  >> pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163
>
>  >> scontext=system_u:system_r:prelink_t:s0 
>  >> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  >> audit(1147793155.447:356): avc:  denied  { execute_no_trans } for  
>  >> pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163
>
>  >> scontext=system_u:system_r:prelink_t:s0 
>  >> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  >> audit(1147793156.255:357): avc:  denied  { execute_no_trans } for  
>  >> pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163
>
>  >> scontext=system_u:system_r:prelink_t:s0 
>  >> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  >> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5
>  >> whats gonig on? is a file misslabeled or is this a policy bug?
>  >>
>  >> -- 
>  >> fedora-selinux-list mailing list
>  >> fedora-selinux-list(a)redhat.com
>  >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  >>
>  >>
>  > hello?
>  > any solution for this problem?
>  >
>  >
>  
>  it happend again...
>  am I the only  one seeing this?
>  audit(1148393411.538:2907): avc:  denied  { execute_no_trans } for  
>  pid=16856 comm="prelink" name="ld-2.4.so" dev=md0 ino=8060939 
>  scontext=system_u:system_r:prelink_t:s0 
>  tcontext=system_u:object_r:lib_t:s0 tclass=file
>  audit(1148393411.794:2908): avc:  denied  { execmod } for  pid=16859 
>  comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" dev=md0
> ino=29797475 
>  scontext=system_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 
>  tclass=file
>  audit(1148393411.814:2909): avc:  denied  { execmod } for  pid=16860 
>  comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.8762" dev=md0 
>  ino=30869146 scontext=system_u:system_r:prelink_t:s0 
>  tcontext=root:object_r:lib_t:s0 tclass=file
>  audit(1148393412.438:2910): avc:  denied  { unlink } for  pid=13702 
>  comm="prelink" name="prelink.cache" dev=md0 ino=7012828 
>  scontext=system_u:system_r:prelink_t:s0 
>  tcontext=user_u:object_r:etc_t:s0 tclass=file
>  prelink seems to be completly broken and nobody seems to notice it? 
I'm not seeing this anywhere.

Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t on your
system?

Paul.

[dragoran]

Paul Howarth wrote:
>  On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote:
>    
> > dragoran wrote:
> >     
> >> dragoran wrote:
> >>       
> >>> audit(1147793154.831:353): avc:  denied  { execute_no_trans } for  
> >>> pid=5195 comm="prelink" name="ld-2.4.so" dev=md0
> ino=8061163 
> >>> scontext=system_u:system_r:prelink_t:s0 
> >>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>> audit(1147793154.831:354): avc:  denied  { execute_no_trans } for  
> >>> pid=5196 comm="prelink" name="ld-2.4.so" dev=md0
> ino=8061163 
> >>> scontext=system_u:system_r:prelink_t:s0 
> >>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>> audit(1147793155.019:355): avc:  denied  { execute_no_trans } for  
> >>> pid=5197 comm="prelink" name="ld-2.4.so" dev=md0
> ino=8061163 
> >>> scontext=system_u:system_r:prelink_t:s0 
> >>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>> audit(1147793155.447:356): avc:  denied  { execute_no_trans } for  
> >>> pid=5198 comm="prelink" name="ld-2.4.so" dev=md0
> ino=8061163 
> >>> scontext=system_u:system_r:prelink_t:s0 
> >>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>> audit(1147793156.255:357): avc:  denied  { execute_no_trans } for  
> >>> pid=5199 comm="prelink" name="ld-2.4.so" dev=md0
> ino=8061163 
> >>> scontext=system_u:system_r:prelink_t:s0 
> >>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5
> >>> whats gonig on? is a file misslabeled or is this a policy bug?
> >>>
> >>> -- 
> >>> fedora-selinux-list mailing list
> >>> fedora-selinux-list(a)redhat.com
> >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >>>
> >>>
> >>>         
> >> hello?
> >> any solution for this problem?
> >>
> >>
> >>       
> > it happend again...
> > am I the only  one seeing this?
> > audit(1148393411.538:2907): avc:  denied  { execute_no_trans } for  
> > pid=16856 comm="prelink" name="ld-2.4.so" dev=md0 ino=8060939 
> > scontext=system_u:system_r:prelink_t:s0 
> > tcontext=system_u:object_r:lib_t:s0 tclass=file
> > audit(1148393411.794:2908): avc:  denied  { execmod } for  pid=16859 
> > comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" dev=md0
> ino=29797475 
> > scontext=system_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 
> > tclass=file
> > audit(1148393411.814:2909): avc:  denied  { execmod } for  pid=16860 
> > comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.8762" dev=md0 
> > ino=30869146 scontext=system_u:system_r:prelink_t:s0 
> > tcontext=root:object_r:lib_t:s0 tclass=file
> > audit(1148393412.438:2910): avc:  denied  { unlink } for  pid=13702 
> > comm="prelink" name="prelink.cache" dev=md0 ino=7012828 
> > scontext=system_u:system_r:prelink_t:s0 
> > tcontext=user_u:object_r:etc_t:s0 tclass=file
> > prelink seems to be completly broken and nobody seems to notice it?
> >     
>
>  I'm not seeing this anywhere.
>
>  Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t on your
>  system?
>
>  Paul.
>
>
>
>     
ls -Z /lib/ld-2.4.so
-rwxr-xr-x  root     root     system_u:object_r:ld_so_t        
/lib/ld-2.4.so
ls -Z /lib64/ld-2.4.so
-rwxr-xr-x  root     root     system_u:object_r:lib_t
seems that you are correct lets hope that this wont happen again.

[dragoran]

dragoran wrote:
>  Paul Howarth wrote:
> > On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote:
> >  
> >> dragoran wrote:
> >>    
> >>> dragoran wrote:
> >>>      
> >>>> audit(1147793154.831:353): avc:  denied  { execute_no_trans } for  
> >>>> pid=5195 comm="prelink" name="ld-2.4.so" dev=md0
> ino=8061163 
> >>>> scontext=system_u:system_r:prelink_t:s0 
> >>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>> audit(1147793154.831:354): avc:  denied  { execute_no_trans } for  
> >>>> pid=5196 comm="prelink" name="ld-2.4.so" dev=md0
> ino=8061163 
> >>>> scontext=system_u:system_r:prelink_t:s0 
> >>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>> audit(1147793155.019:355): avc:  denied  { execute_no_trans } for  
> >>>> pid=5197 comm="prelink" name="ld-2.4.so" dev=md0
> ino=8061163 
> >>>> scontext=system_u:system_r:prelink_t:s0 
> >>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>> audit(1147793155.447:356): avc:  denied  { execute_no_trans } for  
> >>>> pid=5198 comm="prelink" name="ld-2.4.so" dev=md0
> ino=8061163 
> >>>> scontext=system_u:system_r:prelink_t:s0 
> >>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>> audit(1147793156.255:357): avc:  denied  { execute_no_trans } for  
> >>>> pid=5199 comm="prelink" name="ld-2.4.so" dev=md0
> ino=8061163 
> >>>> scontext=system_u:system_r:prelink_t:s0 
> >>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5
> >>>> whats gonig on? is a file misslabeled or is this a policy bug?
> >>>>
> >>>> -- 
> >>>> fedora-selinux-list mailing list
> >>>> fedora-selinux-list(a)redhat.com
> >>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >>>>
> >>>>
> >>>>         
> >>> hello?
> >>> any solution for this problem?
> >>>
> >>>
> >>>       
> >> it happend again...
> >> am I the only  one seeing this?
> >> audit(1148393411.538:2907): avc:  denied  { execute_no_trans } for  
> >> pid=16856 comm="prelink" name="ld-2.4.so" dev=md0 ino=8060939
>
> >> scontext=system_u:system_r:prelink_t:s0 
> >> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >> audit(1148393411.794:2908): avc:  denied  { execmod } for  pid=16859 
> >> comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" dev=md0 
> >> ino=29797475 scontext=system_u:system_r:prelink_t:s0 
> >> tcontext=root:object_r:lib_t:s0 tclass=file
> >> audit(1148393411.814:2909): avc:  denied  { execmod } for  pid=16860 
> >> comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.8762" dev=md0
>
> >> ino=30869146 scontext=system_u:system_r:prelink_t:s0 
> >> tcontext=root:object_r:lib_t:s0 tclass=file
> >> audit(1148393412.438:2910): avc:  denied  { unlink } for  pid=13702 
> >> comm="prelink" name="prelink.cache" dev=md0 ino=7012828 
> >> scontext=system_u:system_r:prelink_t:s0 
> >> tcontext=user_u:object_r:etc_t:s0 tclass=file
> >> prelink seems to be completly broken and nobody seems to notice it?
> >>     
> >
> > I'm not seeing this anywhere.
> >
> > Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t on your
> > system?
> >
> > Paul.
> >
> >
> >
> >   
>  ls -Z /lib/ld-2.4.so
>  -rwxr-xr-x  root     root     system_u:object_r:ld_so_t        
>  /lib/ld-2.4.so
>  ls -Z /lib64/ld-2.4.so
>  -rwxr-xr-x  root     root     system_u:object_r:lib_t
>  seems that you are correct lets hope that this wont happen again.
>
>  -- 
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
>  
this *is* a bug
restorecon /lib64/ld-2.4.so
does not change it to ld_so_t (had to do a chcon)

selinux prelink avc's (broken paths in policy?)

[dragoran]

dragoran wrote:
>  dragoran wrote:
> > Paul Howarth wrote:
> >> On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote:
> >>  
> >>> dragoran wrote:
> >>>   
> >>>> dragoran wrote:
> >>>>     
> >>>>> audit(1147793154.831:353): avc:  denied  { execute_no_trans } 
> >>>>> for  pid=5195 comm="prelink" name="ld-2.4.so"
> dev=md0 ino=8061163 
> >>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>> audit(1147793154.831:354): avc:  denied  { execute_no_trans } 
> >>>>> for  pid=5196 comm="prelink" name="ld-2.4.so"
> dev=md0 ino=8061163 
> >>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>> audit(1147793155.019:355): avc:  denied  { execute_no_trans } 
> >>>>> for  pid=5197 comm="prelink" name="ld-2.4.so"
> dev=md0 ino=8061163 
> >>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>> audit(1147793155.447:356): avc:  denied  { execute_no_trans } 
> >>>>> for  pid=5198 comm="prelink" name="ld-2.4.so"
> dev=md0 ino=8061163 
> >>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>> audit(1147793156.255:357): avc:  denied  { execute_no_trans } 
> >>>>> for  pid=5199 comm="prelink" name="ld-2.4.so"
> dev=md0 ino=8061163 
> >>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5
> >>>>> whats gonig on? is a file misslabeled or is this a policy bug?
> >>>>>
> >>>>> -- 
> >>>>> fedora-selinux-list mailing list
> >>>>> fedora-selinux-list(a)redhat.com
> >>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >>>>>
> >>>>>
> >>>>>         
> >>>> hello?
> >>>> any solution for this problem?
> >>>>
> >>>>
> >>>>       
> >>> it happend again...
> >>> am I the only  one seeing this?
> >>> audit(1148393411.538:2907): avc:  denied  { execute_no_trans } for  
> >>> pid=16856 comm="prelink" name="ld-2.4.so" dev=md0
> ino=8060939 
> >>> scontext=system_u:system_r:prelink_t:s0 
> >>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>> audit(1148393411.794:2908): avc:  denied  { execmod } for  
> >>> pid=16859 comm="ld-linux.so.2"
> name="libGLcore.so.1.0.8762" dev=md0 
> >>> ino=29797475 scontext=system_u:system_r:prelink_t:s0 
> >>> tcontext=root:object_r:lib_t:s0 tclass=file
> >>> audit(1148393411.814:2909): avc:  denied  { execmod } for  
> >>> pid=16860 comm="ld-linux.so.2"
> name="libnvidia-tls.so.1.0.8762" 
> >>> dev=md0 ino=30869146 scontext=system_u:system_r:prelink_t:s0 
> >>> tcontext=root:object_r:lib_t:s0 tclass=file
> >>> audit(1148393412.438:2910): avc:  denied  { unlink } for  pid=13702 
> >>> comm="prelink" name="prelink.cache" dev=md0 ino=7012828 
> >>> scontext=system_u:system_r:prelink_t:s0 
> >>> tcontext=user_u:object_r:etc_t:s0 tclass=file
> >>> prelink seems to be completly broken and nobody seems to notice it?
> >>>     
> >>
> >> I'm not seeing this anywhere.
> >>
> >> Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t on 
> >> your
> >> system?
> >>
> >> Paul.
> >>
> >>
> >>
> >>   
> > ls -Z /lib/ld-2.4.so
> > -rwxr-xr-x  root     root     system_u:object_r:ld_so_t        
> > /lib/ld-2.4.so
> > ls -Z /lib64/ld-2.4.so
> > -rwxr-xr-x  root     root     system_u:object_r:lib_t
> > seems that you are correct lets hope that this wont happen again.
> >
> > -- 
> > fedora-selinux-list mailing list
> > fedora-selinux-list(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >
> >
>  this *is* a bug
>  restorecon /lib64/ld-2.4.so
>  does not change it to ld_so_t (had to do a chcon)
>
>
>  
I did a complete relabel and the result is
ls -Z /lib64/ld-2.4.so
-rwxr-xr-x  root     root     system_u:object_r:lib_t          
/lib64/ld-2.4.so
I also noticed this:
drwxr-xr-x  root     root     system_u:object_r:bin_t          bin
drwxr-xr-x  root     root     system_u:object_r:boot_t         boot
drwxr-xr-x  root     root     system_u:object_r:device_t       dev
drwxr-xr-x  root     root     system_u:object_r:etc_t          etc
drwxr-xr-x  root     root     system_u:object_r:home_root_t    home
drwxr-xr-x  root     root     system_u:object_r:lib_t          lib
drwxr-xr-x  root     root     system_u:object_r:lib_t          lib64
drwx------  root     root     system_u:object_r:lost_found_t   lost+found
drwxr-xr-x  root     root     system_u:object_r:mnt_t          media
drwxr-xr-x  root     root     system_u:object_r:mnt_t          misc
drwxr-xr-x  root     root     system_u:object_r:mnt_t          mnt
dr-xr-xr-x  root     root     system_u:object_r:mnt_t          net
drwxr-xr-x  root     root     system_u:object_r:usr_t          opt
dr-xr-xr-x  root     root     system_u:object_r:proc_t         proc
drwxr-x---  root     root     root:object_r:user_home_dir_t    root
drwxr-xr-x  root     root     system_u:object_r:sbin_t         sbin
drwxr-xr-x  root     root     system_u:object_r:security_t     selinux
drwxr-xr-x  root     root     system_u:object_r:var_t          srv
drwxr-xr-x  root     root     system_u:object_r:sysfs_t        sys
drwxrwxrwt  root     root     system_u:object_r:tmp_t          tmp
drwxr-xr-x  root     root     system_u:object_r:usr_t          usr
drwxr-xr-x  root     root     system_u:object_r:var_t          var
looks incorrect too whats going on here?

selinux prelink avc's (broken paths in policy?)

[dragoran]

dragoran wrote:
>  dragoran wrote:
> > dragoran wrote:
> >> Paul Howarth wrote:
> >>> On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote:
> >>>  
> >>>> dragoran wrote:
> >>>>  
> >>>>> dragoran wrote:
> >>>>>    
> >>>>>> audit(1147793154.831:353): avc:  denied  { execute_no_trans } 
> >>>>>> for  pid=5195 comm="prelink" name="ld-2.4.so"
> dev=md0 
> >>>>>> ino=8061163 scontext=system_u:system_r:prelink_t:s0 
> >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>> audit(1147793154.831:354): avc:  denied  { execute_no_trans } 
> >>>>>> for  pid=5196 comm="prelink" name="ld-2.4.so"
> dev=md0 
> >>>>>> ino=8061163 scontext=system_u:system_r:prelink_t:s0 
> >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>> audit(1147793155.019:355): avc:  denied  { execute_no_trans } 
> >>>>>> for  pid=5197 comm="prelink" name="ld-2.4.so"
> dev=md0 
> >>>>>> ino=8061163 scontext=system_u:system_r:prelink_t:s0 
> >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>> audit(1147793155.447:356): avc:  denied  { execute_no_trans } 
> >>>>>> for  pid=5198 comm="prelink" name="ld-2.4.so"
> dev=md0 
> >>>>>> ino=8061163 scontext=system_u:system_r:prelink_t:s0 
> >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>> audit(1147793156.255:357): avc:  denied  { execute_no_trans } 
> >>>>>> for  pid=5199 comm="prelink" name="ld-2.4.so"
> dev=md0 
> >>>>>> ino=8061163 scontext=system_u:system_r:prelink_t:s0 
> >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5
> >>>>>> whats gonig on? is a file misslabeled or is this a policy bug?
> >>>>>>
> >>>>>> -- 
> >>>>>> fedora-selinux-list mailing list
> >>>>>> fedora-selinux-list(a)redhat.com
> >>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >>>>>>
> >>>>>>
> >>>>>>         
> >>>>> hello?
> >>>>> any solution for this problem?
> >>>>>
> >>>>>
> >>>>>       
> >>>> it happend again...
> >>>> am I the only  one seeing this?
> >>>> audit(1148393411.538:2907): avc:  denied  { execute_no_trans } 
> >>>> for  pid=16856 comm="prelink" name="ld-2.4.so"
> dev=md0 ino=8060939 
> >>>> scontext=system_u:system_r:prelink_t:s0 
> >>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>> audit(1148393411.794:2908): avc:  denied  { execmod } for  
> >>>> pid=16859 comm="ld-linux.so.2"
> name="libGLcore.so.1.0.8762" 
> >>>> dev=md0 ino=29797475 scontext=system_u:system_r:prelink_t:s0 
> >>>> tcontext=root:object_r:lib_t:s0 tclass=file
> >>>> audit(1148393411.814:2909): avc:  denied  { execmod } for  
> >>>> pid=16860 comm="ld-linux.so.2"
> name="libnvidia-tls.so.1.0.8762" 
> >>>> dev=md0 ino=30869146 scontext=system_u:system_r:prelink_t:s0 
> >>>> tcontext=root:object_r:lib_t:s0 tclass=file
> >>>> audit(1148393412.438:2910): avc:  denied  { unlink } for  
> >>>> pid=13702 comm="prelink" name="prelink.cache" dev=md0
> ino=7012828 
> >>>> scontext=system_u:system_r:prelink_t:s0 
> >>>> tcontext=user_u:object_r:etc_t:s0 tclass=file
> >>>> prelink seems to be completly broken and nobody seems to notice it?
> >>>>     
> >>>
> >>> I'm not seeing this anywhere.
> >>>
> >>> Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t on 
> >>> your
> >>> system?
> >>>
> >>> Paul.
> >>>
> >>>
> >>>
> >>>   
> >> ls -Z /lib/ld-2.4.so
> >> -rwxr-xr-x  root     root     system_u:object_r:ld_so_t        
> >> /lib/ld-2.4.so
> >> ls -Z /lib64/ld-2.4.so
> >> -rwxr-xr-x  root     root     system_u:object_r:lib_t
> >> seems that you are correct lets hope that this wont happen again.
> >>
> >> -- 
> >> fedora-selinux-list mailing list
> >> fedora-selinux-list(a)redhat.com
> >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >>
> >>
> > this *is* a bug
> > restorecon /lib64/ld-2.4.so
> > does not change it to ld_so_t (had to do a chcon)
> >
> >
> >
>
>  I did a complete relabel and the result is
>  ls -Z /lib64/ld-2.4.so
>  -rwxr-xr-x  root     root     system_u:object_r:lib_t          
>  /lib64/ld-2.4.so
>  I also noticed this:
>  drwxr-xr-x  root     root     system_u:object_r:bin_t          bin
>  drwxr-xr-x  root     root     system_u:object_r:boot_t         boot
>  drwxr-xr-x  root     root     system_u:object_r:device_t       dev
>  drwxr-xr-x  root     root     system_u:object_r:etc_t          etc
>  drwxr-xr-x  root     root     system_u:object_r:home_root_t    home
>  drwxr-xr-x  root     root     system_u:object_r:lib_t          lib
>  drwxr-xr-x  root     root     system_u:object_r:lib_t          lib64
>  drwx------  root     root     system_u:object_r:lost_found_t   lost+found
>  drwxr-xr-x  root     root     system_u:object_r:mnt_t          media
>  drwxr-xr-x  root     root     system_u:object_r:mnt_t          misc
>  drwxr-xr-x  root     root     system_u:object_r:mnt_t          mnt
>  dr-xr-xr-x  root     root     system_u:object_r:mnt_t          net
>  drwxr-xr-x  root     root     system_u:object_r:usr_t          opt
>  dr-xr-xr-x  root     root     system_u:object_r:proc_t         proc
>  drwxr-x---  root     root     root:object_r:user_home_dir_t    root
>  drwxr-xr-x  root     root     system_u:object_r:sbin_t         sbin
>  drwxr-xr-x  root     root     system_u:object_r:security_t     selinux
>  drwxr-xr-x  root     root     system_u:object_r:var_t          srv
>  drwxr-xr-x  root     root     system_u:object_r:sysfs_t        sys
>  drwxrwxrwt  root     root     system_u:object_r:tmp_t          tmp
>  drwxr-xr-x  root     root     system_u:object_r:usr_t          usr
>  drwxr-xr-x  root     root     system_u:object_r:var_t          var
>  looks incorrect too whats going on here?
>  
bug filled:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192839

selinux prelink avc's (broken paths in policy?)

[Paul Howarth]

On Tue, 2006-05-23 at 17:17 +0200, dragoran wrote:
>  dragoran wrote:
>  > dragoran wrote:
>  >> Paul Howarth wrote:
>  >>> On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote:
>  >>>  
>  >>>> dragoran wrote:
>  >>>>   
>  >>>>> dragoran wrote:
>  >>>>>     
>  >>>>>> audit(1147793154.831:353): avc:  denied  { execute_no_trans } 
>  >>>>>> for  pid=5195 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
>  >>>>>> scontext=system_u:system_r:prelink_t:s0 
>  >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  >>>>>> audit(1147793154.831:354): avc:  denied  { execute_no_trans } 
>  >>>>>> for  pid=5196 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
>  >>>>>> scontext=system_u:system_r:prelink_t:s0 
>  >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  >>>>>> audit(1147793155.019:355): avc:  denied  { execute_no_trans } 
>  >>>>>> for  pid=5197 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
>  >>>>>> scontext=system_u:system_r:prelink_t:s0 
>  >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  >>>>>> audit(1147793155.447:356): avc:  denied  { execute_no_trans } 
>  >>>>>> for  pid=5198 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
>  >>>>>> scontext=system_u:system_r:prelink_t:s0 
>  >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  >>>>>> audit(1147793156.255:357): avc:  denied  { execute_no_trans } 
>  >>>>>> for  pid=5199 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
>  >>>>>> scontext=system_u:system_r:prelink_t:s0 
>  >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  >>>>>> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5
>  >>>>>> whats gonig on? is a file misslabeled or is this a policy bug?
>  >>>>>>
>  >>>>>> -- 
>  >>>>>> fedora-selinux-list mailing list
>  >>>>>> fedora-selinux-list(a)redhat.com
>  >>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  >>>>>>
>  >>>>>>
>  >>>>>>         
>  >>>>> hello?
>  >>>>> any solution for this problem?
>  >>>>>
>  >>>>>
>  >>>>>       
>  >>>> it happend again...
>  >>>> am I the only  one seeing this?
>  >>>> audit(1148393411.538:2907): avc:  denied  { execute_no_trans } for  
>  >>>> pid=16856 comm="prelink" name="ld-2.4.so" dev=md0
> ino=8060939 
>  >>>> scontext=system_u:system_r:prelink_t:s0 
>  >>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  >>>> audit(1148393411.794:2908): avc:  denied  { execmod } for  
>  >>>> pid=16859 comm="ld-linux.so.2"
> name="libGLcore.so.1.0.8762" dev=md0 
>  >>>> ino=29797475 scontext=system_u:system_r:prelink_t:s0 
>  >>>> tcontext=root:object_r:lib_t:s0 tclass=file
>  >>>> audit(1148393411.814:2909): avc:  denied  { execmod } for  
>  >>>> pid=16860 comm="ld-linux.so.2"
> name="libnvidia-tls.so.1.0.8762" 
>  >>>> dev=md0 ino=30869146 scontext=system_u:system_r:prelink_t:s0 
>  >>>> tcontext=root:object_r:lib_t:s0 tclass=file
>  >>>> audit(1148393412.438:2910): avc:  denied  { unlink } for  pid=13702 
>  >>>> comm="prelink" name="prelink.cache" dev=md0
> ino=7012828 
>  >>>> scontext=system_u:system_r:prelink_t:s0 
>  >>>> tcontext=user_u:object_r:etc_t:s0 tclass=file
>  >>>> prelink seems to be completly broken and nobody seems to notice it?
>  >>>>     
>  >>>
>  >>> I'm not seeing this anywhere.
>  >>>
>  >>> Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t on 
>  >>> your
>  >>> system?
>  >>>
>  >>> Paul.
>  >>>
>  >>>
>  >>>
>  >>>   
>  >> ls -Z /lib/ld-2.4.so
>  >> -rwxr-xr-x  root     root     system_u:object_r:ld_so_t        
>  >> /lib/ld-2.4.so
>  >> ls -Z /lib64/ld-2.4.so
>  >> -rwxr-xr-x  root     root     system_u:object_r:lib_t
>  >> seems that you are correct lets hope that this wont happen again.
>  >>
>  >> -- 
>  >> fedora-selinux-list mailing list
>  >> fedora-selinux-list(a)redhat.com
>  >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  >>
>  >>
>  > this *is* a bug
>  > restorecon /lib64/ld-2.4.so
>  > does not change it to ld_so_t (had to do a chcon)
>  >
>  >
>  >
>  
>  I did a complete relabel and the result is
>  ls -Z /lib64/ld-2.4.so
>  -rwxr-xr-x  root     root     system_u:object_r:lib_t          
>  /lib64/ld-2.4.so 
The context line that *should* match this appears to be:
/lib(64)?(/.*)?/ld-[^/]*\.so(\.[^/]*)*             regular file
system_u:object_r:ld_so_t:s0

But this appears to be overruled by one of these:
/lib(/.*)?                                         all files
system_u:object_r:lib_t:s0
/lib64(/.*)?                                       all files
system_u:object_r:lib_t:s0

I'm not sure what it is that decides which is the best match. The top
one is longer and appears to me to be more specific, but it does have
more wildcards in it...

>  I also noticed this:
>  drwxr-xr-x  root     root     system_u:object_r:bin_t          bin
>  drwxr-xr-x  root     root     system_u:object_r:boot_t         boot
>  drwxr-xr-x  root     root     system_u:object_r:device_t       dev
>  drwxr-xr-x  root     root     system_u:object_r:etc_t          etc
>  drwxr-xr-x  root     root     system_u:object_r:home_root_t    home
>  drwxr-xr-x  root     root     system_u:object_r:lib_t          lib
>  drwxr-xr-x  root     root     system_u:object_r:lib_t          lib64
>  drwx------  root     root     system_u:object_r:lost_found_t   lost+found
>  drwxr-xr-x  root     root     system_u:object_r:mnt_t          media
>  drwxr-xr-x  root     root     system_u:object_r:mnt_t          misc
>  drwxr-xr-x  root     root     system_u:object_r:mnt_t          mnt
>  dr-xr-xr-x  root     root     system_u:object_r:mnt_t          net
>  drwxr-xr-x  root     root     system_u:object_r:usr_t          opt
>  dr-xr-xr-x  root     root     system_u:object_r:proc_t         proc
>  drwxr-x---  root     root     root:object_r:user_home_dir_t    root
>  drwxr-xr-x  root     root     system_u:object_r:sbin_t         sbin
>  drwxr-xr-x  root     root     system_u:object_r:security_t     selinux
>  drwxr-xr-x  root     root     system_u:object_r:var_t          srv
>  drwxr-xr-x  root     root     system_u:object_r:sysfs_t        sys
>  drwxrwxrwt  root     root     system_u:object_r:tmp_t          tmp
>  drwxr-xr-x  root     root     system_u:object_r:usr_t          usr
>  drwxr-xr-x  root     root     system_u:object_r:var_t          var
>  looks incorrect too whats going on here? 
Looks like mine. What do you think is wrong with this? Nothing stands
out to me.

Paul.

selinux prelink avc's (broken paths in policy?)

[dragoran]

Paul Howarth wrote:
>  On Tue, 2006-05-23 at 17:17 +0200, dragoran wrote:
>    
> > dragoran wrote:
> >     
> >> dragoran wrote:
> >>       
> >>> Paul Howarth wrote:
> >>>         
> >>>> On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote:
> >>>>  
> >>>>           
> >>>>> dragoran wrote:
> >>>>>   
> >>>>>             
> >>>>>> dragoran wrote:
> >>>>>>     
> >>>>>>               
> >>>>>>> audit(1147793154.831:353): avc:  denied  { execute_no_trans }
>
> >>>>>>> for  pid=5195 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
> >>>>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>>> audit(1147793154.831:354): avc:  denied  { execute_no_trans }
>
> >>>>>>> for  pid=5196 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
> >>>>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>>> audit(1147793155.019:355): avc:  denied  { execute_no_trans }
>
> >>>>>>> for  pid=5197 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
> >>>>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>>> audit(1147793155.447:356): avc:  denied  { execute_no_trans }
>
> >>>>>>> for  pid=5198 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
> >>>>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>>> audit(1147793156.255:357): avc:  denied  { execute_no_trans }
>
> >>>>>>> for  pid=5199 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
> >>>>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>>> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5
> >>>>>>> whats gonig on? is a file misslabeled or is this a policy
> bug?
> >>>>>>>
> >>>>>>> -- 
> >>>>>>> fedora-selinux-list mailing list
> >>>>>>> fedora-selinux-list(a)redhat.com
> >>>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >>>>>>>
> >>>>>>>
> >>>>>>>         
> >>>>>>>                 
> >>>>>> hello?
> >>>>>> any solution for this problem?
> >>>>>>
> >>>>>>
> >>>>>>       
> >>>>>>               
> >>>>> it happend again...
> >>>>> am I the only  one seeing this?
> >>>>> audit(1148393411.538:2907): avc:  denied  { execute_no_trans } for  
> >>>>> pid=16856 comm="prelink" name="ld-2.4.so" dev=md0
> ino=8060939 
> >>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>> audit(1148393411.794:2908): avc:  denied  { execmod } for  
> >>>>> pid=16859 comm="ld-linux.so.2"
> name="libGLcore.so.1.0.8762" dev=md0 
> >>>>> ino=29797475 scontext=system_u:system_r:prelink_t:s0 
> >>>>> tcontext=root:object_r:lib_t:s0 tclass=file
> >>>>> audit(1148393411.814:2909): avc:  denied  { execmod } for  
> >>>>> pid=16860 comm="ld-linux.so.2"
> name="libnvidia-tls.so.1.0.8762" 
> >>>>> dev=md0 ino=30869146 scontext=system_u:system_r:prelink_t:s0 
> >>>>> tcontext=root:object_r:lib_t:s0 tclass=file
> >>>>> audit(1148393412.438:2910): avc:  denied  { unlink } for  pid=13702 
> >>>>> comm="prelink" name="prelink.cache" dev=md0
> ino=7012828 
> >>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>> tcontext=user_u:object_r:etc_t:s0 tclass=file
> >>>>> prelink seems to be completly broken and nobody seems to notice it?
> >>>>>     
> >>>>>             
> >>>> I'm not seeing this anywhere.
> >>>>
> >>>> Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t on 
> >>>> your
> >>>> system?
> >>>>
> >>>> Paul.
> >>>>
> >>>>
> >>>>
> >>>>   
> >>>>           
> >>> ls -Z /lib/ld-2.4.so
> >>> -rwxr-xr-x  root     root     system_u:object_r:ld_so_t        
> >>> /lib/ld-2.4.so
> >>> ls -Z /lib64/ld-2.4.so
> >>> -rwxr-xr-x  root     root     system_u:object_r:lib_t
> >>> seems that you are correct lets hope that this wont happen again.
> >>>
> >>> -- 
> >>> fedora-selinux-list mailing list
> >>> fedora-selinux-list(a)redhat.com
> >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >>>
> >>>
> >>>         
> >> this *is* a bug
> >> restorecon /lib64/ld-2.4.so
> >> does not change it to ld_so_t (had to do a chcon)
> >>
> >>
> >>
> >>       
> > I did a complete relabel and the result is
> > ls -Z /lib64/ld-2.4.so
> > -rwxr-xr-x  root     root     system_u:object_r:lib_t          
> > /lib64/ld-2.4.so
> >     
>
>  The context line that *should* match this appears to be:
>  /lib(64)?(/.*)?/ld-[^/]*\.so(\.[^/]*)*             regular file
>  system_u:object_r:ld_so_t:s0
>
>  But this appears to be overruled by one of these:
>  /lib(/.*)?                                         all files
>  system_u:object_r:lib_t:s0
>  /lib64(/.*)?                                       all files
>  system_u:object_r:lib_t:s0
>
>  I'm not sure what it is that decides which is the best match. The top
>  one is longer and appears to me to be more specific, but it does have
>  more wildcards in it...
>
>    
> > I also noticed this:
> > drwxr-xr-x  root     root     system_u:object_r:bin_t          bin
> > drwxr-xr-x  root     root     system_u:object_r:boot_t         boot
> > drwxr-xr-x  root     root     system_u:object_r:device_t       dev
> > drwxr-xr-x  root     root     system_u:object_r:etc_t          etc
> > drwxr-xr-x  root     root     system_u:object_r:home_root_t    home
> > drwxr-xr-x  root     root     system_u:object_r:lib_t          lib
> > drwxr-xr-x  root     root     system_u:object_r:lib_t          lib64
> > drwx------  root     root     system_u:object_r:lost_found_t   lost+found
> > drwxr-xr-x  root     root     system_u:object_r:mnt_t          media
> > drwxr-xr-x  root     root     system_u:object_r:mnt_t          misc
> > drwxr-xr-x  root     root     system_u:object_r:mnt_t          mnt
> > dr-xr-xr-x  root     root     system_u:object_r:mnt_t          net
> > drwxr-xr-x  root     root     system_u:object_r:usr_t          opt
> > dr-xr-xr-x  root     root     system_u:object_r:proc_t         proc
> > drwxr-x---  root     root     root:object_r:user_home_dir_t    root
> > drwxr-xr-x  root     root     system_u:object_r:sbin_t         sbin
> > drwxr-xr-x  root     root     system_u:object_r:security_t     selinux
> > drwxr-xr-x  root     root     system_u:object_r:var_t          srv
> > drwxr-xr-x  root     root     system_u:object_r:sysfs_t        sys
> > drwxrwxrwt  root     root     system_u:object_r:tmp_t          tmp
> > drwxr-xr-x  root     root     system_u:object_r:usr_t          usr
> > drwxr-xr-x  root     root     system_u:object_r:var_t          var
> > looks incorrect too whats going on here?
> >     
>
>  Looks like mine. What do you think is wrong with this? Nothing stands
>  out to me.
>
>  Paul.
>
>
>
>     
root:object_r:user_home_dir_t    root should be /home and 
system_u:object_r:home_root_t    home should be /root something weird is going on here...

selinux prelink avc's (broken paths in policy?)

[Paul Howarth]

On Tue, 2006-05-23 at 17:34 +0200, dragoran wrote:
>  Paul Howarth wrote:
>  > On Tue, 2006-05-23 at 17:17 +0200, dragoran wrote:
>  >   
>  >> dragoran wrote:
>  >>     
>  >>> dragoran wrote:
>  >>>       
>  >>>> Paul Howarth wrote:
>  >>>>         
>  >>>>> On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote:
>  >>>>>  
>  >>>>>           
>  >>>>>> dragoran wrote:
>  >>>>>>   
>  >>>>>>             
>  >>>>>>> dragoran wrote:
>  >>>>>>>     
>  >>>>>>>               
>  >>>>>>>> audit(1147793154.831:353): avc:  denied  {
> execute_no_trans } 
>  >>>>>>>> for  pid=5195 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
>  >>>>>>>> scontext=system_u:system_r:prelink_t:s0 
>  >>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  >>>>>>>> audit(1147793154.831:354): avc:  denied  {
> execute_no_trans } 
>  >>>>>>>> for  pid=5196 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
>  >>>>>>>> scontext=system_u:system_r:prelink_t:s0 
>  >>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  >>>>>>>> audit(1147793155.019:355): avc:  denied  {
> execute_no_trans } 
>  >>>>>>>> for  pid=5197 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
>  >>>>>>>> scontext=system_u:system_r:prelink_t:s0 
>  >>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  >>>>>>>> audit(1147793155.447:356): avc:  denied  {
> execute_no_trans } 
>  >>>>>>>> for  pid=5198 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
>  >>>>>>>> scontext=system_u:system_r:prelink_t:s0 
>  >>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  >>>>>>>> audit(1147793156.255:357): avc:  denied  {
> execute_no_trans } 
>  >>>>>>>> for  pid=5199 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
>  >>>>>>>> scontext=system_u:system_r:prelink_t:s0 
>  >>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  >>>>>>>> I am using FC5 with
> selinux-policy-targeted-2.2.36-2.fc5
>  >>>>>>>> whats gonig on? is a file misslabeled or is this a
> policy bug?
>  >>>>>>>>
>  >>>>>>>> -- 
>  >>>>>>>> fedora-selinux-list mailing list
>  >>>>>>>> fedora-selinux-list(a)redhat.com
>  >>>>>>>>
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>         
>  >>>>>>>>                 
>  >>>>>>> hello?
>  >>>>>>> any solution for this problem?
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>       
>  >>>>>>>               
>  >>>>>> it happend again...
>  >>>>>> am I the only  one seeing this?
>  >>>>>> audit(1148393411.538:2907): avc:  denied  { execute_no_trans }
> for  
>  >>>>>> pid=16856 comm="prelink" name="ld-2.4.so"
> dev=md0 ino=8060939 
>  >>>>>> scontext=system_u:system_r:prelink_t:s0 
>  >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  >>>>>> audit(1148393411.794:2908): avc:  denied  { execmod } for  
>  >>>>>> pid=16859 comm="ld-linux.so.2"
> name="libGLcore.so.1.0.8762" dev=md0 
>  >>>>>> ino=29797475 scontext=system_u:system_r:prelink_t:s0 
>  >>>>>> tcontext=root:object_r:lib_t:s0 tclass=file
>  >>>>>> audit(1148393411.814:2909): avc:  denied  { execmod } for  
>  >>>>>> pid=16860 comm="ld-linux.so.2"
> name="libnvidia-tls.so.1.0.8762" 
>  >>>>>> dev=md0 ino=30869146 scontext=system_u:system_r:prelink_t:s0 
>  >>>>>> tcontext=root:object_r:lib_t:s0 tclass=file
>  >>>>>> audit(1148393412.438:2910): avc:  denied  { unlink } for 
> pid=13702 
>  >>>>>> comm="prelink" name="prelink.cache" dev=md0
> ino=7012828 
>  >>>>>> scontext=system_u:system_r:prelink_t:s0 
>  >>>>>> tcontext=user_u:object_r:etc_t:s0 tclass=file
>  >>>>>> prelink seems to be completly broken and nobody seems to notice
> it?
>  >>>>>>     
>  >>>>>>             
>  >>>>> I'm not seeing this anywhere.
>  >>>>>
>  >>>>> Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t
> on 
>  >>>>> your
>  >>>>> system?
>  >>>>>
>  >>>>> Paul.
>  >>>>>
>  >>>>>
>  >>>>>
>  >>>>>   
>  >>>>>           
>  >>>> ls -Z /lib/ld-2.4.so
>  >>>> -rwxr-xr-x  root     root     system_u:object_r:ld_so_t        
>  >>>> /lib/ld-2.4.so
>  >>>> ls -Z /lib64/ld-2.4.so
>  >>>> -rwxr-xr-x  root     root     system_u:object_r:lib_t
>  >>>> seems that you are correct lets hope that this wont happen again.
>  >>>>
>  >>>> -- 
>  >>>> fedora-selinux-list mailing list
>  >>>> fedora-selinux-list(a)redhat.com
>  >>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  >>>>
>  >>>>
>  >>>>         
>  >>> this *is* a bug
>  >>> restorecon /lib64/ld-2.4.so
>  >>> does not change it to ld_so_t (had to do a chcon)
>  >>>
>  >>>
>  >>>
>  >>>       
>  >> I did a complete relabel and the result is
>  >> ls -Z /lib64/ld-2.4.so
>  >> -rwxr-xr-x  root     root     system_u:object_r:lib_t          
>  >> /lib64/ld-2.4.so
>  >>     
>  >
>  > The context line that *should* match this appears to be:
>  > /lib(64)?(/.*)?/ld-[^/]*\.so(\.[^/]*)*             regular file
>  > system_u:object_r:ld_so_t:s0
>  >
>  > But this appears to be overruled by one of these:
>  > /lib(/.*)?                                         all files
>  > system_u:object_r:lib_t:s0
>  > /lib64(/.*)?                                       all files
>  > system_u:object_r:lib_t:s0
>  >
>  > I'm not sure what it is that decides which is the best match. The top
>  > one is longer and appears to me to be more specific, but it does have
>  > more wildcards in it...
>  >
>  >   
>  >> I also noticed this:
>  >> drwxr-xr-x  root     root     system_u:object_r:bin_t          bin
>  >> drwxr-xr-x  root     root     system_u:object_r:boot_t         boot
>  >> drwxr-xr-x  root     root     system_u:object_r:device_t       dev
>  >> drwxr-xr-x  root     root     system_u:object_r:etc_t          etc
>  >> drwxr-xr-x  root     root     system_u:object_r:home_root_t    home
>  >> drwxr-xr-x  root     root     system_u:object_r:lib_t          lib
>  >> drwxr-xr-x  root     root     system_u:object_r:lib_t          lib64
>  >> drwx------  root     root     system_u:object_r:lost_found_t   lost+found
>  >> drwxr-xr-x  root     root     system_u:object_r:mnt_t          media
>  >> drwxr-xr-x  root     root     system_u:object_r:mnt_t          misc
>  >> drwxr-xr-x  root     root     system_u:object_r:mnt_t          mnt
>  >> dr-xr-xr-x  root     root     system_u:object_r:mnt_t          net
>  >> drwxr-xr-x  root     root     system_u:object_r:usr_t          opt
>  >> dr-xr-xr-x  root     root     system_u:object_r:proc_t         proc
>  >> drwxr-x---  root     root     root:object_r:user_home_dir_t    root
>  >> drwxr-xr-x  root     root     system_u:object_r:sbin_t         sbin
>  >> drwxr-xr-x  root     root     system_u:object_r:security_t     selinux
>  >> drwxr-xr-x  root     root     system_u:object_r:var_t          srv
>  >> drwxr-xr-x  root     root     system_u:object_r:sysfs_t        sys
>  >> drwxrwxrwt  root     root     system_u:object_r:tmp_t          tmp
>  >> drwxr-xr-x  root     root     system_u:object_r:usr_t          usr
>  >> drwxr-xr-x  root     root     system_u:object_r:var_t          var
>  >> looks incorrect too whats going on here?
>  >>     
>  >
>  > Looks like mine. What do you think is wrong with this? Nothing stands
>  > out to me.
>  >
>  > Paul.
>  >
>  >
>  >
>  >   
>  
>  root:object_r:user_home_dir_t    root should be /home and 
>  system_u:object_r:home_root_t    home should be /root something weird is going on here...
I disagree. I think these are correct.

/root is the home directory for user "root" and should be
user_home_dir_t, just like any other user's home directory.

/home is the root of the "home" directory tree, where most user home
directories live, so home_root_t seems OK for that.

Perhaps it's just the names of the context types that are confusing?

Paul.

selinux prelink avc's (broken paths in policy?)

[dragoran]

Paul Howarth wrote:
>  On Tue, 2006-05-23 at 17:34 +0200, dragoran wrote:
>    
> > Paul Howarth wrote:
> >     
> >> On Tue, 2006-05-23 at 17:17 +0200, dragoran wrote:
> >>   
> >>       
> >>> dragoran wrote:
> >>>     
> >>>         
> >>>> dragoran wrote:
> >>>>       
> >>>>           
> >>>>> Paul Howarth wrote:
> >>>>>         
> >>>>>             
> >>>>>> On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote:
> >>>>>>  
> >>>>>>           
> >>>>>>               
> >>>>>>> dragoran wrote:
> >>>>>>>   
> >>>>>>>             
> >>>>>>>                 
> >>>>>>>> dragoran wrote:
> >>>>>>>>     
> >>>>>>>>               
> >>>>>>>>                   
> >>>>>>>>> audit(1147793154.831:353): avc:  denied  {
> execute_no_trans } 
> >>>>>>>>> for  pid=5195 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
> >>>>>>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>>>>> audit(1147793154.831:354): avc:  denied  {
> execute_no_trans } 
> >>>>>>>>> for  pid=5196 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
> >>>>>>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>>>>> audit(1147793155.019:355): avc:  denied  {
> execute_no_trans } 
> >>>>>>>>> for  pid=5197 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
> >>>>>>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>>>>> audit(1147793155.447:356): avc:  denied  {
> execute_no_trans } 
> >>>>>>>>> for  pid=5198 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
> >>>>>>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>>>>> audit(1147793156.255:357): avc:  denied  {
> execute_no_trans } 
> >>>>>>>>> for  pid=5199 comm="prelink"
> name="ld-2.4.so" dev=md0 ino=8061163 
> >>>>>>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>>>>> I am using FC5 with
> selinux-policy-targeted-2.2.36-2.fc5
> >>>>>>>>> whats gonig on? is a file misslabeled or is this a
> policy bug?
> >>>>>>>>>
> >>>>>>>>> -- 
> >>>>>>>>> fedora-selinux-list mailing list
> >>>>>>>>> fedora-selinux-list(a)redhat.com
> >>>>>>>>>
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>         
> >>>>>>>>>                 
> >>>>>>>>>                     
> >>>>>>>> hello?
> >>>>>>>> any solution for this problem?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>       
> >>>>>>>>               
> >>>>>>>>                   
> >>>>>>> it happend again...
> >>>>>>> am I the only  one seeing this?
> >>>>>>> audit(1148393411.538:2907): avc:  denied  { execute_no_trans
> } for  
> >>>>>>> pid=16856 comm="prelink" name="ld-2.4.so"
> dev=md0 ino=8060939 
> >>>>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>>> audit(1148393411.794:2908): avc:  denied  { execmod } for  
> >>>>>>> pid=16859 comm="ld-linux.so.2"
> name="libGLcore.so.1.0.8762" dev=md0 
> >>>>>>> ino=29797475 scontext=system_u:system_r:prelink_t:s0 
> >>>>>>> tcontext=root:object_r:lib_t:s0 tclass=file
> >>>>>>> audit(1148393411.814:2909): avc:  denied  { execmod } for  
> >>>>>>> pid=16860 comm="ld-linux.so.2"
> name="libnvidia-tls.so.1.0.8762" 
> >>>>>>> dev=md0 ino=30869146 scontext=system_u:system_r:prelink_t:s0
>
> >>>>>>> tcontext=root:object_r:lib_t:s0 tclass=file
> >>>>>>> audit(1148393412.438:2910): avc:  denied  { unlink } for 
> pid=13702 
> >>>>>>> comm="prelink" name="prelink.cache"
> dev=md0 ino=7012828 
> >>>>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>> tcontext=user_u:object_r:etc_t:s0 tclass=file
> >>>>>>> prelink seems to be completly broken and nobody seems to
> notice it?
> >>>>>>>     
> >>>>>>>             
> >>>>>>>                 
> >>>>>> I'm not seeing this anywhere.
> >>>>>>
> >>>>>> Perhaps it's because /lib/ld-2.4.so is lib_t rather than
> ld_so_t on 
> >>>>>> your
> >>>>>> system?
> >>>>>>
> >>>>>> Paul.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>   
> >>>>>>           
> >>>>>>               
> >>>>> ls -Z /lib/ld-2.4.so
> >>>>> -rwxr-xr-x  root     root     system_u:object_r:ld_so_t        
> >>>>> /lib/ld-2.4.so
> >>>>> ls -Z /lib64/ld-2.4.so
> >>>>> -rwxr-xr-x  root     root     system_u:object_r:lib_t
> >>>>> seems that you are correct lets hope that this wont happen again.
> >>>>>
> >>>>> -- 
> >>>>> fedora-selinux-list mailing list
> >>>>> fedora-selinux-list(a)redhat.com
> >>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >>>>>
> >>>>>
> >>>>>         
> >>>>>             
> >>>> this *is* a bug
> >>>> restorecon /lib64/ld-2.4.so
> >>>> does not change it to ld_so_t (had to do a chcon)
> >>>>
> >>>>
> >>>>
> >>>>       
> >>>>           
> >>> I did a complete relabel and the result is
> >>> ls -Z /lib64/ld-2.4.so
> >>> -rwxr-xr-x  root     root     system_u:object_r:lib_t          
> >>> /lib64/ld-2.4.so
> >>>     
> >>>         
> >> The context line that *should* match this appears to be:
> >> /lib(64)?(/.*)?/ld-[^/]*\.so(\.[^/]*)*             regular file
> >> system_u:object_r:ld_so_t:s0
> >>
> >> But this appears to be overruled by one of these:
> >> /lib(/.*)?                                         all files
> >> system_u:object_r:lib_t:s0
> >> /lib64(/.*)?                                       all files
> >> system_u:object_r:lib_t:s0
> >>
> >> I'm not sure what it is that decides which is the best match. The top
> >> one is longer and appears to me to be more specific, but it does have
> >> more wildcards in it...
> >>
> >>   
> >>       
> >>> I also noticed this:
> >>> drwxr-xr-x  root     root     system_u:object_r:bin_t          bin
> >>> drwxr-xr-x  root     root     system_u:object_r:boot_t         boot
> >>> drwxr-xr-x  root     root     system_u:object_r:device_t       dev
> >>> drwxr-xr-x  root     root     system_u:object_r:etc_t          etc
> >>> drwxr-xr-x  root     root     system_u:object_r:home_root_t    home
> >>> drwxr-xr-x  root     root     system_u:object_r:lib_t          lib
> >>> drwxr-xr-x  root     root     system_u:object_r:lib_t          lib64
> >>> drwx------  root     root     system_u:object_r:lost_found_t   lost+found
> >>> drwxr-xr-x  root     root     system_u:object_r:mnt_t          media
> >>> drwxr-xr-x  root     root     system_u:object_r:mnt_t          misc
> >>> drwxr-xr-x  root     root     system_u:object_r:mnt_t          mnt
> >>> dr-xr-xr-x  root     root     system_u:object_r:mnt_t          net
> >>> drwxr-xr-x  root     root     system_u:object_r:usr_t          opt
> >>> dr-xr-xr-x  root     root     system_u:object_r:proc_t         proc
> >>> drwxr-x---  root     root     root:object_r:user_home_dir_t    root
> >>> drwxr-xr-x  root     root     system_u:object_r:sbin_t         sbin
> >>> drwxr-xr-x  root     root     system_u:object_r:security_t     selinux
> >>> drwxr-xr-x  root     root     system_u:object_r:var_t          srv
> >>> drwxr-xr-x  root     root     system_u:object_r:sysfs_t        sys
> >>> drwxrwxrwt  root     root     system_u:object_r:tmp_t          tmp
> >>> drwxr-xr-x  root     root     system_u:object_r:usr_t          usr
> >>> drwxr-xr-x  root     root     system_u:object_r:var_t          var
> >>> looks incorrect too whats going on here?
> >>>     
> >>>         
> >> Looks like mine. What do you think is wrong with this? Nothing stands
> >> out to me.
> >>
> >> Paul.
> >>
> >>
> >>
> >>   
> >>       
> > root:object_r:user_home_dir_t    root should be /home and 
> > system_u:object_r:home_root_t    home should be /root something weird is going on
> here...
> >     
>
>  I disagree. I think these are correct.
>
>  /root is the home directory for user "root" and should be
>  user_home_dir_t, just like any other user's home directory.
>
>  /home is the root of the "home" directory tree, where most user home
>  directories live, so home_root_t seems OK for that.
>
>     
thx got it
>  Perhaps it's just the names of the context types that are
> confusing?
>     
yes
>  Paul.
>
>
>
>

selinux prelink avc's (broken paths in policy?)

[Daniel J Walsh]

dragoran wrote:
>  Paul Howarth wrote:
> > On Tue, 2006-05-23 at 17:34 +0200, dragoran wrote:
> >  
> >> Paul Howarth wrote:
> >>    
> >>> On Tue, 2006-05-23 at 17:17 +0200, dragoran wrote:
> >>>        
> >>>> dragoran wrote:
> >>>>            
> >>>>> dragoran wrote:
> >>>>>                
> >>>>>> Paul Howarth wrote:
> >>>>>>                    
> >>>>>>> On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote:
> >>>>>>>  
> >>>>>>>                        
> >>>>>>>> dragoran wrote:
> >>>>>>>>                              
> >>>>>>>>> dragoran wrote:
> >>>>>>>>>                                    
> >>>>>>>>>> audit(1147793154.831:353): avc:  denied  {
> execute_no_trans 
> >>>>>>>>>> } for  pid=5195 comm="prelink"
> name="ld-2.4.so" dev=md0 
> >>>>>>>>>> ino=8061163
> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>>>>>> audit(1147793154.831:354): avc:  denied  {
> execute_no_trans 
> >>>>>>>>>> } for  pid=5196 comm="prelink"
> name="ld-2.4.so" dev=md0 
> >>>>>>>>>> ino=8061163
> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>>>>>> audit(1147793155.019:355): avc:  denied  {
> execute_no_trans 
> >>>>>>>>>> } for  pid=5197 comm="prelink"
> name="ld-2.4.so" dev=md0 
> >>>>>>>>>> ino=8061163
> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>>>>>> audit(1147793155.447:356): avc:  denied  {
> execute_no_trans 
> >>>>>>>>>> } for  pid=5198 comm="prelink"
> name="ld-2.4.so" dev=md0 
> >>>>>>>>>> ino=8061163
> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>>>>>> audit(1147793156.255:357): avc:  denied  {
> execute_no_trans 
> >>>>>>>>>> } for  pid=5199 comm="prelink"
> name="ld-2.4.so" dev=md0 
> >>>>>>>>>> ino=8061163
> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>>>>>> I am using FC5 with
> selinux-policy-targeted-2.2.36-2.fc5
> >>>>>>>>>> whats gonig on? is a file misslabeled or is this
> a policy bug?
> >>>>>>>>>>
> >>>>>>>>>> -- 
> >>>>>>>>>> fedora-selinux-list mailing list
> >>>>>>>>>> fedora-selinux-list(a)redhat.com
> >>>>>>>>>>
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>                                             
> >>>>>>>>> hello?
> >>>>>>>>> any solution for this problem?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>                                       
> >>>>>>>> it happend again...
> >>>>>>>> am I the only  one seeing this?
> >>>>>>>> audit(1148393411.538:2907): avc:  denied  {
> execute_no_trans } 
> >>>>>>>> for  pid=16856 comm="prelink"
> name="ld-2.4.so" dev=md0 
> >>>>>>>> ino=8060939 scontext=system_u:system_r:prelink_t:s0 
> >>>>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>>>> audit(1148393411.794:2908): avc:  denied  { execmod } for
>  
> >>>>>>>> pid=16859 comm="ld-linux.so.2"
> name="libGLcore.so.1.0.8762" 
> >>>>>>>> dev=md0 ino=29797475
> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>>> tcontext=root:object_r:lib_t:s0 tclass=file
> >>>>>>>> audit(1148393411.814:2909): avc:  denied  { execmod } for
>  
> >>>>>>>> pid=16860 comm="ld-linux.so.2" 
> >>>>>>>> name="libnvidia-tls.so.1.0.8762" dev=md0
> ino=30869146 
> >>>>>>>> scontext=system_u:system_r:prelink_t:s0 
> >>>>>>>> tcontext=root:object_r:lib_t:s0 tclass=file
> >>>>>>>> audit(1148393412.438:2910): avc:  denied  { unlink } for 
>
> >>>>>>>> pid=13702 comm="prelink"
> name="prelink.cache" dev=md0 
> >>>>>>>> ino=7012828 scontext=system_u:system_r:prelink_t:s0 
> >>>>>>>> tcontext=user_u:object_r:etc_t:s0 tclass=file
> >>>>>>>> prelink seems to be completly broken and nobody seems to
>
> >>>>>>>> notice it?
> >>>>>>>>                                 
> >>>>>>> I'm not seeing this anywhere.
> >>>>>>>
> >>>>>>> Perhaps it's because /lib/ld-2.4.so is lib_t rather than
>
> >>>>>>> ld_so_t on your
> >>>>>>> system?
> >>>>>>>
> >>>>>>> Paul.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>                           
> >>>>>> ls -Z /lib/ld-2.4.so
> >>>>>> -rwxr-xr-x  root     root     system_u:object_r:ld_so_t        
> >>>>>> /lib/ld-2.4.so
> >>>>>> ls -Z /lib64/ld-2.4.so
> >>>>>> -rwxr-xr-x  root     root     system_u:object_r:lib_t
> >>>>>> seems that you are correct lets hope that this wont happen
> again.
> >>>>>>
> >>>>>> -- 
> >>>>>> fedora-selinux-list mailing list
> >>>>>> fedora-selinux-list(a)redhat.com
> >>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >>>>>>
> >>>>>>
> >>>>>>                     
> >>>>> this *is* a bug
> >>>>> restorecon /lib64/ld-2.4.so
> >>>>> does not change it to ld_so_t (had to do a chcon)
> >>>>>
> >>>>>
> >>>>>
> >>>>>                 
> >>>> I did a complete relabel and the result is
> >>>> ls -Z /lib64/ld-2.4.so
> >>>> -rwxr-xr-x  root     root     system_u:object_r:lib_t          
> >>>> /lib64/ld-2.4.so
> >>>>             
> >>> The context line that *should* match this appears to be:
> >>> /lib(64)?(/.*)?/ld-[^/]*\.so(\.[^/]*)*             regular file
> >>> system_u:object_r:ld_so_t:s0
> >>>
> >>> But this appears to be overruled by one of these:
> >>> /lib(/.*)?                                         all files
> >>> system_u:object_r:lib_t:s0
> >>> /lib64(/.*)?                                       all files
> >>> system_u:object_r:lib_t:s0
> >>>
> >>> I'm not sure what it is that decides which is the best match. The top
> >>> one is longer and appears to me to be more specific, but it does have
> >>> more wildcards in it...
> >>>
> >>>        
> >>>> I also noticed this:
> >>>> drwxr-xr-x  root     root     system_u:object_r:bin_t          bin
> >>>> drwxr-xr-x  root     root     system_u:object_r:boot_t         boot
> >>>> drwxr-xr-x  root     root     system_u:object_r:device_t       dev
> >>>> drwxr-xr-x  root     root     system_u:object_r:etc_t          etc
> >>>> drwxr-xr-x  root     root     system_u:object_r:home_root_t    home
> >>>> drwxr-xr-x  root     root     system_u:object_r:lib_t          lib
> >>>> drwxr-xr-x  root     root     system_u:object_r:lib_t          lib64
> >>>> drwx------  root     root     system_u:object_r:lost_found_t   
> >>>> lost+found
> >>>> drwxr-xr-x  root     root     system_u:object_r:mnt_t          media
> >>>> drwxr-xr-x  root     root     system_u:object_r:mnt_t          misc
> >>>> drwxr-xr-x  root     root     system_u:object_r:mnt_t          mnt
> >>>> dr-xr-xr-x  root     root     system_u:object_r:mnt_t          net
> >>>> drwxr-xr-x  root     root     system_u:object_r:usr_t          opt
> >>>> dr-xr-xr-x  root     root     system_u:object_r:proc_t         proc
> >>>> drwxr-x---  root     root     root:object_r:user_home_dir_t    root
> >>>> drwxr-xr-x  root     root     system_u:object_r:sbin_t         sbin
> >>>> drwxr-xr-x  root     root     system_u:object_r:security_t     
> >>>> selinux
> >>>> drwxr-xr-x  root     root     system_u:object_r:var_t          srv
> >>>> drwxr-xr-x  root     root     system_u:object_r:sysfs_t        sys
> >>>> drwxrwxrwt  root     root     system_u:object_r:tmp_t          tmp
> >>>> drwxr-xr-x  root     root     system_u:object_r:usr_t          usr
> >>>> drwxr-xr-x  root     root     system_u:object_r:var_t          var
> >>>> looks incorrect too whats going on here?
> >>>>             
> >>> Looks like mine. What do you think is wrong with this? Nothing stands
> >>> out to me.
> >>>
> >>> Paul.
> >>>
> >>>
> >>>
> >>>         
> >> root:object_r:user_home_dir_t    root should be /home and 
> >> system_u:object_r:home_root_t    home should be /root something 
> >> weird is going on here...
> >>     
> >
> > I disagree. I think these are correct.
> >
> > /root is the home directory for user "root" and should be
> > user_home_dir_t, just like any other user's home directory.
> >
> > /home is the root of the "home" directory tree, where most user home
> > directories live, so home_root_t seems OK for that.
> >
> >   
>  thx got it
> > Perhaps it's just the names of the context types that are confusing?
> >   
>  yes
> > Paul.
> >
> >
> >
> >   
>
>
>  -- 
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list 
Yes /lib64/ld-2.4.so
has the wrong context.  These new sorting 
algorithms are driving me nuts.  I have fixed it in Rawhide, and
a new test package for fc5 is about to go out.

selinux prelink avc's (broken paths in policy?)

[Paul Howarth]

Daniel J Walsh wrote:
>  Yes /lib64/ld-2.4.so has the wrong context.  These new sorting 
>  algorithms are driving me nuts.  I have fixed it in Rawhide, and
>  a new test package for fc5 is about to go out. 
Is the sorting algorithm documented somewhere (the wiki?)?

Paul.

selinux prelink avc's (broken paths in policy?)

[Christopher Ashworth]

On Wed, 2006-05-24 at 15:22 +0100, Paul Howarth wrote:

>  Is the sorting algorithm documented somewhere (the wiki?)? 
The sorting algorithm is based on the following heuristics, applied in
this order:

When comparing two file contexts A and B...

- if A is a regular expression and B is not, A is less specific than B
- if A's stem length (the number of characters before the first regular
expression wildcard) is shorter than B's stem length, A is less specific
than B
- if A's string length (the entire length of the file context string) is
shorter than B's string length, A is less specific than B
- if A does not have a specified type and B does, A is less specific
than B.
- else, they are considered equally specific.

These are the same heuristics applied to file contexts when building
reference policy.  

The sort is implemented as a stable iterative mergesort.

Christopher

selinux prelink avc's (broken paths in policy?)

[Christopher Ashworth]

On Wed, 2006-05-24 at 10:39 -0400, Christopher Ashworth wrote:
>  - if A's stem length (the number of characters before the first
>  regular expression wildcard) is shorter than B's stem length, A is
>  less specific than B 
"Wildcard" isn't the best word to use here.  "Meta character" is
better.
They include:

. ^ $ ? * + | [ ( {



Chris

selinux prelink avc's (broken paths in policy?)

[Paul Howarth]

Christopher Ashworth wrote:
>  On Wed, 2006-05-24 at 15:22 +0100, Paul Howarth wrote:
>  
> > Is the sorting algorithm documented somewhere (the wiki?)?
>  
>  The sorting algorithm is based on the following heuristics, applied in
>  this order:
>  
>  When comparing two file contexts A and B...
>  
>  - if A is a regular expression and B is not, A is less specific than B
>  - if A's stem length (the number of characters before the first regular
>  expression wildcard) is shorter than B's stem length, A is less specific
>  than B
>  - if A's string length (the entire length of the file context string) is
>  shorter than B's string length, A is less specific than B
>  - if A does not have a specified type and B does, A is less specific
>  than B.
>  - else, they are considered equally specific. 
If there are two or more equally specific matches, is one picked at random?

Paul.

selinux prelink avc's (broken paths in policy?)

[Christopher Ashworth]

On Wed, 2006-05-24 at 16:06 +0100, Paul Howarth wrote:
>  Christopher Ashworth wrote:
>  > On Wed, 2006-05-24 at 15:22 +0100, Paul Howarth wrote:
>  > 
>  >> Is the sorting algorithm documented somewhere (the wiki?)?
>  > 
>  > The sorting algorithm is based on the following heuristics, applied in
>  > this order:
>  > 
>  > When comparing two file contexts A and B...
>  > 
>  > - if A is a regular expression and B is not, A is less specific than B
>  > - if A's stem length (the number of characters before the first regular
>  > expression wildcard) is shorter than B's stem length, A is less specific
>  > than B
>  > - if A's string length (the entire length of the file context string) is
>  > shorter than B's string length, A is less specific than B
>  > - if A does not have a specified type and B does, A is less specific
>  > than B.
>  > - else, they are considered equally specific.
>  
>  If there are two or more equally specific matches, is one picked at random?
>  
>  Paul. 
The sort is stable, so the order of the original file contexts is
maintained. The result is a list of all the file contexts sorted from
least specific to most specific.

When assigning the file contexts, the list is consulted in order of most
to least specific.  The first match wins.  If there were two contexts
that are considered equally specific, the original order given by the
author will determine which one wins.

Chris

selinux prelink avc's (broken paths in policy?)

[Daniel J Walsh]

Christopher Ashworth wrote:
>  On Wed, 2006-05-24 at 16:06 +0100, Paul Howarth wrote:
>    
> > Christopher Ashworth wrote:
> >     
> >> On Wed, 2006-05-24 at 15:22 +0100, Paul Howarth wrote:
> >>
> >>       
> >>> Is the sorting algorithm documented somewhere (the wiki?)?
> >>>         
> >> The sorting algorithm is based on the following heuristics, applied in
> >> this order:
> >>
> >> When comparing two file contexts A and B...
> >>
> >> - if A is a regular expression and B is not, A is less specific than B
> >> - if A's stem length (the number of characters before the first regular
> >> expression wildcard) is shorter than B's stem length, A is less specific
> >> than B
> >> - if A's string length (the entire length of the file context string) is
> >> shorter than B's string length, A is less specific than B
> >> - if A does not have a specified type and B does, A is less specific
> >> than B.
> >> - else, they are considered equally specific.
> >>       
> > If there are two or more equally specific matches, is one picked at random?
> >
> > Paul.
> >     
>
>  The sort is stable, so the order of the original file contexts is
>  maintained. The result is a list of all the file contexts sorted from
>  least specific to most specific.
>
>  When assigning the file contexts, the list is consulted in order of most
>  to least specific.  The first match wins.  If there were two contexts
>  that are considered equally specific, the original order given by the
>  author will determine which one wins.
>
>  Chris
>     
Chris I just put some of your comments on my Blog and out on 
http://fedoraproject.org/wiki/SELinux

I have better understanding of this now.

selinux prelink avc's (broken paths in policy?)

[Paul Howarth]

Christopher Ashworth wrote:
>  On Wed, 2006-05-24 at 16:06 +0100, Paul Howarth wrote:
> > Christopher Ashworth wrote:
> >> On Wed, 2006-05-24 at 15:22 +0100, Paul Howarth wrote:
> >>
> >>> Is the sorting algorithm documented somewhere (the wiki?)?
> >> The sorting algorithm is based on the following heuristics, applied in
> >> this order:
> >>
> >> When comparing two file contexts A and B...
> >>
> >> - if A is a regular expression and B is not, A is less specific than B
> >> - if A's stem length (the number of characters before the first regular
> >> expression wildcard) is shorter than B's stem length, A is less specific
> >> than B
> >> - if A's string length (the entire length of the file context string) is
> >> shorter than B's string length, A is less specific than B
> >> - if A does not have a specified type and B does, A is less specific
> >> than B.
> >> - else, they are considered equally specific.
> > If there are two or more equally specific matches, is one picked at random?
> >
> > Paul.
>  
>  The sort is stable, so the order of the original file contexts is
>  maintained. The result is a list of all the file contexts sorted from
>  least specific to most specific.
>  
>  When assigning the file contexts, the list is consulted in order of most
>  to least specific.  The first match wins.  If there were two contexts
>  that are considered equally specific, the original order given by the
>  author will determine which one wins. 
So in other words, in the event of a tie, the one nearest the bottom of 
the list (in the file_contexts file or the output of "semanage fcontext 
-l") is determined to be the most specific and that one wins. Is that right?

Paul.

selinux prelink avc's (broken paths in policy?)

[Christopher Ashworth]

On Wed, 2006-05-24 at 16:20 +0100, Paul Howarth wrote:

>  So in other words, in the event of a tie, the one nearest the bottom
> of 
>  the list (in the file_contexts file or the output of "semanage fcontext 
>  -l") is determined to be the most specific and that one wins. Is that right? 
When I do "semanage fcontext -l" I don't get an ordered listing (so this
does not appear to be correct in that case), but yes, this is correct
for the file_contexts file. 

It would be ideal to make the algorithm do a proper sort based on strict
regular expression subsets, but this is non-trivial and these heuristics
work pretty well.

Chris

selinux prelink avc's (broken paths in policy?)

[Paul Howarth]

Christopher Ashworth wrote:
>  On Wed, 2006-05-24 at 16:20 +0100, Paul Howarth wrote:
>  
> > So in other words, in the event of a tie, the one nearest the bottom of 
> > the list (in the file_contexts file or the output of "semanage fcontext 
> > -l") is determined to be the most specific and that one wins. Is that right?
>  
>  When I do "semanage fcontext -l" I don't get an ordered listing (so this
>  does not appear to be correct in that case), but yes, this is correct
>  for the file_contexts file. 
>  
>  It would be ideal to make the algorithm do a proper sort based on strict
>  regular expression subsets, but this is non-trivial and these heuristics
>  work pretty well. 
So if "semanage fcontext -l" doesn't produce an ordered listing, is 
there any way from userland to get one, one that encompasses both the 
base policy and any added modules or context objects added using semanage?

I take it as read that semanage-added objects and the file contexts from 
policy module packages (.pp files) are seen as "later" in the list than 
the base file_contexts file, but which has precedence for 
semanage/semodule? Last one in? Does it make a difference whether 
"semodule -i" or "semodule -u" are used?

Paul.

selinux prelink avc's (broken paths in policy?)

[Christopher Ashworth]

On Wed, 2006-05-24 at 16:38 +0100, Paul Howarth wrote:
>  So if "semanage fcontext -l" doesn't produce an ordered
> listing, is 
>  there any way from userland to get one, one that encompasses both the 
>  base policy and any added modules or context objects added using semanage? 
I don't know the definitive answer on a userland tool.  semanage
fcontext -l appears to just be calling libsemanage, which is in turn
using Ivan's database functions to list the objects (in this case, the
fcontext objects).  I'll try to track down what happens between the
file_contexts file and the listing.

>  I take it as read that semanage-added objects and the file contexts
> from 
>  policy module packages (.pp files) are seen as "later" in the list than 
>  the base file_contexts file, but which has precedence for 
>  semanage/semodule? Last one in? Does it make a difference whether 
>  "semodule -i" or "semodule -u" are used? 
When semanage_direct_commit is invoked in libsemanage, the following
things happen:

 - any modules are linked to the base module
 - the file contexts in the linked base are sorted
 - the file contexts are split into the file_contexts file and the other
template files, and written to disk (well, to the sandbox, which is then
loaded in a separate step)
 - any semanage-added "database" objects are then merged

Thus, all fcontexts in the linked base (i.e. any fcontext associated
with a module) are sorted together.  The semanage-added objects are done
last, outside of the module sorting, and so would have precedence, as I
understand it.  The database code is a little opaque and not well
documented, so there may be some subtlety I'm missing as to how the
database objects are merged, but this is my current understanding.

Chris

selinux prelink avc's (broken paths in policy?)

[Paul Howarth]

Christopher Ashworth wrote:
>  On Wed, 2006-05-24 at 16:38 +0100, Paul Howarth wrote:
> > So if "semanage fcontext -l" doesn't produce an ordered listing, is 
> > there any way from userland to get one, one that encompasses both the 
> > base policy and any added modules or context objects added using semanage?
>  
>  I don't know the definitive answer on a userland tool.  semanage
>  fcontext -l appears to just be calling libsemanage, which is in turn
>  using Ivan's database functions to list the objects (in this case, the
>  fcontext objects).  I'll try to track down what happens between the
>  file_contexts file and the listing.
>  
> > I take it as read that semanage-added objects and the file contexts from 
> > policy module packages (.pp files) are seen as "later" in the list than 
> > the base file_contexts file, but which has precedence for 
> > semanage/semodule? Last one in? Does it make a difference whether 
> > "semodule -i" or "semodule -u" are used?
>  
>  When semanage_direct_commit is invoked in libsemanage, the following
>  things happen:
>  
>   - any modules are linked to the base module
>   - the file contexts in the linked base are sorted
>   - the file contexts are split into the file_contexts file and the other
>  template files, and written to disk (well, to the sandbox, which is then
>  loaded in a separate step)
>   - any semanage-added "database" objects are then merged
>  
>  Thus, all fcontexts in the linked base (i.e. any fcontext associated
>  with a module) are sorted together.  The semanage-added objects are done
>  last, outside of the module sorting, and so would have precedence, as I
>  understand it.  The database code is a little opaque and not well
>  documented, so there may be some subtlety I'm missing as to how the
>  database objects are merged, but this is my current understanding. 
I think the best policy, for the avoidance of confusion for people 
writing policy modules or calling semanage in rpm post-install scripts, 
is to encourage them to use strings that will sort as "more specific", 
i.e. avoid metacharacters if possible, and if not, use as long a stem as 
possible. This probably means having two separate entries for things 
that will go under /lib or /lib64, rather than the current idiom of 
/lib(64)?, which has a metacharacter very early in the string.

Paul.

selinux prelink avc's (broken paths in policy?)

[Stephen Smalley]

On Wed, 2006-05-24 at 18:04 +0100, Paul Howarth wrote:
>  I think the best policy, for the avoidance of confusion for people 
>  writing policy modules or calling semanage in rpm post-install scripts, 
>  is to encourage them to use strings that will sort as "more specific", 
>  i.e. avoid metacharacters if possible, and if not, use as long a stem as 
>  possible. This probably means having two separate entries for things 
>  that will go under /lib or /lib64, rather than the current idiom of 
>  /lib(64)?, which has a metacharacter very early in the string. 
Yes, this would be desirable even in the base policy module.

-- 
Stephen Smalley
National Security Agency

selinux prelink avc's (broken paths in policy?)

[Paul Howarth]

Stephen Smalley wrote:
>  On Wed, 2006-05-24 at 18:04 +0100, Paul Howarth wrote:
> > I think the best policy, for the avoidance of confusion for people 
> > writing policy modules or calling semanage in rpm post-install scripts, 
> > is to encourage them to use strings that will sort as "more specific", 
> > i.e. avoid metacharacters if possible, and if not, use as long a stem as 
> > possible. This probably means having two separate entries for things 
> > that will go under /lib or /lib64, rather than the current idiom of 
> > /lib(64)?, which has a metacharacter very early in the string.
>  
>  Yes, this would be desirable even in the base policy module. 
Yes, and it explains why in the earlier thread "Re: unconfined_execmem_t 
for /usr/lib/jvm/java-1.5.0-sun-1.5.0.06/jre/bin/java ?" we had 
/usr/lib/jvm/java-1.5.0-sun-1.5.0.06/jre/bin/java labelled as bin_t 
rather than java_exec_t with the following file context entries in the 
base policy:

/usr/lib(.*/)?bin/java([^/]*)?     regular file 
system_u:object_r:java_exec_t:s0
/usr/lib/jvm/java.*/bin/.*         all files 
system_u:object_r:bin_t:s0

Paul.

selinux prelink avc's (broken paths in policy?)

[Christopher Ashworth]

On Wed, 2006-05-24 at 12:56 -0400, Christopher Ashworth wrote:
>  On Wed, 2006-05-24 at 16:38 +0100, Paul Howarth wrote:
>  > So if "semanage fcontext -l" doesn't produce an ordered listing, is 
>  > there any way from userland to get one, one that encompasses both the 
>  > base policy and any added modules or context objects added using semanage?
>  
>  I don't know the definitive answer on a userland tool.  semanage
>  fcontext -l appears to just be calling libsemanage, which is in turn
>  using Ivan's database functions to list the objects (in this case, the
>  fcontext objects).  I'll try to track down what happens between the
>  file_contexts file and the listing. 
I had a chance to take another look at this this morning.  

In semanage (seobject.py, specifically), the list of file contexts being
retrieved via semanage_fcontext_list is in the correct order.  However,
it is transfered to a dictionary and printed out by iterating over the
keys of the dictionary.

Changing this will allow semanage to report the file contexts in the
original order.

Christopher

selinux prelink avc's (broken paths in policy?)

[Daniel J Walsh]

Christopher Ashworth wrote:
>  On Wed, 2006-05-24 at 12:56 -0400, Christopher Ashworth wrote:
>    
> > On Wed, 2006-05-24 at 16:38 +0100, Paul Howarth wrote:
> >     
> >> So if "semanage fcontext -l" doesn't produce an ordered listing, is
>
> >> there any way from userland to get one, one that encompasses both the 
> >> base policy and any added modules or context objects added using semanage?
> >>       
> > I don't know the definitive answer on a userland tool.  semanage
> > fcontext -l appears to just be calling libsemanage, which is in turn
> > using Ivan's database functions to list the objects (in this case, the
> > fcontext objects).  I'll try to track down what happens between the
> > file_contexts file and the listing.
> >     
>
>  I had a chance to take another look at this this morning.  
>
>  In semanage (seobject.py, specifically), the list of file contexts being
>  retrieved via semanage_fcontext_list is in the correct order.  However,
>  it is transfered to a dictionary and printed out by iterating over the
>  keys of the dictionary.
>
>  Changing this will allow semanage to report the file contexts in the
>  original order.
>
>  Christopher
>     
Ok I updated policycoreutils to use a list instead of a dictionary so 
the order is maintained.

selinux prelink avc's (broken paths in policy?)

[Paul Howarth]

Christopher Ashworth wrote:
>  On Wed, 2006-05-24 at 15:22 +0100, Paul Howarth wrote:
>  
> > Is the sorting algorithm documented somewhere (the wiki?)?
>  
>  The sorting algorithm is based on the following heuristics, applied in
>  this order:
>  
>  When comparing two file contexts A and B...
>  
>  - if A is a regular expression and B is not, A is less specific than B
>  - if A's stem length (the number of characters before the first regular
>  expression wildcard) is shorter than B's stem length, A is less specific
>  than B
>  - if A's string length (the entire length of the file context string) is
>  shorter than B's string length, A is less specific than B
>  - if A does not have a specified type and B does, A is less specific
>  than B.
>  - else, they are considered equally specific.
>  
>  These are the same heuristics applied to file contexts when building
>  reference policy.  
>  
>  The sort is implemented as a stable iterative mergesort. 
Thanks - I added this to the wiki:
http://fedoraproject.org/wiki/SELinux/ManagingFileContext

I suspect that Dan is currently writing a new page:
http://fedoraproject.org/wiki/SELinux/FileContext

Paul.