public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
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

  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