From: Eric Paris <eparis@redhat.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: Linux-Audit Mailing List <linux-audit@redhat.com>
Subject: Re: pam_tty_audit icanon log switch
Date: Thu, 11 Apr 2013 16:43:45 -0400 (EDT) [thread overview]
Message-ID: <1677270682.17361178.1365713025068.JavaMail.root@redhat.com> (raw)
In-Reply-To: <20130322054636.GA18911@madcap2.tricolour.ca>
----- Original Message -----
> Hi folks,
>
> There's been a couple of requests to add a switch to pam_tty_audit to
> *not* log passwords when logging user commands.
> Here are two patches, the first to pam to add the switch to
> the pam_tty_audit module. The second is to the kernel to add the
> necessary bits in audit and tty:
Patches as attachments are little harder to comment on. So inline preferred.
>From 110971ad92ce8669f6dc18db9e6369e92afdd03e Mon Sep 17 00:00:00 2001
From: Richard Guy Briggs <rgb@redhat.com>
Date: Thu, 21 Mar 2013 00:52:37 -0400
Subject: [PATCH] tty: add an option to control logging of passwords with pam_tty_audit
To: linux-audit@redhat.com
Most commands are entered one line at a time and processed as complete lines
in non-canonical mode. Commands that interactively require a password, enter
canonical mode to do this. This feature (icanon) can be used to avoid logging
passwords by audit while still logging the rest of the command.
Adding a member to the struct audit_tty_status passed in by pam_tty_audit
allows control of canonical mode per task.
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
drivers/tty/tty_audit.c | 8 ++++++++
include/linux/sched.h | 1 +
include/uapi/linux/audit.h | 3 ++-
kernel/audit.c | 5 ++++-
4 files changed, 15 insertions(+), 2 deletions(-)
[snip]
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -369,7 +369,8 @@ struct audit_status {
};
struct audit_tty_status {
- __u32 enabled; /* 1 = enabled, 0 = disabled */
+ __u32 enabled; /* 1 = enabled, 0 = disabled */
+ __u32 log_icanon; /* 1 = enabled, 0 = disabled */
};
/* audit_rule_data supports filter rules with both integer and string
diff --git a/kernel/audit.c b/kernel/audit.c
index d596e53..98d43c6 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -873,6 +873,7 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
spin_lock_irq(&tsk->sighand->siglock);
s.enabled = tsk->signal->audit_tty != 0;
+ s.log_icanon = tsk->signal->audit_tty_log_icanon != 0;
spin_unlock_irq(&tsk->sighand->siglock);
audit_send_reply(NETLINK_CB(skb).portid, seq,
@@ -886,11 +887,13 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
if (nlh->nlmsg_len < sizeof(struct audit_tty_status))
return -EINVAL;
s = data;
what happens if this comes from an old pam stack that didn't set/send log_icanon? We'd just be reading past the end of the allocation, right? Maybe something like
unsigned log_icanon
if (nlmsg_len(nlh) < sizeof(struct audit_tty_status))
log_icanon = 0;
else
log_icanon = s->log_icanon
- if (s->enabled != 0 && s->enabled != 1)
+ if (s->enabled != 0 && s->enabled != 1
+ && s->log_icanon != 0 && s->log_icanon != 1)
Shouldn't this be
if ((s->enabled != 0 && s->enabled != 1) || log_icanon != 0 && log_icanon != 1))
return -EINVAL;
spin_lock_irq(&tsk->sighand->siglock);
tsk->signal->audit_tty = s->enabled != 0;
+ tsk->signal->audit_tty_log_icanon = s->log_icanon != 0;
spin_unlock_irq(&tsk->sighand->siglock);
break;
}
--
1.7.1
next prev parent reply other threads:[~2013-04-11 20:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-22 5:46 pam_tty_audit icanon log switch Richard Guy Briggs
2013-03-22 7:19 ` Tomas Mraz
2013-04-26 17:42 ` Richard Guy Briggs
2013-04-29 7:14 ` Tomas Mraz
2013-03-22 16:05 ` Miloslav Trmac
2013-04-11 20:43 ` Eric Paris [this message]
2013-04-18 19:14 ` Richard Guy Briggs
2013-04-18 19:31 ` Miloslav Trmač
2013-04-18 20:07 ` Richard Guy Briggs
2013-04-22 17:16 ` Richard Guy Briggs
2013-04-22 17:28 ` Miloslav Trmač
2013-04-22 18:29 ` Richard Guy Briggs
2013-04-26 17:23 ` Richard Guy Briggs
2013-04-26 17:37 ` Richard Guy Briggs
2013-04-29 21:02 ` Miloslav Trmač
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=1677270682.17361178.1365713025068.JavaMail.root@redhat.com \
--to=eparis@redhat.com \
--cc=linux-audit@redhat.com \
--cc=rgb@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