Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: add CWD for file-related LSM_AUDIT_DATA_* #96

Closed
rgbriggs opened this issue Aug 3, 2018 · 14 comments
Closed

RFE: add CWD for file-related LSM_AUDIT_DATA_* #96

rgbriggs opened this issue Aug 3, 2018 · 14 comments

Comments

@rgbriggs
Copy link
Member

rgbriggs commented Aug 3, 2018

The following dump_common_audit_data cases could use a CWD record:
LSM_AUDIT_DATA_PATH
LSM_AUDIT_DATA_FILE
LSM_AUDIT_DATA_IOCTL_OP
LSM_AUDIT_DATA_DENTRY
LSM_AUDIT_DATA_INODE

This should be as simple as calling get_fs_pwd() for these cases.

Another suggestion that was made was to implement an AVC_PATH record.

See also: #65

@nefigtut
Copy link
Contributor

nefigtut commented Mar 24, 2020

The above is a naive straight-forward fix for this issue which just adds "cwd=" field into the "type=AVC" audit record.

I'm not sure if "use a CWD record" above means a separate audit "type=CWD" record. If yes, there will be more work, as "struct audit_context" and friends should be exposed to "security/lsm_audit.c" (now they are internal to "kernel/audit.c") and some analogue of audit_log_exit() should be created for the LSM case (or audit_log_exit() itself exposed and used).

@rgbriggs
Copy link
Member Author

rgbriggs commented Mar 24, 2020 via email

@nefigtut
Copy link
Contributor

nefigtut commented Mar 25, 2020

Hm. This way I do not see a simple solution, unfortunately. It looks like we would need to tweak internal API. This is how I see it. Yes, we can export audit_cwd() and call it in the LSM code. But what would emit this CWD record?

For syscalls it is done by audit_log_exit() which emits a number of records (including the CWD one) at the end of syscall processing. But it is internal (static) to auditsc.c and has syscall-only code, so we cannot call it from the LSM code. As I see it now, we could:

  1. Write an new audit_log_lsm_exit() which has the same code as audit_log_exit() for emitting CWD records, has lsm-only code and is internal to LSM. So it is called at the end of AVC record processing. This forces us to expose struct audit_context as audit_lsm_log_exit() must be able to access audit context fields. Either (which I like more):

  2. We can move common code to audit_log_exit_common(), expose it, make audit_log_syscall_exit() and audit_log_lsm_exit() call it, and call audit_log_lsm_exit() at the end of AVC record processing.

Would you like to see any of these approaches implemented? Or some 3rd one?

@rgbriggs
Copy link
Member Author

rgbriggs commented Mar 25, 2020 via email

@nefigtut
Copy link
Contributor

nefigtut commented Mar 26, 2020

  1. audit context is always NULL if "-a never,task" rule is active, which is default in Fedora. so CWD record won't be emitted.

  2. ghak#120 fix is necessary pre-req as it enables audit context in case when no audit rules are active. with that the resulting fix is rather straight-forward.

  3. testing:

audit context is NULL case (no CWD record):

# uname -r
5.6.0-rc7-vsdau << (with ghak#120 fix and this fix)
# auditctl -l
-a never,task
# chcon system_u:system_r:gpm_t:s0 aaa
chcon: failed to change context of 'aaa' to ‘system_u:system_r:gpm_t:s0’: Permission denied
...
type=AVC msg=audit(1585244338.716:128): avc:  denied  { relabelfrom } for  pid=562 comm="chcon" name="aaa" dev="vda3" ino=33631336 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:system_r:gpm_t:s0 tclass=file permissive=0

# runcon system_u:system_r:gpm_t:s0 cat autest.c 
runcon: ‘cat’: Permission denied
...
type=AVC msg=audit(1585244441.260:129): avc:  denied  { entrypoint } for  pid=565 comm="runcon" path="/usr/bin/cat" dev="vda3" ino=50497724 scontext=system_u:system_r:gpm_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file permissive=0

no audit rules case:

# auditctl -D
No rules
# chcon system_u:system_r:gpm_t:s0 aaa
chcon: failed to change context of 'aaa' to ‘system_u:system_r:gpm_t:s0’: Permission denied
...
type=AVC msg=audit(1585244507.504:131): avc:  denied  { relabelfrom } for  pid=570 comm="chcon" name="aaa" dev="vda3" ino=33631336 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:system_r:gpm_t:s0 tclass=file permissive=0
type=SYSCALL msg=audit(1585244507.504:131): arch=c000003e syscall=188 success=no exit=-13 a0=5597206297a0 a1=7f403a71e726 a2=55972062ac10 a3=1b items=0 ppid=511 pid=570 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="chcon" exe="/usr/bin/chcon" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)ARCH=x86_64 SYSCALL=setxattr AUID="root" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
type=CWD msg=audit(1585244507.504:131): cwd="/root"
type=PROCTITLE msg=audit(1585244507.504:131): proctitle=6368636F6E0073797374656D5F753A73797374656D5F723A67706D5F743A733000616161

