Worrying AVC messages

[Anne Wilson]

On Monday 22 January 2007 19:40, Stephen Smalley wrote:
> On Mon, 2007-01-22 at 18:59 +0000, Anne Wilson wrote:
> > On Monday 22 January 2007 14:49, you wrote:
> >
> > Hi, Stephen.  I'm very new to all this, so bear with me if I don't give
> > you the right info first try :-)
>
> Why take discussion off-list?
>
Sorry - not intentional.  A new folder in KMail, and I forgot to set up 
Mailing List Management.

> > > You don't seem to have included the scontext, tcontext, and tclass
> > > information, which is the real basis for the permission denial.
> > >
> > > You can also get supplemental information about each avc denial by
> > > enabling system call auditing.  Requires installing "audit" and adding
> > > at least one audit rule to enable collection of the full audit context.
> > > This will provide you with information like the system call number and
> > > arguments, the path that has been looked up, etc.
> >
> > I have audit.log and I get logwatch messages, so I think audit is working
> > properly.  Where do I look to see if rules have been made?  They would
> > probably be defaults, as I'm sure I haven't made any myself.
>
> /sbin/auditctl -l will list any rules.  auditctl man page will show you
> some examples of rules, which you can apply manually via auditctl or by
> putting into /etc/audit/audit.rules and re-starting auditd.  Any rule
> will suffice, as the goal is just to get the audit system to start
> collecting information for use when an avc message happens; it used to
> always do that proactively, but that caused performance issues, so they
> disabled it when there are no audit rules in place.
>
Fine.  I'll see what I can do with this.

> > Is this the kind of info you need?
> >
> > type=AVC msg=audit(1162463326.809:49): avc:  denied  { search } for 
> > pid=4186 comm="postmap" name="nscd" dev=hdb1 ino=195773
> > scontext=user_u:system_r:postfix_map_t:s0
> > tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir
> > type=SYSCALL msg=audit(1162463326.809:49): arch=40000003 syscall=102
> > success=no exit=-2 a0=3 a1=bf915688 a2=67eff4 a3=4 items=0 ppid=4147
> > pid=4186 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> > tty=pts5 comm="postmap" exe="/usr/sbin/postmap"
> > subj=user_u:system_r:postfix_map_t:s0 key=(null)
>
> Yes, that shows the security contexts of the source (process) and the
> target (in this case, a directory).  audit2allow will turn those
> messages into allow rules, e.g.
> 	su -
> 	audit2allow -a -M local
> 	semodule -i local.pp
>
Examples are always helpful :-)

> > type=AVC msg=audit(1169487905.785:178): avc:  denied  { read } for 
> > pid=2965 comm="hald-addon-stor" name="hdc" dev=tmpfs ino=7065
> > scontext=system_u:system_r:hald_t:s0
> > tcontext=system_u:object_r:device_t:s0 tclass=blk_file
> > type=SYSCALL msg=audit(1169487905.785:178): arch=40000003 syscall=5
> > success=yes exit=4 a0=96e1ac6 a1=8880 a2=0 a3=8880 items=0 ppid=2940
> > pid=2965 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> > fsgid=0 tty=(none) comm="hald-addon-stor"
> > exe="/usr/libexec/hald-addon-storage" subj=system_u:system_r:hald_t:s0
> > key=(null)
>
> Question on this one is why this device node has a generic type
> (device_t) rather than a specific one (e.g. removable_device_t).
>
I suspect that this is my video capture card, a pci card for use with an 
analogue camcorder.  I had been trying to write udev rules to track video0 
and video1, so that webcam and camcorder capture could always be found.  The 
device is listed currently under video1.  Udevinfo doesn't walk the sys tree 
for this card, the way it does for the webcam.  Perhaps that's part of the 
puzzle?

> > type=AVC msg=audit(1169489443.261:186): avc:  denied  { read } for 
> > pid=4482 comm="smartd" name="hda" dev=tmpfs ino=879
> > scontext=system_u:system_r:fsdaemon_t:s0
> > tcontext=system_u:object_r:device_t:s0 tclass=blk_file
> > type=SYSCALL msg=audit(1169489443.261:186): arch=40000003 syscall=5
> > success=yes exit=3 a0=99c60a0 a1=800 a2=c3c490 a3=c42cae items=0 ppid=1
> > pid=4482 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> > fsgid=0 tty=(none) comm="smartd" exe="/usr/sbin/smartd"
> > subj=system_u:system_r:fsdaemon_t:s0 key=(null)
>
> Likewise.
>
This I don't understand.  I've seen messages like this for hdb as well.  They 
are standard hdds.

> > > audit2allow can be used to generate a local policy module to allow
> > > permissions as appropriate; see its man page and the Fedora SELinux
> > > FAQ.
> >

Thanks for the help so far.  I'll catch up on the reading.

Anne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20070122/887962a2/attachment.sig>