Re: Incorrect avc logs for the packet object class

[Paul Moore <paul.moore@hp.com>]

On Thursday 21 May 2009 10:14:40 am Stephen Smalley wrote:
> On Wed, 2009-05-20 at 13:23 -0400, Marshall Miller wrote:
> > I first noticed this bug on a RHEL 5 system, and I also noticed it on
> > Ubuntu Jaunty.  I tested this out on Fedora 11 Preview and it was there
> > also.
> >
> > The avc messages for the packet object class sporadically report
> > incorrect comm/pid info.  It is most apparent when multiple processes
> > are sending/receiving packets at the same time.  To demonstrate this, I
> > added an iptables rule such that every packet being sent is labeled
> > system_u:object_r:dns_client_packet_t:s0 (arbitrarily chosen from
> > existing types).  I then created and inserted a module that auditallows
> > all packet perms for subj == domain and obj == dns_client_packet_t.
> > Then I started the Software Updater, and when it started downloading
> > packages I ran firefox.
>
> This has always been an issue for the low level networking permission
> checks that may happen outside of process context; unfortunately,
> "current" is still defined in that situation and thus avc_audit() cannot
> distinguish the cases where it has a relevant process context from these
> situations.  Options for fixing:
> - Have the callers of avc_has_perm() pass a flag (e.g. via
> avc_audit_data) when no relevant process context is available, and use
> that flag within avc_audit() to omit the comm= and pid= information and
> to pass a NULL audit_context to audit_log_start().
> - Have avc_audit() internally check for certain classes and permissions
> (e.g. SECCLASS_PACKET, SECCLASS_PEER, SECCLASS_NETIF, SECCLASS_NODE)
> known to have this behavior, and likewise omit the comm= and pid=
> information and pass a NULL context to audit_log_start() in that case.
> Concern with this approach is that a given class/permission may be used
> from multiple call sites, some of which may have a valid process context
> and some of which may not.

For the reasons that Stephen pointed out as well as a concern that it would be 
harder to maintain (we would likely forget to add new classes in the future 
should they arise) I vote for the first flag-passing approach.  It should be a 
relatively small patch; if I don't hear any objections I'll start working on 
it on in the next day or two ... I would think we should be able to still get 
this into 2.6.30.

-- 
paul moore
linux @ hp


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.