[PATCH] audit: mark expected switch fall-through
by Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.
This patch fixes the following warning:
kernel/auditfilter.c: In function ‘audit_krule_to_data’:
kernel/auditfilter.c:668:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
if (krule->pflags & AUDIT_LOGINUID_LEGACY && !f->val) {
^
kernel/auditfilter.c:674:3: note: here
default:
^~~~~~~
Warning level 3 was used: -Wimplicit-fallthrough=3
Notice that, in this particular case, the code comment is modified
in accordance with what GCC is expecting to find.
This patch is part of the ongoing efforts to enable
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com>
---
kernel/auditfilter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index add360b46b38..63f8b3f26fab 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -670,7 +670,7 @@ static struct audit_rule_data *audit_krule_to_data(struct audit_krule *krule)
data->values[i] = AUDIT_UID_UNSET;
break;
}
- /* fallthrough if set */
+ /* fall through - if set */
default:
data->values[i] = f->val;
}
--
2.20.1
4 years
Re: Linux Audit userspace query
by Ondrej Mosnáček
Hello Ali,
pi 26. 7. 2019 o 15:00 Ali Ahad <20100284(a)lums.edu.pk> napísal(a):
> Dear Ondrej,
>
> I am computer science student currently enrolled in my senior year at Lahore University of Management Sciences (LUMS) , Pakistan . I am writing this email in regards to a problem that I am facing while working on the repository "Linux Audit userspace".
>
> The summer research project I have been working on involves modifying and customizing the linux audit userspace such that I can customize the AUDIT_ARGS (a0,a1,a2 etc) of the write system calls being recorded. I have been looking the repository for days now and am unable to figure out the source of where the syscalls or any other events are being recorded.
I'm not sure what exactly you are trying to achieve, but the audit
records are not generated in the userspace programs, but in the
kernel. The userspace code (auditd) only receives them, writes them
into log files and optionally passes them on to other programs. There
are also utilities for parsing (libauparse, ...) and searching the
records (ausearch, ...).
>
> Basically, I am unable to figure out where an audit_event is being populated with the relevant data such as the audit_args (a0,a1,a2) so that I can change and play around with the arguments that are being recorded and populated at the source.
Again, to change the way values are being recorded into the record,
you'd need to modify the kernel.
>
> Kindly let me know if you can slightly guide me in this regard. I would be really grateful. Also kindly let me know of the feasibility of the problem. So basically the argument a1 of the write syscall records the pointer to a buffer. Is it possible to store the dereferenced complete buffer as the argument instead?
It is technically possible, again at the kernel level. Obviously we
don't do that currently, since to post-process the arguments you'd
need to do specific stuff for each specific syscall, which would lead
to excessive logging, challenges with record format, keeping the code
in sync with all the syscalls being supported in the kernel, etc...
For logging extended information about what is happening in each
syscall, we usually use separate records with specific type and fields
that are associated to the syscall record based on record ID.
I'm adding the linux-audit mailing list to Cc - that is the official
place to discuss questions about Linux audit subsystem and the
associated userspace tools. You are likely to get a reply from people
much more involved and educated in audit than me :)
>
> Thanks in anticipation. Really looking forward to hearing back from you.
>
> Best,
> Ali Ahad,
> Lahore University of Management Sciences (LUMS)
Cheers and good luck with your project!
Ondrej Mosnacek
4 years, 9 months
boot parameter question
by Lenny Bruzenak
I'm having trouble getting my "audit_backlog_limit" boot parameter
accepted.
I have the following 2 audit parameters on my boot line:
audit=1
audit_backlog_limit=8192
My /proc/cmdline shows them both once booted up.
But I'm not getting the audit_backlog_limit applied to the kernel audit
startup. I have a auditctl -b 8192 that runs from the audit.rules, and
the resulting CONFIG_change event shows "...audit_backlog_limit=8192,
old=64...".
After startup I run:
# auditctl -s
and see that I've lost 93 events.
Looking at the kernel code, I see that if the "audit=1" value is set, it
should print:
"enabled (after initialization)" , which I see in both dmesg and
/var/log/messages,
The second one (audit_backlog_limit=8192) should output IIUC:
"audit_backlog_limit: " , which I don't see anywhere.
It's as if the parameter is being ignored. I've tried moving it to a
different spot so it isn't the last on the line, etc. Nothing.
I stumbled on this because I'm not seeing the "SYSTEM_BOOT" events
anymore; I suspect they are in the missing ones.
Pretty sure I don't have a typo; I've put it into the grub config and
run the grub2-mkconfig -o /boot/grub2/grub.cfg and booted from that.
Again, the parameter is there in /proc/cmdline but doesn't seem to be
accepted. No warnings about it either AFAICT.
RHEL7.6, kernel 3.10.0-957
Don't think the audit userspace version makes much difference, but it is
2.8.5.
Thanks in advance,
LCB
--
Lenny Bruzenak
MagitekLTD
4 years, 9 months
How to filter PROCTITLE events
by 杨海
Hi
I am looking for the method to filter the PROCTITLE events via auditctl.
It is said we can do it, but I could not figure out how.
"The proctitle event is emitted during syscall audits, and can be filtered with auditctl."
Regards
Hai
4 years, 9 months
[PATCH] kernel: auditfilter: Fix a possible null-pointer dereference in audit_watch_path()
by Jia-Ju Bai
In audit_find_rule(), there is an if statement on line 894 to check
whether entry->rule.watch is NULL:
else if (entry->rule.watch)
If entry->rule.watch is NULL, audit_compare_rule on 910 is called:
audit_compare_rule(&entry->rule, &e->rule))
In audit_compare_rule(), a->watch is used on line 720:
if (strcmp(audit_watch_path(a->watch), ...)
In this case, a->watch is NULL, and audit_watch_path() will use:
watch->path
Thus, a possible null-pointer dereference may occur in this case.
To fix this possible bug, an if statement is added in
audit_compare_rule() to check a->watch before using a->watch.
This bug is found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990(a)gmail.com>
---
kernel/auditfilter.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index b0126e9c0743..b0ad17b14609 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -717,6 +717,8 @@ static int audit_compare_rule(struct audit_krule *a, struct audit_krule *b)
return 1;
break;
case AUDIT_WATCH:
+ if (!a->watch)
+ break;
if (strcmp(audit_watch_path(a->watch),
audit_watch_path(b->watch)))
return 1;
--
2.17.0
4 years, 9 months
Preferred subj= with multiple LSMs
by Casey Schaufler
Which of these options would be preferred for audit records
when there are multiple active security modules? I'm not asking
if we should do it, I'm asking which of these options I should
implement when I do do it. I've prototyped #1 and #2. #4 is a
minor variant of #1 that is either better for compatibility or
worse, depending on how you want to look at it. I understand
that each of these offer challenges. If I've missed something
obvious, I'd be delighted to consider #5.
Thank you.
Option 1:
subj=selinux='x:y:z:s:c',apparmor='a'
Option 2:
subj=x:y:z:s:c subj=a
Option 3:
lsms=selinux,apparmor subj=x:y:z:s:c subj=a
Option 4:
subjs=selinux='x:y:z:s:c',apparmor='a'
Option 5:
Something else.
4 years, 9 months
[PATCH ghak90 V6 00/10] audit: implement container identifier
by Richard Guy Briggs
Implement kernel audit container identifier.
This patchset is a fifth based on the proposal document (V3)
posted:
https://www.redhat.com/archives/linux-audit/2018-January/msg00014.html
The first patch was the last patch from ghak81 that was absorbed into
this patchset since its primary justification is the rest of this
patchset.
The second patch implements the proc fs write to set the audit container
identifier of a process, emitting an AUDIT_CONTAINER_OP record to
announce the registration of that audit container identifier on that
process. This patch requires userspace support for record acceptance
and proper type display.
The third implements reading the audit container identifier from the
proc filesystem for debugging. This patch wasn't planned for upstream
inclusion but is starting to become more likely.
The fourth implements the auxiliary record AUDIT_CONTAINER_ID if an audit
container identifier is associated with an event. This patch requires
userspace support for proper type display.
The 5th adds audit daemon signalling provenance through audit_sig_info2.
The 6th creates a local audit context to be able to bind a standalone
record with a locally created auxiliary record.
The 7th patch adds audit container identifier records to the user
standalone records.
The 8th adds audit container identifier filtering to the exit,
exclude and user lists. This patch adds the AUDIT_CONTID field and
requires auditctl userspace support for the --contid option.
The 9th adds network namespace audit container identifier labelling
based on member tasks' audit container identifier labels.
The 10th adds audit container identifier support to standalone netfilter
records that don't have a task context and lists each container to which
that net namespace belongs.
Example: Set an audit container identifier of 123456 to the "sleep" task:
sleep 2&
child=$!
echo 123456 > /proc/$child/audit_containerid; echo $?
ausearch -ts recent -m container_op
echo child:$child contid:$( cat /proc/$child/audit_containerid)
This should produce a record such as:
type=CONTAINER_OP msg=audit(2018-06-06 12:39:29.636:26949) : op=set opid=2209 contid=123456 old-contid=18446744073709551615 pid=628 auid=root uid=root tty=ttyS0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 comm=bash exe=/usr/bin/bash res=yes
Example: Set a filter on an audit container identifier 123459 on /tmp/tmpcontainerid:
contid=123459
key=tmpcontainerid
auditctl -a exit,always -F dir=/tmp -F perm=wa -F contid=$contid -F key=$key
perl -e "sleep 1; open(my \$tmpfile, '>', \"/tmp/$key\"); close(\$tmpfile);" &
child=$!
echo $contid > /proc/$child/audit_containerid
sleep 2
ausearch -i -ts recent -k $key
auditctl -d exit,always -F dir=/tmp -F perm=wa -F contid=$contid -F key=$key
rm -f /tmp/$key
This should produce an event such as:
type=CONTAINER_ID msg=audit(2018-06-06 12:46:31.707:26953) : contid=123459
type=PROCTITLE msg=audit(2018-06-06 12:46:31.707:26953) : proctitle=perl -e sleep 1; open(my $tmpfile, '>', "/tmp/tmpcontainerid"); close($tmpfile);
type=PATH msg=audit(2018-06-06 12:46:31.707:26953) : item=1 name=/tmp/tmpcontainerid inode=25656 dev=00:26 mode=file,644 ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=PATH msg=audit(2018-06-06 12:46:31.707:26953) : item=0 name=/tmp/ inode=8985 dev=00:26 mode=dir,sticky,777 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=CWD msg=audit(2018-06-06 12:46:31.707:26953) : cwd=/root
type=SYSCALL msg=audit(2018-06-06 12:46:31.707:26953) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffffffffffff9c a1=0x5621f2b81900 a2=O_WRONLY|O_CREAT|O_TRUNC a3=0x1b6 items=2 ppid=628 pid=2232 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=ttyS0 ses=1 comm=perl exe=/usr/bin/perl subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=tmpcontainerid
Example: Test multiple containers on one netns:
sleep 5 &
child1=$!
containerid1=123451
echo $containerid1 > /proc/$child1/audit_containerid
sleep 5 &
child2=$!
containerid2=123452
echo $containerid2 > /proc/$child2/audit_containerid
iptables -I INPUT -i lo -p icmp --icmp-type echo-request -j AUDIT --type accept
iptables -I INPUT -t mangle -i lo -p icmp --icmp-type echo-request -j MARK --set-mark 0x12345555
sleep 1;
bash -c "ping -q -c 1 127.0.0.1 >/dev/null 2>&1"
sleep 1;
ausearch -i -m NETFILTER_PKT -ts boot|grep mark=0x12345555
ausearch -i -m NETFILTER_PKT -ts boot|grep contid=|grep $containerid1|grep $containerid2
This should produce an event such as:
type=NETFILTER_PKT msg=audit(03/15/2019 14:16:13.369:244) : mark=0x12345555 saddr=127.0.0.1 daddr=127.0.0.1 proto=icmp
type=CONTAINER_ID msg=audit(03/15/2019 14:16:13.369:244) : contid=123452,123451
Includes the last patch of https://github.com/linux-audit/audit-kernel/issues/81
Please see the github audit kernel issue for the main feature:
https://github.com/linux-audit/audit-kernel/issues/90
and the kernel filter code:
https://github.com/linux-audit/audit-kernel/issues/91
and the network support:
https://github.com/linux-audit/audit-kernel/issues/92
Please see the github audit userspace issue for supporting record types:
https://github.com/linux-audit/audit-userspace/issues/51
and filter code:
https://github.com/linux-audit/audit-userspace/issues/40
Please see the github audit testsuiite issue for the test case:
https://github.com/linux-audit/audit-testsuite/issues/64
Please see the github audit wiki for the feature overview:
https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID
Changelog:
v6
- change TMPBUFLEN from 11 to 21 to cover the decimal value of contid
u64 (nhorman)
- fix bug overwriting ctx in struct audit_sig_info, move cid above
ctx[0] (nhorman)
- fix bug skipping remaining fields and not advancing bufp when copying
out contid in audit_krule_to_data (omosnacec)
- add acks, tidy commit descriptions, other formatting fixes (checkpatch
wrong on audit_log_lost)
- cast ull for u64 prints
- target_cid tracking was moved from the ptrace/signal patch to
container_op
- target ptrace and signal records were moved from the ptrace/signal
patch to container_id
- auditd signaller tracking was moved to a new AUDIT_SIGNAL_INFO2
request and record
- ditch unnecessary list_empty() checks
- check for null net and aunet in audit_netns_contid_add()
- swap CONTAINER_OP contid/old-contid order to ease parsing
v5
- address loginuid and sessionid syscall scope in ghak104
- address audit_context in CONFIG_AUDIT vs CONFIG_AUDITSYSCALL in ghak105
- remove tty patch, addressed in ghak106
- rebase on audit/next v5.0-rc1
w/ghak59/ghak104/ghak103/ghak100/ghak107/ghak105/ghak106/ghak105sup
- update CONTAINER_ID to CONTAINER_OP in patch description
- move audit_context in audit_task_info to CONFIG_AUDITSYSCALL
- move audit_alloc() and audit_free() out of CONFIG_AUDITSYSCALL and into
CONFIG_AUDIT and create audit_{alloc,free}_syscall
- use plain kmem_cache_alloc() rather than kmem_cache_zalloc() in audit_alloc()
- fix audit_get_contid() declaration type error
- move audit_set_contid() from auditsc.c to audit.c
- audit_log_contid() returns void
- audit_log_contid() handed contid rather than tsk
- switch from AUDIT_CONTAINER to AUDIT_CONTAINER_ID for aux record
- move audit_log_contid(tsk/contid) & audit_contid_set(tsk)/audit_contid_valid(contid)
- switch from tsk to current
- audit_alloc_local() calls audit_log_lost() on failure to allocate a context
- add AUDIT_USER* non-syscall contid record
- cosmetic cleanup double parens, goto out on err
- ditch audit_get_ns_contid_list_lock(), fix aunet lock race
- switch from all-cpu read spinlock to rcu, keep spinlock for write
- update audit_alloc_local() to use ktime_get_coarse_real_ts64()
- add nft_log support
- add call from do_exit() in audit_free() to remove contid from netns
- relegate AUDIT_CONTAINER ref= field (was op=) to debug patch
v4
- preface set with ghak81:"collect audit task parameters"
- add shallyn and sgrubb acks
- rename feature bitmap macro
- rename cid_valid() to audit_contid_valid()
- rename AUDIT_CONTAINER_ID to AUDIT_CONTAINER_OP
- delete audit_get_contid_list() from headers
- move work into inner if, delete "found"
- change netns contid list function names
- move exports for audit_log_contid audit_alloc_local audit_free_context to non-syscall patch
- list contids CSV
- pass in gfp flags to audit_alloc_local() (fix audit_alloc_context callers)
- use "local" in lieu of abusing in_syscall for auditsc_get_stamp()
- read_lock(&tasklist_lock) around children and thread check
- task_lock(tsk) should be taken before first check of tsk->audit
- add spin lock to contid list in aunet
- restrict /proc read to CAP_AUDIT_CONTROL
- remove set again prohibition and inherited flag
- delete contidion spelling fix from patchset, send to netdev/linux-wireless
v3
- switched from containerid in task_struct to audit_task_info (depends on ghak81)
- drop INVALID_CID in favour of only AUDIT_CID_UNSET
- check for !audit_task_info, throw -ENOPROTOOPT on set
- changed -EPERM to -EEXIST for parent check
- return AUDIT_CID_UNSET if !audit_enabled
- squash child/thread check patch into AUDIT_CONTAINER_ID patch
- changed -EPERM to -EBUSY for child check
- separate child and thread checks, use -EALREADY for latter
- move addition of op= from ptrace/signal patch to AUDIT_CONTAINER patch
- fix && to || bashism in ptrace/signal patch
- uninline and export function for audit_free_context()
- drop CONFIG_CHANGE, FEATURE_CHANGE, ANOM_ABEND, ANOM_SECCOMP patches
- move audit_enabled check (xt_AUDIT)
- switched from containerid list in struct net to net_generic's struct audit_net
- move containerid list iteration into audit (xt_AUDIT)
- create function to move namespace switch into audit
- switched /proc/PID/ entry from containerid to audit_containerid
- call kzalloc with GFP_ATOMIC on in_atomic() in audit_alloc_context()
- call kzalloc with GFP_ATOMIC on in_atomic() in audit_log_container_info()
- use xt_net(par) instead of sock_net(skb->sk) to get net
- switched record and field names: initial CONTAINER_ID, aux CONTAINER, field CONTID
- allow to set own contid
- open code audit_set_containerid
- add contid inherited flag
- ccontainerid and pcontainerid eliminated due to inherited flag
- change name of container list funcitons
- rename containerid to contid
- convert initial container record to syscall aux
- fix spelling mistake of contidion in net/rfkill/core.c to avoid contid name collision
v2
- add check for children and threads
- add network namespace container identifier list
- add NETFILTER_PKT audit container identifier logging
- patch description and documentation clean-up and example
- reap unused ppid
Richard Guy Briggs (10):
audit: collect audit task parameters
audit: add container id
audit: read container ID of a process
audit: log container info of syscalls
audit: add contid support for signalling the audit daemon
audit: add support for non-syscall auxiliary records
audit: add containerid support for user records
audit: add containerid filtering
audit: add support for containerid to network namespaces
audit: NETFILTER_PKT: record each container ID associated with a netNS
fs/proc/base.c | 57 +++++++-
include/linux/audit.h | 113 +++++++++++++--
include/linux/sched.h | 7 +-
include/uapi/linux/audit.h | 9 +-
init/init_task.c | 3 +-
init/main.c | 2 +
kernel/audit.c | 325 ++++++++++++++++++++++++++++++++++++++++++--
kernel/audit.h | 9 ++
kernel/auditfilter.c | 47 +++++++
kernel/auditsc.c | 90 ++++++++----
kernel/fork.c | 1 -
kernel/nsproxy.c | 4 +
net/netfilter/nft_log.c | 11 +-
net/netfilter/xt_AUDIT.c | 11 +-
security/selinux/nlmsgtab.c | 1 +
15 files changed, 627 insertions(+), 63 deletions(-)
--
1.8.3.1
4 years, 10 months
Re: [PATCH v5 15/23] LSM: Specify which LSM to display
by Stephen Smalley
On 7/9/19 1:51 PM, Casey Schaufler wrote:
> On 7/9/2019 10:13 AM, Stephen Smalley wrote:
>> On 7/3/19 5:25 PM, Casey Schaufler wrote:
>>> Create a new entry "display" in /proc/.../attr for controlling
>>> which LSM security information is displayed for a process.
>>> The name of an active LSM that supplies hooks for human readable
>>> data may be written to "display" to set the value. The name of
>>> the LSM currently in use can be read from "display".
>>> At this point there can only be one LSM capable of display
>>> active. A helper function lsm_task_display() to get the display
>>> slot for a task_struct.
>>
>> As I explained previously, this is a security hole waiting to happen. It still permits a process to affect the output of audit, alter the result of reading or writing /proc/self/attr nodes even by setuid/setgid/file-caps/context-changing programs, alter the contexts generated in netlink messages delivered to other processes (I think?), and possibly other effects beyond affecting the process' own view of things.
>
> I would very much like some feedback regarding which of the
> possible formats for putting multiple subject contexts in
> audit records would be preferred:
>
> lsm=selinux,subj=xyzzy_t lsm=smack,subj=Xyzzy
> lsm=selinux,smack subj=xyzzy_t,Xyzzy
> subj="selinux='xyzzy_t',smack='Xyzzy'"
(cc'd linux-audit mailing list)
>
> Or something else. Free bikeshedding!
>
> I don't see how you have a problem with netlink. My look
> at what's in the kernel didn't expose anything, but I am
> willing to be educated.
I haven't traced through it in detail, but it wasn't clear to me that
the security_secid_to_secctx() call always occurs in the context of the
receiving process (and hence use its display value). If not, then the
display of the sender can affect what is reported to the receiver;
hence, there is a forgery concern similar to the binder issue. It would
be cleaner if we didn't alter the default behavior of
security_secid_to_secctx() and security_secctx_to_secid() and instead
introduced new hooks for any case where we truly want the display to
take effect.
>
>>
>> Before:
>> $ id
>> uid=1002(sds2) gid=1002(sds2) groups=1002(sds2) context=staff_u:staff_r:staff_t:s0-s0:c0.c1023
>> $ su
>> Password:
>> su: Authentication failure
>>
>> syscall audit record:
>> type=SYSCALL msg=audit(07/09/2019 11:52:49.784:365) : arch=x86_64 syscall=openat
>> success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x560897e58e00 a2=O_
>> WRONLY a3=0x0 items=1 ppid=3258 pid=3781 auid=sds2 uid=sds2 gid=sds2 euid=root s
>> uid=root fsuid=root egid=sds2 sgid=sds2 fsgid=sds2 tty=pts2 ses=6 comm=su exe=/usr/bin/su subj=staff_u:staff_r:staff_t:s0-s0:c0.c1023 key=(null)
>>
>> After:
>> $ id
>> uid=1002(sds2) gid=1002(sds2) groups=1002(sds2) context=staff_u:staff_r:staff_t:s0-s0:c0.c1023
>> $ echo apparmor > /proc/self/attr/display
>> $ su
>> Password:
>> su: Authentication failure
>>
>> audit record:
>> type=SYSCALL msg=audit(07/09/2019 12:05:32.402:406) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x556b41e1ae00 a2=O_WRONLY a3=0x0 items=1 ppid=3258 pid=9426 auid=sds2 uid=sds2 gid=sds2 euid=root suid=root fsuid=root egid=sds2 sgid=sds2 fsgid=sds2 tty=pts2 ses=6 comm=su exe=/usr/bin/su subj==unconfined key=(null)
>>
>> NB The subj= field of the SYSCALL audit record is longer accurate and is potentially under the control of a process that would not be authorized to set its subject label to that value by SELinux.
>
> It's still accurate, it's just not complete. It's a matter
> of how best to complete it.
>
>>
>> Now, let's play with userspace.
>>
>> Before:
>> # id
>> uid=0(root) gid=0(root) groups=0(root) context=staff_u:staff_r:staff_t:s0-s0:c0.c1023
>> # passwd root
>> passwd: SELinux deny access due to security policy.
>>
>> audit record:
>> type=USER_AVC msg=audit(07/09/2019 12:24:35.135:812) : pid=12693 uid=root auid=sds2 ses=7 subj=staff_u:staff_r:passwd_t:s0-s0:c0.c1023 msg='avc: denied { passwd } for scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tclass=passwd permissive=0 exe=/usr/bin/passwd sauid=root hostname=? addr=? terminal=pts/2'
>> type=USER_CHAUTHTOK msg=audit(07/09/2019 12:24:35.135:813) : pid=12693 uid=root auid=sds2 ses=7 subj=staff_u:staff_r:passwd_t:s0-s0:c0.c1023 msg='op=attempted-to-change-password id=root exe=/usr/bin/passwd hostname=moss-pluto.infosec.tycho.ncsc.mil addr=? terminal=pts/2 res=failed'
>>
>> After:
>> # id
>> uid=0(root) gid=0(root) groups=0(root) context=staff_u:staff_r:staff_t:s0-s0:c0.c1023
>> # echo apparmor > /proc/self/attr/display
>> # passwd root
>> passwd: SELinux deny access due to security policy.
>>
>> audit record:
>> type=USER_CHAUTHTOK msg=audit(07/09/2019 12:28:41.349:832) : pid=13083 uid=root auid=sds2 ses=7 subj==unconfined msg='op=attempted-to-change-password id=root exe=/usr/bin/passwd hostname=moss-pluto.infosec.tycho.ncsc.mil addr=? terminal=pts/2 res=failed'
>>
>> Here we again get the wrong value for subj= in the USER_CHAUTHTOK audit record, and we further lose the USER_AVC record entirely because it didn't even reach the point of the permission check due to not being able to get the caller context.
>>
>> The situation gets worse if the caller can set things up such that it can set an attribute value for one security module that is valid and privileged with respect to another security module. This isn't a far-fetched scenario; AppArmor will default to running everything unconfined, so as soon as you enable it, any root process can potentially load a policy that defines contexts that look exactly like SELinux contexts. Smack is even simpler; you can set any arbitrary string you want as long as you are root (by default); no policy required. So a root process that is confined by SELinux (or by AppAmor) can suddenly forge arbitrary contexts in audit records or reads of /proc/self/attr nodes or netlink messages or ..., just by virtue of applying these patches and enabling another security module like Smack. Or consider if ptags were ever made real and merged - by design, that's all about setting arbitrary tags from userspace. Then there is the separate issue of switching
>> display to prevent attempts by a more privileged program to set one of its attributes from taking effect. Where have we seen that before - sendmail capabilities bug anyone? And it is actually worse than that bug, because with the assistance of a friendly security module, the write may actually succeed; it just won't alter the SELinux context of the program or anything it creates!
>>
>> This gets a NAK from me so long as it has these issues and setting the display remains outside the control of any security module.
>
> The issues you've raised around audit are meritorious.
> Any suggestions regarding how to address them would be
> quite welcome.
>
> As far as the general objection to the display mechanism,
> I am eager to understand what you might propose as an
> alternative. We can't dismiss backward compatibility for
> any of the modules. We can't preclude any module combination.
>
> We can require user space changes for configurations that
> were impossible before, just as the addition of SELinux to
> a system required user space changes. Update libselinux
> to check the display before using the attr interfaces and
> you've addressed most of the issues.
Either we ensure that setting of the display can only affect processes
in the same security equivalence class (same credentials) or the
security modules need to be able to control who can set the display. Or
both.
4 years, 10 months
Re: [RFC PATCH] security, capability: pass object information to security_capable
by Stephen Smalley
On 7/12/19 1:50 PM, James Morris wrote:
> On Fri, 12 Jul 2019, Nicholas Franck wrote:
>
>> + case LSM_AUDIT_DATA_CAP: {
>> + const struct inode *inode;
>> +
>> + if (a->u.cap_struct.cad) {
>> + switch (a->u.cap_struct.cad->type) {
>> + case CAP_AUX_DATA_INODE: {
>> + inode = a->u.cap_struct.cad->u.inode;
>> +
>> + audit_log_format(ab, " dev=");
>> + audit_log_untrustedstring(ab,
>> + inode->i_sb->s_id);
>> + audit_log_format(ab, " ino=%lu",
>> + inode->i_ino);
>> + break;
>> + }
>> + }
>> + }
>> + audit_log_format(ab, " capability=%d ", a->u.cap_struct.cap);
>> break;
>
> Will this break any existing userspace log parsers?
I'm hoping not given that we are only adding auxiliary fields and those
are already defined for other AVC audit messages. ausearch appeared to
work fine. Added the linux-audit mailing list to the cc line to get
their view.
4 years, 10 months
overhead of auditd
by 杨海
Hi,
Turning on all system calls in audit.rules, and transferring a tar file to the target system (CentOS 7, 4 cores), I found "auditd" consumes high CPU usage.
Is it expected?
BTW, after turning write-logs off, and add dispatcher, both "audispd" and "auditd" are consuming high CPU.
Regards
Hai
4 years, 10 months
