On Tue, 2008-05-27 at 11:59 -0400, Eric Paris wrote:
...
> ----
> type=SOCKADDR msg=audit(05/27/2008 10:30:22.163:13193) : saddr=inet
> host:0.0.0.0 serv:711
> type=SYSCALL msg=audit(05/27/2008 10:30:22.163:13193) : arch=x86_64
> syscall=bind success=yes exit=0 a0=5 a1=7fff63dbb220 a2=10 a3=89ea70
> items=0 ppid=1 pid=2647 auid=unset uid=root gid=root euid=root suid=root
> fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=4294967295
> comm=rpc.rquotad exe=/usr/sbin/rpc.rquotad
> subj=system_u:system_r:initrc_t:s0-s15:c0.c1023 key=(null)
> type=AVC msg=audit(05/27/2008 10:30:22.163:13193) : avc: denied
> { name_bind } for pid=2647 comm=rpc.rquotad src=711
> scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023
> tcontext=system_u:object_r:hi_reserved_port_t:s0 tclass=udp_socket
>
> Is the host "0.0.0.0" field here a bug?
Isn't this telling up that they are calling bind on any interface not a
specific address?
the const struct sockaddr *addr part of the bind(2) call is IN_ADDRANY
what whatever the semantics are...
-Eric
I understand; thanks.
Semantically this is probably the intended use of the "host" field.
When audit data is examined on one host this isn't a problem. But when
aggregated with other host audit data, this record as standalone is
indistinguishable from a similar one on a different host ... unless I'm
missing something in the above record.
Or if we separate the aggregated data by filename/whatever which the
search tools can use to differentiate audit hosts.
Thx,
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com