audit 2.2.3 released
by Steve Grubb
Hi,
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit. It will also be in rawhide
soon. The ChangeLog is:
- Code cleanups
- In spec file, don't own lib64/audit
- Update man pages
- Aureport no longer reads auditd.conf when stdin is used
- Don't let systemd kill auditd if auditctl errors out
- Update syscall table for 3.7 and 3.8 kernels
- Add interpretation for setns and unshare syscalls
- Code cleanup (Tyler Hicks)
- Documentation cleanups (Laurent Bigonville)
- Add dirfd interpretation to the *at functions
- Add termination signal to clone flags interpretation
- Update stig.rules
- In auditctl, when listing rules don't print numeric value of dir fields
- Add support for rng resource type in auvirt
- Fix aulast bad login output (#922508)
- In ausearch, allow negative numbers for session and auid searches
- In audisp-remote, if disk_full_action is stop then stop sending (#908977)
This is almost entirely a bugfix release. The new capabilities is that the
syscall tables were updated and some interpretations were updated. Ausearch
now allows using a negative number for auid and session search options. Aside
from that - lots of bug fixes.
Please let me know if you run across any problems with this release.
-Steve
12 years, 1 month
Re: [PATCH RFC 8/8] audit: allow user records to be created inside a container
by Eric W. Biederman
Aristeu Rozanski <arozansk(a)redhat.com> writes:
> Since user events will be followed by namespace information, userspace
> can filter off undesired container records.
I don't think we want to allow any user to write to the audit records,
that is what nsown_capable will allow, as all you would need to do is to
unshare the user namespace to be able to write audit records.
Eric
> @@ -597,13 +612,13 @@ static int audit_netlink_ok(struct sk_buff *skb, u16 msg_type)
> case AUDIT_TTY_SET:
> case AUDIT_TRIM:
> case AUDIT_MAKE_EQUIV:
> - if (!capable(CAP_AUDIT_CONTROL))
> + if (!nsown_capable(CAP_AUDIT_CONTROL))
> err = -EPERM;
> break;
> case AUDIT_USER:
> case AUDIT_FIRST_USER_MSG ... AUDIT_LAST_USER_MSG:
> case AUDIT_FIRST_USER_MSG2 ... AUDIT_LAST_USER_MSG2:
> - if (!capable(CAP_AUDIT_WRITE))
> + if (!nsown_capable(CAP_AUDIT_WRITE))
> err = -EPERM;
> break;
> default: /* bad msg */
12 years, 1 month
[PATCH RFC] audit: provide namespace information in user originated records
by Aristeu Rozanski
(re-sending this, linux-audit is members only it seems)
This patchset introduces a new audit record to follow all USER records which
provides namespace information of the process. The idea is to allow processes
in containers to create records in the host system while providing means to be
filtered out.
For each new namespace, a unique procfs inode number is allocated and this
number has been used by userspace to determine which processes belong to the
same namespace. These numbers are used in the new audit record.
Applications such as libvirt-sandbox and lxc can then report the same numbers
when a container is created and destroyed allowing to map records to a certain
container. Maybe the next step would be having a record for whenever a new
namespace is created?
First 6 patches are needed in order to get each namespace's inode number.
Patch 7 properly defines the new record that is related to the USER record
Patch 8 allows USER records to be generated from namespaces
Here's an example of output:
type=CRED_DISP msg=audit(1363528861.403:311): pid=20016 uid=0 auid=0 ses=45 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
type=UNKNOWN[1327] msg=audit(1363528861.403:311): mnt=4026531840 net=4026531956 uts=4026531838 ipc=4026531839 pid=4026531836 user=4026531837
Notes:
- this is a RFC, all sorts of feedback are much appreciated
- while the last patch allows a new userns to send audit records, I haven't
look yet on making sure it has proper capabilities so regular users'
containers can create records
- the record number allocated is just a draft. If this patchset evolves into
something that can be merged, please advise which number number is the best
choice
fs/namespace.c | 14 +++++++
include/linux/ipc_namespace.h | 1
include/linux/mnt_namespace.h | 2 +
include/linux/pid_namespace.h | 1
include/linux/user_namespace.h | 1
include/linux/utsname.h | 1
include/net/net_namespace.h | 1
include/uapi/linux/audit.h | 1
ipc/namespace.c | 14 +++++++
kernel/audit.c | 76 +++++++++++++++++++++++++++++++++++++----
kernel/pid_namespace.c | 11 +++++
kernel/user_namespace.c | 5 ++
kernel/utsname.c | 14 +++++++
net/core/net_namespace.c | 14 +++++++
14 files changed, 150 insertions(+), 6 deletions(-)
12 years, 1 month
Re: PCI-DSS: Log every root actions/keystrokes but avoid passwords
by Tracy Reed
I am resurrecting this old thread from last summer because I ran into the same
issue and found the thread in the archives via Google. It would be very nice if
everything could be logged except passwords. Isn't the option for echo back set
in the tty settings? Could the pam module not log characters when the tty is
set for no echo back? Or at least log the fact that something was typed but
not logged. A typical problematic log line looks like:
type=TTY msg=audit(1362711728.667:284493): tty pid=21810 uid=0 auid=500 major=136 minor=1 comm="passwd" data=ABCDEF01234569
We can already enable/disable audit based on user with enable= or disable= as
an argument to the pam module. Could we do something similar with the command?
So if comm="passwd" could we note that something was typed but not log the
actual chars?
On Friday, July 13, 2012 10:14:59 AM Florian Crouzat wrote:
> Le 12/07/2012 21:41, Thugzclub a écrit :
> > Florian,
> >
> > Did you get and answer for this?
> >
> > Regards.
>
> Not a single one.
Hmm...I thought I sent an answer. The problem from the kernel's perspective is
that it has no idea what user space is doing. It can't tell a password from
anything else being typed. There is a flag that can be set for the TTY to hide
characters. But the issue then becomes that now you have a loophole that a
crafty admin could use to hide what he's really doing.
If anyone has ideas on how to improve this, I think we should.
-Steve
> > On 10 Jul 2012, at 08:29, Florian Crouzat <gentoo floriancrouzat net>
wrote:
> >> Hi,
> >>
> >> This is my first message to the list to please be indulgent, I might be
> >> mixing concepts here between auditd, selinux and pam. Any guidance much
> >> appreciated.
> >>
> >> For PCI-DSS, in order to be allowed to have a real root shell instead of
> >> firing sudo all the time (and it's lack of glob/completion), I'm trying
> >> to have any commands fired in any kind of root shell logged. (Of course
> >> it doesn't protect against malicious root users but that's off-topic).
> >>
> >> So, I've been able to achieve that purpose by using :
> >>
> >> $ grep tty /etc/pam.d/{su*,system-auth}
> >> /etc/pam.d/su:session required pam_tty_audit.so enable=root
> >> /etc/pam.d/sudo:session required pam_tty_audit.so open_only enable=root
> >> /etc/pam.d/sudo-i:session required pam_tty_audit.so open_only enable=root
> >> /etc/pam.d/su-l:session required pam_tty_audit.so enable=root
> >> /etc/pam.d/system-auth:session required pam_tty_audit.so disable=*
> >> enable=root
> >>
> >> Every keystroke are logged in /var/log/audit/audit.log which is great. My
> >> only issue is that I just realized that prompt passwords are also
> >> logged, eg MySQL password or Spacewalk, etc. I can read them in plain
> >> text when doing "aureport --tty -if /var/log/audit/audit.log and PCI-DSS
> >> forbid any kind of storage of passwords, is there a workaround ? Eg:
> >> don't log keystrokes when the prompt is "hidden" (inputting a password)
> >>
> >> I'd like very much to be able to obtain real root shells for ease of work
> >> (sudo -i) my only constraint beeing: log everything but don't store any
> >> password.
> >>
> >> Thanks,
> >>
> >> --
> >> Cheers,
> >> Florian Crouzat
>
> --
> Linux-audit mailing list
> Linux-audit redhat com
> https://www.redhat.com/mailman/listinfo/linux-audit
--
Tracy Reed
12 years, 1 month
Auparse feature or bug
by Burn Alting
Hi,
When the auparse library parses certain USER_* type events it appears to
have an issue key values with embedded spaces. For example, the event
type=USER_CHAUTHTOK msg=audit(1363256032.497:202603): user
pid=24180 uid=0 auid=500 ses=1 msg='op=change password id=500
exe="/usr/bin/passwd" hostname=? addr=? terminal=pts/1
res=success'
when parsed using the code identified in auparse_feed(1), will result in
event: 1
records:1
fields:12
type=1108 event time: 1363256032.497:202603
type=USER_CHAUTHTOK (USER_CHAUTHTOK)
pid=24180 (24180)
uid=0 (root)
auid=500 (burn)
ses=1 (1)
op=change (change)
id=500 (burn)
exe="/usr/bin/passwd" (/usr/bin/passwd)
hostname=? (?)
addr=? (?)
terminal=pts/1 (pts/1)
res=success (success)
As you can see, we have lost the 'password' element of the
"op=change password"
key value pair in the original event.
Is this a feature or bug???
Regards
Burn
Regards
Burn Alting
12 years, 1 month
