From: Linda Knippers <linda.knippers@hp.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: Linux Audit <linux-audit@redhat.com>
Subject: Re: Bad bug in remote logging
Date: Mon, 11 Apr 2011 23:18:44 -0400 [thread overview]
Message-ID: <4DA3C494.2090909@hp.com> (raw)
In-Reply-To: <201104111900.47508.sgrubb@redhat.com>
Steve Grubb wrote:
> Hello,
>
> There was a bug reported to day that I think merits an email and/or discussion.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=695419
> =================================
> audisp-remote does
>> memset (&address, 0, sizeof(address));
>> address.sin_family = htons(AF_INET);
>> address.sin_port = htons(config.local_port);
>> address.sin_addr.s_addr = htonl(INADDR_ANY);
> which shows in strace as
>
>> bind(3, {sa_family=0x200 /* AF_??? */, sa_data="\0<\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) =
> 0
>
> For some reason the call still succeeds, but a correct invocation would not
> call htons on AF_INET.
Are you sure that that field is actually used by bind()? Doesn't the
socket also have the address family? Its surprising that the call would
succeed and even more surprising that the socket would work.
> ================================
>
> The reason it succeeds is because there is a matching mistake in auditd. So, what this
> means is that remote logging is not using IPv4, but something else.
What else would it be using? That value is greater than any legal
address family so I would think that lots of things in the kernel
would break.
> I committed a
> patch to fix this in trunk:
>
> https://fedorahosted.org/audit/changeset/505
>
> This would cause new systems and old systems to not be able to talk to one another.
> Regarding RHEL, remote logging has been tech preview, meaning that its alpha code and
> likely buggy but available so you can see where this is heading. So, I think we can
> just change it to be correct. For Fedora, there is no tech preview and everything is
> supported...but it has a short life. However, what the code was doing is clearly
> wrong. So, I am thinking to fix this all the way back to F-13 if I can. Regarding other
> distributions...not sure what the support status is or how they would like to choose
> to solve this. Anyone have any thoughts on this?
Your resolution seems ok if this is really more than a benign coding
problem.
-- ljk
>
> -Steve
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2011-04-12 3:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-11 23:00 Bad bug in remote logging Steve Grubb
2011-04-12 3:18 ` Linda Knippers [this message]
2011-04-12 7:23 ` Stephan Mueller
2011-04-12 13:09 ` Steve Grubb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DA3C494.2090909@hp.com \
--to=linda.knippers@hp.com \
--cc=linux-audit@redhat.com \
--cc=sgrubb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox