Fresh rawhide install / AVC messages

Dax Kelson dax at gurulabs.com
Wed Mar 10 08:19:39 UTC 2004


On Wed, 10 Mar 2004, Russell Coker wrote:

> On Wed, 10 Mar 2004 04:45, Dax Kelson <dax at gurulabs.com> wrote:
> > On the first boot, I got the following AVC messages. Is enforcing mode
> > expected to work? Is this helpful?
> 
> This is helpful!

Great! I'm still trying to wrap my brain around all this, so hopefully
I'll be able to provide actual fixes--rather than just information--in the
future.

I think a fair amount of these were triggered from RH's "firstboot"  
program that does some post-install tasks on the first boot (surprise
surprise) of a freshly installed system.

I have made no custom changes to my box at this point.

> I have attached a first cut at cpuspeed policy, it won't work but if you try 
> it out I'll get more information and be able to write more policy.  What is 
> the full path name for this scaling_governor file?

/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Tomorrow I'll see if I can try it out.
 
> > audit(1078849148.792:0): avc:  denied  { getattr } for 
> > pid=1141 exe=/bin/bash path=/etc/ntp.conf dev=hda8 ino=19690
> > scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:ntpd_etc_t
> > tclass=file audit(1078849148.796:0): avc:  denied  { rename } for  pid=1160
> > exe=/bin/mv name=ntp.conf dev=hda8 ino=19690
> > scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:ntpd_etc_t
> > tclass=file audit(1078849148.797:0): avc:  denied  { getattr } for 
> > pid=1161 exe=/bin/bash path=/tmp dev=hda8 ino=588673
> 
> This is a problem.  Is this standard functionality of the dhcp client or have 
> you written your own scripts?

This is standard behavior on RHL8.0 and above if the DHCP server sends the
'time-server' options. I don't know off hand if it is RH specific or stock 
dhclient.

> The problem we face is that the dhcp client as a standard function will 
> replace /etc/resolv.conf.  The /etc/resolv.conf file is given the type 
> resolv_conf_t because so many programs want to re-write it.
> 
> Now we can give the ntpd config file the same type.  But in that case we will 
> probably want to rename it to net_conf_t or something.
> 
> This is all conditional on this being standard functionality of the dhcp 
> client.  If it's your customisation then you can just change ntpd.fc to label 
> the file as resolv_conf_t.  Although I suspect that if this is a 
> customisation of yours it'll become a standard thing soon enough, it sounds 
> like a good idea!

net_conf_t sounds good. I'd imagine we are going to encouter other cases 
besides resolv.conf and ntp.conf.

> > tclass=dir audit(1078849148.798:0): avc:  denied  { search } for  pid=1161
> > exe=/bin/bash name=tmp dev=hda8 ino=588673
> > scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:tmp_t
> > tclass=dir audit(1078849148.798:0): avc:  denied  { write } for  pid=1161
> > exe=/bin/bash name=tmp dev=hda8 ino=588673
> > scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:tmp_t
> > tclass=dir audit(1078849148.798:0): avc:  denied  { add_name } for 
> > pid=1161 exe=/bin/bash name=sh-thd-1078853309
> 
> What is this for?  The following is the policy needed to address that.  If 
> it's a standard thing then I'll put it in my policy tree.
> 
> tmp_domain(dhcpc)

I don't know, what's it doing? :)

It is a standard thing as I've made no custom changes.

> > audit(1078849246.286:0): avc:  denied  { create } for  pid=4526
> > exe=/usr/bin/python key=0 scontext=system_u:system_r:initrc_t
> > tcontext=system_u:system_r:initrc_t tclass=shm audit(1078849246.286:0):
> > avc:  denied  { unix_read unix_write } for  pid=4526 exe=/usr/bin/python
> > key=0 scontext=system_u:system_r:initrc_t
> > tcontext=system_u:system_r:initrc_t tclass=shm audit(1078849246.286:0):
> > avc:  denied  { read write } for  pid=4526 exe=/usr/bin/python key=0
> > scontext=system_u:system_r:initrc_t tcontext=system_u:system_r:initrc_t
> > tclass=shm
> 
> Any idea what this program is?

Maybe it is firstboot.
 
Dax Kelson




More information about the fedora-selinux-list mailing list