Auditing file access by application
by John Petrini
Hello,
We have a need to monitor voicemail directories for any sort of access.
Basically there is only one application that should be accessing the files.
If anything else accesses the files we need to log that.
We setup the following to accomplish this but it's doesn't quite do what we
want.
-a always,exit -S all -F dir=/path/to/voicemail -F perm=rwxa -F
auid!=voicemail_user -F key=voicemail_watch
voicemail_user is the user that initially starts the process. The problem
arises when someone logged in under a different account restarts the
process. From that point forward every time the application accesses that
directory it results in a log message.
We need other users to be able to be able to log in and restart the process
so our method here really doesn't work. Is there a way to log only if a
different application access the directory rather than basing the audit on
user?
I was hoping to us something like -F exe!="/path/to/application" but it
looks like this is not supported.
Thank You,
___
John Petrini
7 years, 6 months
some questions about Linux audit
by 358123097
Dear Sir/Madam,
Hello， I‘am a Chinese student， now I studying Linux audit and having some problems. I want to collect some information from network，such as the accessor’s IP and port. I defined a audit rule in machine A as follow， then I used “ping” and “vsftpd” programs to test audit. For example, I run "ping A" in another machine, I can't collect any information in A's audit log. In addition, I run "ssh A" , then I get some incomprehensible records that display in the picture below(eg saddr=inet6 host:::1 serv:45983 and saddr=inet6 host:::ffff:127.0.0.1 serv:41573).
-a always,exit -F arch=b64 -S connect -S getsockname -S getpeername
Looking forward to your reply！
Your sincerely,
Yingjie Tang
7 years, 6 months
[PATCH 00/12] Delete CURRENT_TIME, CURRENT_TIME_SEC and current_fs_time
by Deepa Dinamani
The series contains the last unmerged uses of CURRENT_TIME,
CURRENT_TIME_SEC, and current_fs_time().
The series also deletes these apis.
All the patches except [PATCH 9/12] and [PATCH 10/12] are resend patches.
These patches fix new instances of CURRENT_TIME.
cifs and ceph patches have been squashed so that we have one patch per
filesystem.
We want to get these merged onto 4.12 release so that I can post the series
that changes vfs timestamps to use 64 bits for 4.13 release.
I'm proposing these to be merged through Andrew's tree.
Filesystem maintainers, please let Andrew know if you will be picking up
the patch in your trees.
Let me know if anybody has other preferences for merging.
Deepa Dinamani (12):
fs: f2fs: Use ktime_get_real_seconds for sit_info times
trace: Make trace_hwlat timestamp y2038 safe
fs: cifs: Replace CURRENT_TIME by other appropriate apis
fs: ceph: CURRENT_TIME with ktime_get_real_ts()
fs: ufs: Use ktime_get_real_ts64() for birthtime
audit: Use timespec64 to represent audit timestamps
fs: btrfs: Use ktime_get_real_ts for root ctime
fs: ubifs: Replace CURRENT_TIME_SEC with current_time
lustre: Replace CURRENT_TIME macro
apparmorfs: Replace CURRENT_TIME with current_time()
time: Delete CURRENT_TIME_SEC and CURRENT_TIME
time: Delete current_fs_time() function
drivers/block/rbd.c | 2 +-
drivers/staging/lustre/lustre/llite/llite_lib.c | 6 +++---
drivers/staging/lustre/lustre/osc/osc_io.c | 4 ++--
fs/btrfs/root-tree.c | 3 ++-
fs/ceph/mds_client.c | 4 +++-
fs/cifs/cifsencrypt.c | 4 +++-
fs/cifs/cifssmb.c | 10 ++++-----
fs/cifs/inode.c | 28 +++++++++++++------------
fs/f2fs/segment.c | 2 +-
fs/f2fs/segment.h | 5 +++--
fs/ubifs/dir.c | 12 +++++------
fs/ubifs/file.c | 12 +++++------
fs/ubifs/ioctl.c | 2 +-
fs/ubifs/misc.h | 10 ---------
fs/ubifs/sb.c | 14 +++++++++----
fs/ubifs/xattr.c | 6 +++---
fs/ufs/ialloc.c | 6 ++++--
include/linux/audit.h | 4 ++--
include/linux/fs.h | 1 -
include/linux/time.h | 3 ---
kernel/audit.c | 10 ++++-----
kernel/audit.h | 2 +-
kernel/auditsc.c | 6 +++---
kernel/time/time.c | 14 -------------
kernel/trace/trace_entries.h | 6 +++---
kernel/trace/trace_hwlat.c | 14 ++++++-------
kernel/trace/trace_output.c | 9 ++++----
net/ceph/messenger.c | 6 ++++--
net/ceph/osd_client.c | 4 ++--
security/apparmor/apparmorfs.c | 2 +-
30 files changed, 100 insertions(+), 111 deletions(-)
--
2.7.4
7 years, 6 months
[RFC PATCH V2 0/4] capabilities: do not audit log BPRM_FCAPS on set*id
by Richard Guy Briggs
The audit subsystem is adding a BPRM_FCAPS record when auditing setuid
application execution (SYSCALL execve). This is not expected as it was
supposed to be limited to when the file system actually had capabilities
in an extended attribute. It lists all capabilities making the event
really ugly to parse what is happening. The PATH record correctly
records the setuid bit and owner. Suppress the BPRM_FCAPS record on
set*id.
See: https://github.com/linux-audit/audit-kernel/issues/16
The patch that resolves this issue is the third. The first and second just
massage the logic to make it easier to understand.
It would be possible to address the original issue with a change of
"!uid_eq(new->euid, root_uid) || !uid_eq(new->uid, root_uid)"
to
"!(uid_eq(new->euid, root_uid) || uid_eq(new->uid, root_uid))"
but it took me long enough to understand this logic that I don't think I'd be
doing any favours by leaving it this difficult to understand.
The final patch attempts to address all the conditions that need logging based
on mailing list conversations, recoginizing there is probably some duplication
in the logic, which is why I'm posting this as an RFC for some feedback.
Richard Guy Briggs (4):
capabilities: use macros to make the logic easier to follow and
verify
capabilities: invert logic for clarity
capabilities: fix logic for effective root or real root
capabilities: auit log other surprising conditions
security/commoncap.c | 55 ++++++++++++++++++++++++++++++++-----------------
1 files changed, 36 insertions(+), 19 deletions(-)
7 years, 6 months
[PATCH 0/6 RFC] Address NETFILTER_CFG issues
by Richard Guy Briggs
There were questions about the presence and cause of unsolicited syscall events
in the logs containing NETFILTER_CFG records and sometimes unaccompanied
NETFILTER_CFG records.
During testing at least the following list of events trigger NETFILTER_CFG
records and the syscalls related (There may be more events that will trigger
this message type.):
init_module, finit_module: modprobe
setsockopt: iptables-restore, ip6tables-restore, ebtables-restore
unshare: (h?)ostnamed
clone: libvirtd
The syscall events unsolicited by any audit rule were found to be caused by a
missing !audit_dummy_context() check before creating a NETFILTER_CFG record.
Check !audit_dummy_context() before creating the NETFILTER_CFG record.
The vast majority of unaccompanied records are caused by the fedora default
rule: "-a never,task" and the occasional early startup one is I believe caused
by the iptables filter table module hard linked into the kernel rather than a
loadable module. The !audit_dummy_context() check above should avoid them.
Seemingly duplicate records are not actually exact duplicates that are caused
by netfilter table initialization in different network namespaces from the same
syscall. Recommend adding the network namespace ID (proc inode) to the record
to make this obvious.
Ebtables module initialization to register tables doesn't generate records
because it was never hooked in to audit. Recommend adding audit hooks to log
this.
See: https://github.com/linux-audit/audit-kernel/issues/25
See: https://github.com/linux-audit/audit-kernel/issues/35
See: https://github.com/linux-audit/audit-kernel/issues/43
Richard Guy Briggs (6):
netfilter: normalize x_table function declarations
netfilter: normalize ebtables function declarations
netfilter: audit only on xtables and ebtables syscall rule or
standalone
netfilter: ebtables: audit table registration
netfilter: add audit operation field
netfilter: add audit netns ID
include/linux/audit.h | 4 +-
include/linux/netfilter/x_tables.h | 1 +
include/uapi/linux/audit.h | 1 +
kernel/auditsc.c | 3 +-
net/bridge/netfilter/ebtables.c | 148 +++++++++++++++++++++++-------------
net/ipv4/netfilter/arp_tables.c | 2 +-
net/ipv4/netfilter/ip_tables.c | 2 +-
net/ipv6/netfilter/ip6_tables.c | 2 +-
net/netfilter/x_tables.c | 76 +++++++++++--------
9 files changed, 149 insertions(+), 90 deletions(-)
7 years, 6 months
A quick note on the audit-testsuite (https://github.com/linux-audit/audit-testsuite)
by Paul Moore
A FYI that I just updated the style checker located in
./tools/check-syntax (also available as 'make check-syntax') to add
support for Perl and used it to normalize all the code in the
repository. If you see a rather large set of diffs on your next pull,
that is likely why.
For those interested in these things, the style checker uses perltidy
to enforce the Perl style defined in the perlstyle(1) manpage.
For those of you who have already submitted code via PRs, don't worry,
this doesn't affect you as I'll do ahead and run the script after
merging your patches. For any new patches, please try to follow the
style guide as closely as possible.
Thanks.
--
paul moore
www.paul-moore.com
7 years, 7 months
Kerberos encrypted remote audit log
by Jan Horstmann
Hello,
I'm trying to set up a kerberos encrypted remote audit log using auditd and audisp-remote. The problem seems to be that audisp-remote assumes a kerberos principal of the form "auditd/hostname@REALM"
instead of "auditd/fqdn@REALM". The man page states under "krb5_client_name" that "[...] the remainder of the principal will consist of the host's fully qualified domain name and the default
kerberos realm, like this: auditd/host14.example.com@EXAMPLE.COM [...]". Is there any way to make audisp-remote use the fqdn form because our freeIPA is setup to do so and I'm not sure if that can be
changed at all.
The errors I'm getting on the listening daemon are: "auditd[16836]: TCP session from [IP:PORT] will be closed, error ignored"
On the audisp-remote end: "audisp-remote[34614]: krb5 error: Keytab contains no suitable keys for [auditd/hostname@REALM] in krb5_get_init_creds_keytab" and "audispd[34520]: plugin /sbin/audisp-remote
terminated unexpectedly". The auditd and audisp-remote version is 2.4.5.
It seems to me that freeIPA has struggled with this before at some point:
https://www.redhat.com/archives/freeipa-users/2014-August/msg00079.html
Any input would be much appreciated.
Regards,
Jan Horstmann
7 years, 7 months