# runcon system_u:system_r:gpm_t:s0 cat autest.c 
runcon: ‘cat’: Permission denied
...
type=AVC msg=audit(1585244604.168:132): avc:  denied  { entrypoint } for  pid=571 comm="runcon" path="/usr/bin/cat" dev="vda3" ino=50497724 scontext=system_u:system_r:gpm_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file permissive=0
type=SYSCALL msg=audit(1585244604.168:132): arch=c000003e syscall=59 success=no exit=-13 a0=7fff6574cc00 a1=7fff6574ce38 a2=7fff6574ce50 a3=0 items=0 ppid=511 pid=571 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="runcon" exe="/usr/bin/runcon" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)ARCH=x86_64 SYSCALL=execve AUID="root" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
type=CWD msg=audit(1585244604.168:132): cwd="/root"
type=PROCTITLE msg=audit(1585244604.168:132): proctitle=72756E636F6E0073797374656D5F753A73797374656D5F723A67706D5F743A733000636174006175746573742E63

@pcmoore
Copy link
Member

pcmoore commented Mar 30, 2020

Just as a FYI, patches really should be sent to the relevant kernel mailing lists for discussion.

@nefigtut
Copy link
Contributor

yes, my intent was to have some peer-to-peer or mentor review (by Steve or Richard or someone) of a suggested patch before sending it to a mailing list, as definitely I know little in the audit area as of now. if this is unwelcomed behaviour I'll surely stop.

@pcmoore
Copy link
Member

pcmoore commented Mar 31, 2020

If you send the patch to the mailing list, perhaps with a note that this is just for informal review and not consideration for inclusion into the kernel (yet), then others can more easily benefit from the lessons learned. The number of people following an individual issue tracker is almost always going to be smaller than the number of people following the mailing list.

@nefigtut
Copy link
Contributor

nefigtut commented Apr 2, 2020

thanks, Paul! great, let me try a wider audience:
https://lore.kernel.org/linux-audit/20200402141319.28714-1-vdronov@redhat.com/T/#u

fengguang pushed a commit to 0day-ci/linux that referenced this issue Apr 3, 2020
Set a current working directory in an audit context for the following record
types in dump_common_audit_data(): LSM_AUDIT_DATA_PATH, LSM_AUDIT_DATA_FILE,
LSM_AUDIT_DATA_IOCTL_OP, LSM_AUDIT_DATA_DENTRY, LSM_AUDIT_DATA_INODE so a
separate CWD record is emitted later.

Link: linux-audit/audit-kernel#96
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
@rgbriggs
Copy link
Member Author

rgbriggs commented Jul 3, 2020

fengguang pushed a commit to 0day-ci/linux that referenced this issue Jul 3, 2020
The LSM_AUDIT_DATA_* records for PATH, FILE, IOCTL_OP, DENTRY and INODE
are incomplete without the task context of the AUDIT Current Working
Directory record.  Add it.

This record addition can't use audit_dummy_context to determine whether
or not to store the record information since the LSM_AUDIT_DATA_*
records are initiated by various LSMs independent of any audit rules.
context->in_syscall is used to determine if it was called in user
context like audit_getname.

Please see the upstream issue
linux-audit/audit-kernel#96

Adapted from Vladis Dronov's v2 patch.

Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
pcmoore pushed a commit that referenced this issue Jul 8, 2020
The LSM_AUDIT_DATA_* records for PATH, FILE, IOCTL_OP, DENTRY and INODE
are incomplete without the task context of the AUDIT Current Working
Directory record.  Add it.

This record addition can't use audit_dummy_context to determine whether
or not to store the record information since the LSM_AUDIT_DATA_*
records are initiated by various LSMs independent of any audit rules.
context->in_syscall is used to determine if it was called in user
context like audit_getname.

Please see the upstream issue
#96

Adapted from Vladis Dronov's v2 patch.

Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
@rgbriggs
Copy link
Member Author

rgbriggs commented Jul 27, 2020

fengguang pushed a commit to 0day-ci/linux that referenced this issue Jul 27, 2020
Issue ghak120 enabled syscall records to accompany required records when
no rules are present to trigger the storage of syscall context.  A
reported issue showed that the cwd was not always initialized.  That
issue was already resolved, but a review of all other records that could
be triggered at the time of a syscall record revealed other potential
values that could be missing or misleading.  Initialize them.

The fds array is reset to -1 after the first syscall to indicate it
isn't valid any more, but was never set to -1 when the context was
allocated to indicate it wasn't yet valid.

The audit_inode* functions can be called without going through
getname_flags() or getname_kernel() that sets audit_names and cwd, so
set the cwd if it has not already been done so due to audit_names being
valid.

The LSM dump_common_audit_data() LSM_AUDIT_DATA_NET:AF_UNIX case was
missed with the ghak96 patch, so add that case here.

