4:41 p.m.
* Ondrej Zary (linux(a)rainbow-software.org) wrote:
This patch moves the "name=" field to the end of audit
records. The
original placement is bad because it cannot be properly parsed. It is
impossible to tell if the name is "/bin/true" or "/bin/true inode=469634
dev=00:00" because the "inode=" and "dev=" fields can be
omitted.
Before:
audit(1111008486.824:89346): item=0 name=/bin/true inode=469634 dev=00:00
After:
audit(1111008486.824:89346): item=0 inode=469634 dev=00:00 name=/bin/true
Signed-off-by: Ondrej Zary <linux(a)rainbow-software.org>
Looks reasonable. Thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
8:25 p.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
On Wed, 2005-03-16 at 14:41 -0800, Chris Wright wrote:
* Ondrej Zary (linux(a)rainbow-software.org) wrote:
> This patch moves the "name=" field to the end of audit records. The
> original placement is bad because it cannot be properly parsed. It is
> impossible to tell if the name is "/bin/true" or "/bin/true
inode=469634
> dev=00:00" because the "inode=" and "dev=" fields can be
omitted.
Consider:
open("/bin/true\naudit(1111008484.824:89346): ...", O_RDONLY);
I don't think this patch is enough -- either we need to escape the text
completely or just dump it as hex instead of a string. One option would
be to dump it in quotes as a string if all chars in the string are in
the range 0x20-0x7e, and as hex otherwise. That slightly complicates the
parsing, but not by much, and still gives you plain text in the majority
of cases while protecting against abuse.
--
dwmw2
11:57 a.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
* David Woodhouse (dwmw2(a)infradead.org) wrote:
On Wed, 2005-03-16 at 14:41 -0800, Chris Wright wrote:
> * Ondrej Zary (linux(a)rainbow-software.org) wrote:
> > This patch moves the "name=" field to the end of audit records. The
> > original placement is bad because it cannot be properly parsed. It is
> > impossible to tell if the name is "/bin/true" or "/bin/true
inode=469634
> > dev=00:00" because the "inode=" and "dev=" fields can
be omitted.
Consider:
open("/bin/true\naudit(1111008484.824:89346): ...", O_RDONLY);
I don't think this patch is enough -- either we need to escape the text
completely or just dump it as hex instead of a string. One option would
be to dump it in quotes as a string if all chars in the string are in
the range 0x20-0x7e, and as hex otherwise. That slightly complicates the
parsing, but not by much, and still gives you plain text in the majority
of cases while protecting against abuse.
Yes good point. I don't have a strong preference. Steve, are you
working on processing log data, do you have a preference?
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
12:08 p.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
I don't think this patch is enough -- either we need to escape
the text
completely or just dump it as hex instead of a string. One option would
be to dump it in quotes as a string if all chars in the string are in
the range 0x20-0x7e, and as hex otherwise. That slightly complicates the
parsing, but not by much, and still gives you plain text in the majority
of cases while protecting against abuse.
Dumping in hex instead of string would have a testing impact. Using a
string in quotes would be a
smaller hit, but there still would be additional impact to test the "hex
otherwise" case.
Kris Wilson
Linux Security
(512) 838-0126 T/L:678-0126
krisw(a)us.ibm.com
12:22 p.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
On Thu, 2005-03-17 at 12:08 -0600, Kris Wilson wrote:
<br>Dumping in hex instead of string would have a testing
impact.
Using a string in quotes would be a<br>smaller hit, but there still
would be additional impact to test the "hex otherwise" case.
<br><br><br>
A string in quotes isn't sufficient -- a file name can contain quotes as
well as carriage returns. The only safe option is hex -- it's just a
question of whether it's "string or fall back to hex if dangerous" or
whether it's "just hex".
--
dwmw2
12:30 p.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
* Kris Wilson (krisw(a)us.ibm.com) wrote:
> I don't think this patch is enough -- either we need to
escape the text
> completely or just dump it as hex instead of a string. One option would
> be to dump it in quotes as a string if all chars in the string are in
> the range 0x20-0x7e, and as hex otherwise. That slightly complicates the
> parsing, but not by much, and still gives you plain text in the majority
> of cases while protecting against abuse.
Dumping in hex instead of string would have a testing impact. Using a
string in quotes would be a
smaller hit, but there still would be additional impact to test the "hex
otherwise" case.
We need to do something, as it is the data can't be trusted. It's a way
for user to possibly inject false audit messages. And most characters
are valid in pathnames.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
12:34 p.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
On Thursday 17 March 2005 12:30 pm, Chris Wright wrote:
* Kris Wilson (krisw(a)us.ibm.com) wrote:
> > I don't think this patch is enough -- either we need to escape the text
> > completely or just dump it as hex instead of a string. One option would
> > be to dump it in quotes as a string if all chars in the string are in
> > the range 0x20-0x7e, and as hex otherwise. That slightly complicates
> > the parsing, but not by much, and still gives you plain text in the
> > majority of cases while protecting against abuse.
>
> Dumping in hex instead of string would have a testing impact. Using a
> string in quotes would be a
> smaller hit, but there still would be additional impact to test the "hex
> otherwise" case.
We need to do something, as it is the data can't be trusted. It's a way
for user to possibly inject false audit messages. And most characters
are valid in pathnames.
thanks,
-chris
Let's rewrite Linux. J/K. But all jokes aside, can't we just log out the
length of the name= field with the rest of the record, ie: name_len=7
name=linux\n\0?
-tim
12:39 p.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
* Timothy R. Chavez (tinytim(a)us.ibm.com) wrote:
Let's rewrite Linux. J/K. But all jokes aside, can't we
just log out the
length of the name= field with the rest of the record, ie: name_len=7
name=linux\n\0?
That's what BSM does. But then, they do complete binary format.
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
1 p.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
On Thursday 17 March 2005 13:34, Timothy R. Chavez wrote:
name_len=7 name=linux\n\0?
This'll work, but I'd suggest nlen= That saves 4 bytes per message.
Another way to do the same thing would be name=7:linux\n\0 This gets the
length in it without adding another field.
-Steve
1:10 p.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
On Thu, 17 Mar 2005 14:00:03 EST, Steve Grubb said:
Another way to do the same thing would be name=7:linux\n\0 This gets
the
length in it without adding another field.
Consider:
name=7:f\007\007b
Is that "eff" "octal 7" "backslash zero zero seven bee", or
"eff backslash zero zero seven" "octal 7" "bee"?
We may have to bite the bullet and do a BSM-style binary format....
1:16 p.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
On Thursday 17 March 2005 14:10, Valdis.Kletnieks(a)vt.edu wrote:
name=7:f\007\007b
Is that "eff" "octal 7" "backslash zero zero seven bee",
or
"eff backslash zero zero seven" "octal 7" "bee"?
In this scheme, I don't think there would be any escaping. The next 7 bytes
are what it is.
-Steve
1:45 p.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
On Thu, Mar 17, 2005 at 10:30:24AM -0800, Chris Wright wrote:
We need to do something, as it is the data can't be trusted.
It's a way
for user to possibly inject false audit messages. And most characters
are valid in pathnames.
We had this discussion a couple of weeks ago when we were talking about a
parseable format for audit records, but I think we didn't reach a
consensus back then.
I had proposed back then to use backslash escaping for newline, tab,
single quotes, and backslashes, and octal escapes for control characters
- that's fairly unobtrusive for normal filenames. You could add quotes to
the list of escaped characters if the strings are printed as quoted
strings.
-Klaus
void
print_escaped_string(FILE *out, const char *txt)
{
for (;*txt;++txt) {
switch(*txt) {
case '\n':
putc('\\', out);
putc('n', out);
break;
case '\t':
putc('\\', out);
putc('t', out);
break;
case '\'':
case '\\':
putc('\\', out);
putc(*txt, out);
break;
default:
if (*txt<32) {
fprintf(out, "\\%03o", *txt);
} else {
putc(*txt, out);
}
}
}
}
12:37 p.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
On Thursday 17 March 2005 12:57, Chris Wright wrote:
Steve, are you working on processing log data, do you have a
preference?
Yes, I am working on a utility to process the data. I have 4 comments:
1) Fields that magically appear and dissappear are problematic for fast
parsing.
2) There should be a way to control what fields the kernel emits. The
dissappearing fields are what I take to be a stab at message compression. By
having a mask driven approach and always emitting those fields, we can parse
faster and have compression.
3) Fields that potentially have a space, tab, or carriage return in them need
escaping or quoting if they are sent in human readable format.
4) There should be a mode/format status variable so that in the future we can
tell the kernel to switch to another (binary) format. This way human readable
records can go to syslog and special apps like the audit daemon can switch to
another format (binary data ?) which might be more efficient. I haven't spent
anytime looking at what makes sense for a binary format, nor do we have time
for that right now. But I'd like to look at that in the future.
-Steve Grubb
1:59 p.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
Steve & Debora where cooperating on audit library functions to
handle this issue: text formatting, string escape and so on.
Can this work be resurrected? Now that Debora can contribute the code.
Mounir Bsaibes
Linux Security
Tel: (512) 838-1301
Cell: (512) 762-9957
Fax: (512) 838-8858
e-mail: bsaibes(a)us.ibm.com
linux-audit-bounces(a)redhat.com wrote on 03/17/2005 11:57:03 AM:
* David Woodhouse (dwmw2(a)infradead.org) wrote:
> On Wed, 2005-03-16 at 14:41 -0800, Chris Wright wrote:
> > * Ondrej Zary (linux(a)rainbow-software.org) wrote:
> > > This patch moves the "name=" field to the end of audit records.
The
> > > original placement is bad because it cannot be
properly parsed. It
is
> > > impossible to tell if the name is
"/bin/true" or "/bin/true
inode=469634
> > > dev=00:00" because the "inode=" and "dev=" fields
can be omitted.
>
> Consider:
>
> open("/bin/true\naudit(1111008484.824:89346): ...", O_RDONLY);
>
> I don't think this patch is enough -- either we need to escape the
text
> completely or just dump it as hex instead of a string. One
option
would
> be to dump it in quotes as a string if all chars in the string
are in
> the range 0x20-0x7e, and as hex otherwise. That slightly complicates
the
> parsing, but not by much, and still gives you plain text in the
majority
> of cases while protecting against abuse.
Yes good point. I don't have a strong preference. Steve, are you
working on processing log data, do you have a preference?
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
2:12 p.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
On Thursday 17 March 2005 14:59, Mounir Bsaibes wrote:
Steve & Debora where cooperating on audit library functions to
handle this issue: text formatting, string escape and so on.
I think her code depended on sane text coming from the kernel. This needs
kernel side work so that user space can make sense of it. I think David
nearly has a patch for us to test.
-Steve
2:32 p.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
Mounir Bsaibes
Linux Security
Tel: (512) 838-1301
Cell: (512) 762-9957
Fax: (512) 838-8858
e-mail: bsaibes(a)us.ibm.com
Steve Grubb <sgrubb(a)redhat.com>
Sent by: linux-audit-bounces(a)redhat.com
03/17/2005 02:12 PM
Please respond to
Linux Audit Discussion
To
Linux Audit Discussion <linux-audit(a)redhat.com>
cc
Subject
Re: [patch] Syscall auditing - move "name=" field to the end
On Thursday 17 March 2005 14:59, Mounir Bsaibes wrote:
Steve & Debora where cooperating on audit library functions to
handle this issue: text formatting, string escape and so on.
I think her code depended on sane text coming from the kernel. This needs
kernel side work so that user space can make sense of it. I think David
nearly has a patch for us to test.
Will Debora's patch make it to audit-0.6.9, or audit-0.7 ?
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
2:53 p.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
On Thursday 17 March 2005 15:32, Mounir Bsaibes wrote:
Will Debora's patch make it to audit-0.6.9, or audit-0.7 ?
I haven't planned on it. The issue is that if you have a formatter, you need
to have a parser to read it back. I'm just planning to dump it straight to
logs and parse it as is.
-Steve
3:18 p.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
* Mounir Bsaibes (bsaibes(a)us.ibm.com) wrote:
Mounir Bsaibes
Linux Security
Tel: (512) 838-1301
Cell: (512) 762-9957
Fax: (512) 838-8858
e-mail: bsaibes(a)us.ibm.com
Steve Grubb <sgrubb(a)redhat.com>
Sent by: linux-audit-bounces(a)redhat.com
03/17/2005 02:12 PM
Please respond to
Linux Audit Discussion
To
Linux Audit Discussion <linux-audit(a)redhat.com>
cc
Subject
Re: [patch] Syscall auditing - move "name=" field to the end
On Thursday 17 March 2005 14:59, Mounir Bsaibes wrote:
> Steve & Debora where cooperating on audit library functions to
> handle this issue: text formatting, string escape and so on.
I think her code depended on sane text coming from the kernel. This needs
kernel side work so that user space can make sense of it. I think David
nearly has a patch for us to test.
Will Debora's patch make it to audit-0.6.9, or audit-0.7 ?
-Steve
Not to be a grumpy netiquette type, but could we please get some sane
email text here? It's a real pain to parse some of these messages.
I assume it's Lotus Notes, I've seen it from other IBM accounts.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
4:21 p.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
On Thu, 2005-03-17 at 13:18 -0800, Chris Wright wrote:
Not to be a grumpy netiquette type, but could we please get some
sane
email text here? It's a real pain to parse some of these messages.
I assume it's Lotus Notes, I've seen it from other IBM accounts.
I have to agree -- this is just silly. Not to pick on Mounir, but these
two mails, for example, are almost impossible to make any sense of:
http://david.woodhou.se/notesmail.jpeg
http://david.woodhou.se/notesmail2.jpeg
Please, make sure that replies are given _below_ the quoted text. Quote
_only_ what is absolutely necessary for context. Make sure that
quotations are sufficiently obviously marked (prefixed with '> ' or
something similar), and don't use HTML. Oh, and make sure that line
wrapping is done sanely.
I've seen a bunch of bizarre graphical attachments too, which have
confused me somewhat. We can probably do without those.
--
dwmw2
1:22 p.m.
New subject: [patch] Syscall auditing - move "name=" field to the end
On Thu, 2005-03-17 at 02:25 +0000, David Woodhouse wrote:
Consider:
open("/bin/true\naudit(1111008484.824:89346): ...", O_RDONLY);
I don't think this patch is enough -- either we need to escape the text
completely or just dump it as hex instead of a string. One option would
be to dump it in quotes as a string if all chars in the string are in
the range 0x20-0x7e, and as hex otherwise. That slightly complicates the
parsing, but not by much, and still gives you plain text in the majority
of cases while protecting against abuse.
I think that the same issue exists for audit_log_d_path and portions of
avc_audit. Of course, hopefully portions of avc_audit, like the exe=
information, can be pushed into audit_log_exit and redundant information
(like pid=) can be removed from avc_audit and we can just mandate that
syscall auditing be enabled when SELinux is enabled. Not clear if
avc_audit() should then be converted to just adding to a list on the
audit context for later processing by audit_log_exit like
audit_notify_watch or if it should continue immediate generation of a
partial audit message with the SELinux information.
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency
7220
days inactive
7221
days old
linux-audit@lists.linux-audit.osci.io
19 comments
9 participants
participants (9)
-
Chris Wright -
David Woodhouse -
Klaus Weidner -
Kris Wilson -
Mounir Bsaibes -
Stephen Smalley -
Steve Grubb -
Timothy R. Chavez -
Valdis.Kletnieks＠vt.edu