From: Eric Paris <eparis@redhat.com>
To: Etienne Basset <etienne.basset@numericable.fr>
Cc: linux-audit@redhat.com, jmorris@namei.org
Subject: Re: [Fwd: [PATCH][RFC] SMACK : add logging support V1]
Date: Wed, 01 Apr 2009 14:22:18 -0400 [thread overview]
Message-ID: <1238610138.14615.7.camel@localhost.localdomain> (raw)
In-Reply-To: <49D28EAC.1040604@numericable.fr>
On Tue, 2009-03-31 at 23:44 +0200, Etienne Basset wrote:
> Eric Paris wrote:
> > On Mon, 2009-03-30 at 20:30 +0200, Etienne Basset wrote:
> >>> I pretty strongly detest %s these days. Using it on the left side of an
> >>> = is ok if you are REALLY careful. Using it on the right makes me
> >>> cringe. Can smack labels have characters which are not ascii letters
> >>> (spaces?)
> >>>
> >> no, smack basically do the same tests when importing smack label than you do
> >> in kernel/audit.c:audit_string_contains_control
> >> except smack allows the '"' character
> >
> > How did you plan to handle a SMACK label with a ' ? Using the audit
> > string functions and being given a label with a " is going to give you
> > the hex output. (which might someday turn into better encoding, but I'm
> > still waiting to see some code to do it better)
> >
> hum, since smack labels cannot have special characters and are limited to length 24,
> maybe we could just do :
> subject=FOO object=BAR
> but it would imply using a "object=%s subject=%s"
>
> or using audit_log_untrustedstring and live with the fact that Labels with '"' will be
> printed in hex (i dont expect '"' to be frequently used in labels.)
Since it can contain a " you may not use %s. Just go with
audit_log_untrustedstring and hope people don't use a "
> > Can I suggest if you write userspace tools to do anything with these
> > audit records that you use libauparse? So if we do make changes, SMACK
> > tools keep working (this is the main problem with changing how SELinux
> > uses audit, the userspace tools don't use libauparse so we can't make
> > changes in just the kernel+library...)
> >
> i can have a look, but my first need is /var/log/messages being pretty obvious to read
The changes to string encoding and we want to do would actually make
records more human readable, so if that's your concern we are good.
But, if you ever make tools that parse the raw audit.log rather than
using libauparse it possible (likely?) they break someday down the line.
Don't forget these are going to show up in /var/log/audit/audit.log if
you have auditd running. They'll show up in dmesg/syslog if not.
Thanks for trying to share code between LSMs!
-Eric
next prev parent reply other threads:[~2009-04-01 18:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <49B3AB1A.8040201@numericable.fr>
2009-03-28 5:24 ` [Fwd: [PATCH][RFC] SMACK : add logging support V1] Casey Schaufler
2009-03-30 14:20 ` Eric Paris
[not found] ` <49D10FC5.4060504@numericable.fr>
2009-03-30 19:31 ` Eric Paris
[not found] ` <49D28EAC.1040604@numericable.fr>
2009-04-01 18:22 ` Eric Paris [this message]
2009-04-01 22:21 ` Casey Schaufler
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=1238610138.14615.7.camel@localhost.localdomain \
--to=eparis@redhat.com \
--cc=etienne.basset@numericable.fr \
--cc=jmorris@namei.org \
--cc=linux-audit@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