Please see issue linux-audit/audit-kernel#120
Please see issue linux-audit/audit-kernel#96
Passes audit-testsuite.

Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
@rgbriggs
Copy link
Member Author

fengguang pushed a commit to 0day-ci/linux that referenced this issue Sep 10, 2020
When there are no audit rules registered, mandatory records (config,
etc.) are missing their accompanying records (syscall, proctitle, etc.).

This is due to audit context dummy set on syscall entry based on absence
of rules that signals that no other records are to be printed.

Clear the dummy bit if any record is generated.

The proctitle context and dummy checks are pointless since the
proctitle record will not be printed if no syscall records are printed.

The fds array is reset to -1 after the first syscall to indicate it
isn't valid any more, but was never set to -1 when the context was
allocated to indicate it wasn't yet valid.

The audit_inode* functions can be called without going through
getname_flags() or getname_kernel() that sets audit_names and cwd, so
set the cwd if it has not already been done so due to audit_names being
valid.

The LSM dump_common_audit_data() LSM_AUDIT_DATA_NET:AF_UNIX case was
missed with the ghak96 patch, so add that case here.

Thanks to bauen1 <j2468h@googlemail.com> for reporting LSM situations in
which context->cwd is not valid, inadvertantly fixed by the ghak96 patch.

Please see upstream github issue
linux-audit/audit-kernel#120
This is also related to upstream github issue
linux-audit/audit-kernel#96

Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
@rgbriggs
Copy link
Member Author

fengguang pushed a commit to 0day-ci/linux that referenced this issue Sep 22, 2020
When there are no audit rules registered, mandatory records (config,
etc.) are missing their accompanying records (syscall, proctitle, etc.).

This is due to audit context dummy set on syscall entry based on absence
of rules that signals that no other records are to be printed.  Clear the dummy
bit if any record is generated, open coding this in audit_log_start().

The proctitle context and dummy checks are pointless since the
proctitle record will not be printed if no syscall records are printed.

The fds array is reset to -1 after the first syscall to indicate it
isn't valid any more, but was never set to -1 when the context was
allocated to indicate it wasn't yet valid.

Check ctx->pwd in audit_log_name().

The audit_inode* functions can be called without going through
getname_flags() or getname_kernel() that sets audit_names and cwd, so
set the cwd in audit_alloc_name() if it has not already been done so due to
audit_names being valid and purge all other audit_getcwd() calls.

Revert the LSM dump_common_audit_data() LSM_AUDIT_DATA_* cases from the
ghak96 patch since they are no longer necessary due to cwd coverage in
audit_alloc_name().

Thanks to bauen1 <j2468h@googlemail.com> for reporting LSM situations in
which context->cwd is not valid, inadvertantly fixed by the ghak96 patch.

Please see upstream github issue
linux-audit/audit-kernel#120
This is also related to upstream github issue
linux-audit/audit-kernel#96

Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
pcmoore pushed a commit that referenced this issue Oct 28, 2020
When there are no audit rules registered, mandatory records (config,
etc.) are missing their accompanying records (syscall, proctitle, etc.).

This is due to audit context dummy set on syscall entry based on absence
of rules that signals that no other records are to be printed.  Clear the dummy
bit if any record is generated, open coding this in audit_log_start().

The proctitle context and dummy checks are pointless since the
proctitle record will not be printed if no syscall records are printed.

The fds array is reset to -1 after the first syscall to indicate it
isn't valid any more, but was never set to -1 when the context was
allocated to indicate it wasn't yet valid.

Check ctx->pwd in audit_log_name().

The audit_inode* functions can be called without going through
getname_flags() or getname_kernel() that sets audit_names and cwd, so
set the cwd in audit_alloc_name() if it has not already been done so due to
audit_names being valid and purge all other audit_getcwd() calls.

Revert the LSM dump_common_audit_data() LSM_AUDIT_DATA_* cases from the
ghak96 patch since they are no longer necessary due to cwd coverage in
audit_alloc_name().

Thanks to bauen1 <j2468h@googlemail.com> for reporting LSM situations in
which context->cwd is not valid, inadvertantly fixed by the ghak96 patch.

Please see upstream github issue
#120
This is also related to upstream github issue
#96

Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
@rgbriggs
Copy link
Member Author

This can be closed since this patch went upstream in v5.9-rc1
d7481b2 ("audit: issue CWD record to accompany LSM_AUDIT_DATA_* records")

And further, it ended up being tangled with #120 with this latter's final patch effectively reverting the patch above. In any case, this issue is resolved. ghak120's patches follow:

v5.7-rc1
1320a40 ("audit: trigger accompanying records when no rules present")
v5.8
8ac68dc ("revert: 1320a40 ("audit: trigger accompanying records when no rules present")")
audit/next
6d91547 ("audit: trigger accompanying records when no rules present")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants