Supplemental Groups
by Steve Grubb
Hi,
I ran across something that I was wondering if we have a deficiency/bug. Do we
need to capture supplemental group information? For example:
[sgrubb@beast ~]$ su - root
Password:
[root@beast ~]# echo "test" > /opt/test.txt
[root@beast ~]# chmod 0660 /opt/test.txt
[root@beast ~]# chgrp wheel /opt/test.txt
[root@beast ~]# ls -l /opt/test.txt
-rw-rw---- 1 root wheel 5 Feb 22 11:30 /opt/test.txt
[root@beast ~]# auditctl -a exit,always -S open -F loginuid=501
AUDIT_LIST: exit always loginuid=501 (0x10e5) syscall=open
We created a file that's readable if you have wheel as a supplemental group.
Now from another terminal:
[sgrubb@beast ~]$ cat /opt/test.txt
test
[sgrubb@beast ~]$
OK...it worked. So let's go see what's in the logs:
type=KERNEL msg=audit(1109089864.512:6279351): item=0 name=/opt/test.txt
inode=136 dev=00:00
type=KERNEL msg=audit(1109089864.512:6279351): syscall=5 exit=3 a0=bff6aa07
a1=8000 a2=0 a3=8000 items=1 pid=26538 loginuid=501 uid=501 gid=501 euid=501
suid=501 fsuid=501 egid=501 sgid=501 fsgid=501
Somewhere in there I expected group #10 to be mentioned since that is what
gave me access capability to the file. Does anyone know why its not recorded?
Don't we need that information?
-Steve Grubb
21 years
auditing procmail?
by Valdis.Kletnieks＠vt.edu
Anybody have any good ideas on what should happen for auditing and loginuid
when Sendmail invokes procmail as a delivery agent, and we're running
essentially arbitrary code as the user from their .procmailrc? My gut
feeling is that this *should* act just like a cron job for auditing
purposes, but the sendmail/procmail interface isn't in the least PAM-ified,
so we can't just toss in a 'session required pam_audit.so'...
21 years
PAM RPM in yum repository.
by David Woodhouse
Sorry for not getting this done last night -- it turned out to be a
little harder than I've expected. But a PAM package containing
pam_audit.so is now available in the yum repository.
This package lacks the PAM documentation (all of it, not just
documentation for the new audit bits) because it needed to be built in
the bleeding-edge Fedora buildroot to pick up the new glibc-kernheaders
and audit-libs, but the SGML documentation doesn't build there.
--
dwmw2
21 years
Audit and Sourceforge
by Merry Beekman
I thought at some point Audit would be posted to sourceforge. I went to
sourceforge but the Audit project doesn't appear to be
active http://sourceforge.net/projects/audit/.
I have a customer that needs to understand more about the Audit
project. Sourceforge doesn't seem like the right place to send him.
Is there an alternate resource?
Thanks,
Merry
21 years
Audit-0.6.3 released
by Steve Grubb
Hi,
Just wanted to let everyone know that the next version of the Linux audit
daemon is available. You can get it from
http://people.redhat.com/sgrubb/audit. Or rawhide tomorrow (Monday the
21st).
This release is mostly a bug fix release. There were some issues with the
library files being in the wrong directory on 64bit machines.
Pam_audit was updated to write loginuid to /proc/pid/loginuid. Because of the
way pam works, this is done in the parent process and the login uid is
inherited by the child. This does not work for sshd because of privilege
separation. I'll have to patch that directly.
Added pam_session_close to handle logout messaging.
Update to kernel headers in 2.6.11rc3.
Let me know if there are any problems.
-Steve Grubb
21 years
Another question - audit_lost
by Erich Schubert
Hi,
I set audit_backlog to 1024, and the logging flag to 0 (ignore).
still under heavy load I get:
audit: audit_lost=390 audit_backlog=3 audit_rate_limit=0
audit_backlog_limit=1024
[... other messages ...]
audit: audit_lost=702 audit_backlog=2 audit_rate_limit=0
audit_backlog_limit=1024
audit: audit_lost=703 audit_backlog=1 audit_rate_limit=0
audit_backlog_limit=1024
[... other messages ...]
audit: audit_lost=870 audit_backlog=24 audit_rate_limit=0
audit_backlog_limit=1024
[... more audit_lost messages ...]
audit: audit_lost=892 audit_backlog=2 audit_rate_limit=0
audit_backlog_limit=1024
This is around 30 lost audit events reported to syslog despite I
disabled this, the backlog is high enough and auditd is running (it
gets 102k lines in the first 60 seconds of my system startup)
Greetings,
Erich Schubert
--
erich(a)(mucl.de|debian.org) -- GPG Key ID: 4B3A135C (o_
To understand recursion you first need to understand recursion. //\
Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für V_/_
eine Stunde wie eine Heimat aus. --- Herrmann Hesse
21 years
[RFC][PATCH] (#4) auditfs
by Timothy R. Chavez
Hello,
New patch.
DONE:
- Prelim userspace patch to audit-0.6.2 (I will port this to 0.6.3
soon) to compliment Patch #4 (unavailable for public release at this
time). More work needs to be done in this area at a later date
(cleanup, man page, etc).
- Support for filtering out watches that are accessed in a way we do
not care about during syscall execution (ie: we only want to receive
audit records for /etc/passwd if we MAY_WRITE on it)
- Support for enabling / disabling filesystem auditing from userspace
(ie: auditctl)
- Refined logic that asserts priority. In general, objects being
watched will never be overwritten with a new watch. If the object is
unwatched and another watch is available, it will take on that watch.
- Added the notion of a "valid" and "invalid" watchlist entry.
- More structure to the overall system
* Refined core structs
* Added more helper functions
* Reduced redundant code
- Put protections around user space input.
- Correctly handle the filterkey field of the user space message
* Also allows for sending the same struct back to userspace
- Hooks in vfs_read/write/unlink (please look closely here). The rule
of thumb I went off of is: I can call my hook iff I have an inode and
I'm NOT hooking lookup_hash *nudge Stephen* :)
- Cleanup of some of the public functions / macro pairs.
- Some minor odds and ends
WHAT'S LEFT:
- Final feature to list all the current (valid) watches in the system
- Fix bug introduced by new logic. We are not able to print all
watched components in a path in a specific scenario due to the added
logic.
- Change wentry->w_watched to wentry->w_valid..... I found out the
hard way that wentry->w_watch and wentry->w_watched are too similar
:-)
- Write prelim design document
- Comment my code better
- Fix any remaining Patch #4 bugs
- Fix the inode bug in original code where the reported inode is
incorrect for unlink()s (it's the parent's inode)
- Oh and cleanup some more redundant code with watch removal from a watchlist
I hope Patch #5 is quick (by the end of this week) and will be the one
we bring to Al Viro next week? If you could please give this a quick
look over and raise flags / issues / nits, I'd really really
appreciate it. The positioning of my new hooks could be bad, please
let me know. I'm on 3 hours of sleep.
Three hooks for dynamically assigning watches:
d_splice_alias, d_move, d_instantiate
Five hooks for dynamically adding watches to our context:
permission, exec_permission_lite, vfs_read, vfs_write, vfs_unlink
I'm sending this to the internal list today to get some more eyes to
review (I hope)
--
- Timothy R. Chavez
21 years
Re: [RFC][PATCH] (#4) auditfs
by Stephen Smalley
On Tue, 2005-02-22 at 10:42 -0600, Timothy R. Chavez wrote:
> - Hooks in vfs_read/write/unlink (please look closely here). The rule
> of thumb I went off of is: I can call my hook iff I have an inode and
> I'm NOT hooking lookup_hash *nudge Stephen* :)
<snip>
> Three hooks for dynamically assigning watches:
> d_splice_alias, d_move, d_instantiate
>
> Five hooks for dynamically adding watches to our context:
> permission, exec_permission_lite, vfs_read, vfs_write, vfs_unlink
Why do you hook vfs_read/vfs_write when you have a hook in permission?
If you are trying to audit actual reads and writes, then there are other
cases to consider, e.g. do_sendfile(), plus fun with AIO. Much easier
if you can just stay with auditing open(2) calls via your permission(9)
hook.
There is a known race with respect to d_instantiate and file creation,
but it needs to be resolved anyway for SELinux, so I think you can
proceed under the assumption that it will be fixed. Alternatively, you
would need to move your hook call prior to the setting of d_inode in the
dentry and pass in the inode separately to your hook.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
21 years
Some syscalls not getting records
by Kris Wilson
Hi,
The India team was seeing a lack of audit records in some of the syscalls
tests,
so I did a little manual experimenting. With rules set for entry and exit
for chown
and chmod, I found that I got records for chmod and not chown (same results
if
I only have rules for one or the other). As root I created a file, su'ed
to ealuser,
and tried to do chmod and chown on that file. A record was created for
chmod but
not for chown. I su'ed back to root and successfully executed both
commands;
again a record for chmod but not chown. We were getting records for chown
on
the previous audit release. I haven't tried other syscalls to see how many
might
have this problem.
Kris Wilson
Linux Security
(512) 838-0126 T/L:678-0126
krisw(a)us.ibm.com
21 years
