| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAHC9VhTnj3Sg9R-XM0U9gqOsNXT+Tn+VVRXJtBTt0A0DPQ0GQg@mail.gmail.com>
Date: Thu, 3 Jan 2019 15:11:22 -0500
From: Paul Moore <paul@...l-moore.com>
To: Richard Guy Briggs <rgb@...hat.com>
Cc: containers@...ts.linux-foundation.org, linux-audit@...hat.com,
linux-kernel@...r.kernel.org, ebiederm@...ssion.com,
luto@...nel.org, carlos@...hat.com, dhowells@...hat.com,
viro@...iv.linux.org.uk, simo@...hat.com,
Eric Paris <eparis@...isplace.org>,
Serge Hallyn <serge@...lyn.com>
Subject: Re: [PATCH ghak90 (was ghak32) V4 06/10] audit: add containerid
support for tty_audit
On Wed, Oct 31, 2018 at 5:17 PM Richard Guy Briggs <rgb@...hat.com> wrote:
> On 2018-10-19 19:17, Paul Moore wrote:
> > On Sun, Aug 5, 2018 at 4:33 AM Richard Guy Briggs
<rgb@...hat.com> wrote:
> > > Add audit container identifier auxiliary record to tty
logging rule
> > > event standalone records.
> > >
> > > Signed-off-by: Richard Guy Briggs <rgb@...hat.com>
> > > Acked-by: Serge Hallyn <serge@...lyn.com>
> > > ---
> > > drivers/tty/tty_audit.c | 5 ++++-
> > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/tty/tty_audit.c b/drivers/tty/tty_audit.c
> > > index 50f567b..3e21477 100644
> > > --- a/drivers/tty/tty_audit.c
> > > +++ b/drivers/tty/tty_audit.c
> > > @@ -66,8 +66,9 @@ static void tty_audit_log(const char
*description, dev_t dev,
> > > uid_t uid = from_kuid(&init_user_ns, task_uid(tsk));
> > > uid_t loginuid = from_kuid(&init_user_ns,
audit_get_loginuid(tsk));
> > > unsigned int sessionid = audit_get_sessionid(tsk);
> > > + struct audit_context *context =
audit_alloc_local(GFP_KERNEL);
> > >
> > > - ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_TTY);
> > > + ab = audit_log_start(context, GFP_KERNEL, AUDIT_TTY);
> > > if (ab) {
> > > char name[sizeof(tsk->comm)];
> > >
> > > @@ -80,6 +81,8 @@ static void tty_audit_log(const char
*description, dev_t dev,
> > > audit_log_n_hex(ab, data, size);
> > > audit_log_end(ab);
> > > }
> > > + audit_log_contid(context, "tty", audit_get_contid(tsk));
> > > + audit_free_context(context);
> > > }
> >
> > Since I never polished up my task_struct/current fix patch enough to
> > get it past RFC status during this development window (new job, stolen
> > laptop, etc.) *and* it looks like you are going to need at least one
> > more respin of this patchset, go ahead and fix this patch to use
> > current instead of generating a local context. I'll deal with the
> > merge fallout if/when it happens.
>
> Sure, I will switch it to current in the call to audit_get_contid().
>
> The local context is a distinct issue. Like USER records, I prefer
> local due to potential record volume, it is already trackable as far as
> Steve is concerned, and if it is to be connected with the syscall
> record, it should be linked to syscall records in a seperate new github
> issue with its own patch. It accumulates events until the buffer is
> flushed to a record, so the timestamp only represents the flush (usually
> user "CR/enter").
Generally, yes, associating records is a separate issue, but in this
particular case you are changing this record by making it a "local"
record, which as we've discussed before, I view as a necessary evil
and something that must be minimized. A quick look at the
tty_audit_log() callers shows tty_audit_tiocsti() which is an ioctl
handler (and thus current should be valid and correct), and
tty_audit_buf_push() whose callers all seem have valid and correct
current values; if you find that not to be the case please let me
know.
> > Local contexts are a last resort. If you ever find yourself writing
> > code that generates a local context, you should first be 100% certain
> > that the event is not the the result of a process initiated action (in
> > which case it should take from the task's context).
>
> Well, I'm 100% certain it is linked to a process, but so are USER
> records that are already being discussed as the exception. This is
> basically a keystroke logger (that has a flag to omit passwords).
--
paul moore
www.paul-moore.com
Powered by blists - more mailing lists