BUG: BPRM_FCAPS record generated when executing setuid applications

[pcmoore]

The audit subsystem is adding a BPRM_FCAPS record when auditing setuid application execution. This is not expected as it was supposed to be limited to when the file system actually had capabilities in an extended attribute.

This was observed on Fedora kernel 4.1.5-200.fc22.x86_64.

Reproducer:

# auditctl -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -F key=setuid-exec
# su - root
# ausearch --start recent -k setuid-exec -i

Actual results: It lists all capabilities making the event really ugly to parse what is happening.

Expected results: No BPRM_FCAPS record. The PATH record correctly records the setuid bit and owner.

[rgbriggs]

Patch posted upstream: linux-audit(stuck in moderation), lkml, linux-security-module(stuck in moderation) https://lkml.org/lkml/2017/3/2/830

[rgbriggs]

Posted 4-patch set upstream:

• https://www.redhat.com/archives/linux-audit/2017-May/msg00021.html
• http://kernsec.org/pipermail/linux-security-module-archive/2017-May/001135.html

[rgbriggs]

Posted 10-patch set upstream: (linux-audit and lsm) https://www.redhat.com/archives/linux-audit/2017-August/msg00062.html

[rgbriggs]

Post v4 upstream: https://www.redhat.com/archives/linux-audit/2017-September/msg00017.html Passes: (ltp 20170516) ./runltp -f syscalls -s cap ./runltp -f securebits ./runltp -f cap_bounds ./runltp -f filecaps make TARGETS="capabilities" kselftest

[rgbriggs]

Posted v5 patchset upstream to linux-audit, lkml, lsm: https://www.redhat.com/archives/linux-audit/2017-October/msg00024.html

[The-Mule]

@rgbriggs Richard, I noticed that there is a manual test associated with this issue. AFAIK its trigger can be automated as follows:

# useradd testuser # su -c 'SUDO_ASKPASS=/bin/true sudo -A date' - testuser

I can create GHAT issue and automatize manual test case if you do not see any issue with aforementioned steps.

[rgbriggs]

On 2017-11-06 11:02, Ondrej Moris wrote:

@rgbriggs Richard, I noticed that there is a manual test associated with this issue. AFAIK its trigger can be automated as follows:

# useradd testuser # su -c 'SUDO_ASKPASS=/bin/true sudo -A date' - testuser

Interesting trick. I'd simplify it down even more from "date" to "echo", which seemsm to also work, but the still nagging question is what unprivileged user would you pick that is on any system? Can you use an existing unprivileged system account with no password rather than creating a throwaway account?

I can create GHAT issue and automatize manual test case if you do not see any issue with aforementioned steps.

Ok, works for me.

[rgbriggs]

Upstreamed via James Morris in the git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general tree 2017-10-20 into v4.15-rc1 ref: http://kernsec.org/pipermail/linux-security-module-archive/2017-October/003836.html

[pcmoore]

Then we should close this out ...