On Tue, 2007-03-13 at 16:38 -0400, Mike Edenfield wrote:
> Chris PeBenito wrote:
> > On Tue, 2007-03-06 at 15:33 -0500, Mike Edenfield wrote:
> 
> > Sorry for the slow response.  These messages are likely due to the
> > static device nodes under a udev /dev.
[cut]
> Thanks for this, and also to the person who wrote the 
> previous reply recommending a static /dev.  (I meant to 
> reply sooner but have been on vacation).  This actually 
> eliminated a big chunk of my problems.
> 
> I'm still hoping someone can point me to a more general 
> tutorial on troubleshooting these types of errors.  Now that 
> I'm trying to get actual services running on the system, I'm 
> obviously having more of them, and I don't want to waste 
> this list's time trying to explain every one of them to me 
> :x  Things like this (two of which I assume are being 
> generated because I'm running dhcpcd on this machine at boot):
> 
> Mar 13 06:39:09 [kernel] audit(1173782339.840:57): avc: 
> denied  { write } for  pid=2775 comm="runscript.sh" 
> name="resolv.conf" dev=hda3 ino=1556987 
> scontext=system_u:system_r:initrc_t 
> tcontext=system_u:object_r:net_conf_t tclass=file
> 
> Mar 13 06:39:09 [kernel] audit(1173782339.850:58): avc: 
> denied  { setattr } for  pid=2989 comm="chmod" 
> name="resolv.conf" dev=hda3 ino=1556987 
> scontext=system_u:system_r:initrc_t 
> tcontext=system_u:object_r:net_conf_t tclass=file
> 
> Mar 13 06:39:09 [kernel] audit(1173782348.950:59): avc: 
> denied  { ptrace } for  pid=4000 comm="pidof" 
> scontext=system_u:system_r:initrc_t 
> tcontext=system_u:system_r:init_t tclass=process
> 
> Mar 13 06:39:09 [kernel] audit(1173782348.950:60): avc: 
> denied  { ptrace } for  pid=4000 comm="pidof" 
> scontext=system_u:system_r:initrc_t 
> tcontext=system_u:system_r:kernel_t tclass=process
> 
> Obviously, I can get rid of these by adding rules like this:
> 
> allow initrc_t init_t:process ptrace;
> allow initrc_t kernel_t:process ptrace;
> allow initrc_t net_conf_t:file { setattr write };
> 
> My question is more theoretical, that is, is there a reason 
> why those rules aren't *already* there?

I can't really make general statements about this.  It depends on many
factors.  Sometimes its a due to a new feature of a package that the
policy does not yet account for.  Sometimes checks are added/changed.
Sometimes its simply a feature or error path that hasn't been covered
yet.  The pidof ptrace denials are an example of a check being added.

> Is it normal to have to tweak the policy files right out of the box,
> or after installing a new ebuild, and I should feel "ok" with doing
> it?

The hope is that it should work out of the box.  Since its impossible
for us to anticipate all possible conditions or maybe non-standard file
locations, a couple may pop up.

> Or does it point to a bigger problem with my install that I messed up
> and need to fix?

If those are the only denials you are receiving, I'd say you're in
pretty good shape.

I suspect that the ptrace denials can be dontaudited, i.e.

dontaudit initrc_t init_t:process ptrace;
dontaudit initrc_t kernel_t:process ptrace;

It would be nice to find out more specifically what is going on with the
other two denials, but I suspect that it will be ok to allow.  I use
dhcpcd on my server, but don't see this problem.

-- 
Chris PeBenito
<[EMAIL PROTECTED]>
Developer,
Hardened Gentoo Linux
 
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to