[ANNOUNCE][CFP] Linux Security Summit 2021
by James Morris
==============================================================================
ANNOUNCEMENT AND CALL FOR PARTICIPATION
LINUX SECURITY SUMMIT 2021
27-29 September
Dublin, Ireland
==============================================================================
DESCRIPTION
Linux Security Summit (LSS) is a technical forum for collaboration between
Linux developers, researchers, and end-users. Its primary aim is to foster
community efforts in analyzing and solving Linux security challenges.
The program committee currently seeks proposals for:
* Refereed Presentations:
45 minutes in length.
* Panel Discussion Topics:
45 minutes in length.
* Short Topics:
30 minutes in total, including at least 10 minutes discussion.
* Tutorials
90 minutes in length.
Tutorial sessions should be focused on advanced Linux security defense
topics within areas such as the kernel, compiler, and security-related
libraries. Priority will be given to tutorials created for this conference,
and those where the presenter a leading subject matter expert on the topic.
Topic areas include, but are not limited to:
* Kernel self-protection
* Access control
* Cryptography and key management
* Integrity policy and enforcement
* Hardware Security
* IoT and embedded security
* Virtualization and containers
* System-specific system hardening
* Case studies
* Security tools
* Security UX
* Emerging technologies, threats & techniques
Proposals should be submitted via:
https://events.linuxfoundation.org/linux-security-summit-europe/program/cfp/
** Note that for 2021, the North American and European events are combined into
a single event planned for Dublin, Ireland. **
DATES
* CFP close: June 27
* CFP notifications: July 20
* Schedule announced: July 22
* Event: September 27-29
WHO SHOULD ATTEND
We're seeking a diverse range of attendees and welcome participation by
people involved in Linux security development, operations, and research.
LSS is a unique global event that provides the opportunity to present and
discuss your work or research with key Linux security community members and
maintainers. It's also useful for those who wish to keep up with the latest
in Linux security development and to provide input to the development
process.
WEB SITE
https://events.linuxfoundation.org/linux-security-summit-europe/
TWITTER
For event updates and announcements, follow:
https://twitter.com/LinuxSecSummit
#linuxsecuritysummit
PROGRAM COMMITTEE
The program committee for LSS 2021 is:
* James Morris, Microsoft
* Serge Hallyn, Cisco
* Paul Moore, Cisco
* Stephen Smalley, NSA
* Elena Reshetova, Intel
* John Johansen, Canonical
* Kees Cook, Google
* Casey Schaufler, Intel
* Mimi Zohar, IBM
* David A. Wheeler, Institute for Defense Analyses
The program committee may be contacted as a group via email:
lss-pc () lists.linuxfoundation.org
4 years, 6 months
[RFC PATCH 0/4] Split security_task_getsecid() into subj and obj variants
by Paul Moore
As discussed briefly on the list (lore link below), we are a little
sloppy when it comes to using task credentials, mixing both the
subjective and object credentials. This patch set attempts to fix
this by replacing security_task_getsecid() with two new hooks that
return either the subjective (_subj) or objective (_obj) credentials.
https://lore.kernel.org/linux-security-module/806848326.0ifERbkFSE@x2/T/
Casey and John, I made a quick pass through the Smack and AppArmor
code in an effort to try and do the right thing, but I will admit
that I haven't tested those changes, just the SELinux code. I
would really appreciate your help in reviewing those changes. If
you find it easier, feel free to wholesale replace my Smack/AppArmor
patch with one of your own.
---
Paul Moore (4):
lsm: separate security_task_getsecid() into subjective and objective variants
selinux: clarify task subjective and objective credentials
smack: differentiate between subjective and objective task credentials
apparmor: differentiate between subjective and objective task credentials
security/apparmor/domain.c | 2 +-
security/apparmor/include/cred.h | 19 +++++--
security/apparmor/include/task.h | 3 +-
security/apparmor/lsm.c | 23 ++++++---
security/apparmor/task.c | 23 +++++++--
security/selinux/hooks.c | 85 ++++++++++++++++++--------------
security/smack/smack.h | 18 ++++++-
security/smack/smack_lsm.c | 40 ++++++++++-----
8 files changed, 147 insertions(+), 66 deletions(-)
--
Signature
5 years
Audit ipset changes?
by Andreas Hasenack
Hi,
is there a way to audit ipset changes?
The closest I got was to log the specific "socket(AF_NETLINK, SOCK_RAW,
NETLINK_NETFILTER)" call that ipset makes, but that obviously also triggers
read-only operations like "ipset list", and any other app that opens suck a
socket.
5 years
Getting the value of a syscall's memory address argument - setxattr
by Alan Evangelista
Each syscall has some arguments and the Linux Audit framework logs each
pointer argument as a memory address instead of its values. For instance,
when tracking the setxattr syscall, I get its arguments in the following
format:
"a0":"55f3604ba000"
"a1":"7f1b0bd342fd"
"a2":"55f3604d9b20"
"a3":"38"
According to https://man7.org/linux/man-pages/man2/setxattr.2.html, a0 is
the file path's starting memory address, a1 is the extended attribute
name's starting memory address, a2 is the extended attribute
value's starting memory address and a3 is the size in bytes of the extended
attribute value.
Is it safe to access those memory addresses in order to get their values? I
guess not because their content may have been overwritten between the time
the syscall log entry was generated by the kernel and the time it's
consumed by a Linux Audit client. If indeed it's unsafe to access these
memory addresses, is there any other way to get the extended attribute
name/value in the setxattr syscall using the Linux Audit framework?
My specific use case: I'm using Auditbeat/Linux Audit to track permission
changes done to a disk partition which is mounted by Samba on a Windows
Server box. When a Windows user changes permissions of a file in the Samba
mount, Linux Audit records a setxattr event and Auditbeat (connected to the
kernel's Audit framework via netlink) notifies me of the event. I need to
know what permission changes the user has done in the file and AFAIK
parsing the ext attrib name/value is the only way to do that.
Thanks in advance.
5 years
open_by_handle_at and CVE-2020-35501
by Steve Grubb
Hello,
There was an announcement on the oss-security mail list a week ago:
https://seclists.org/oss-sec/2021/q1/155
regarding auditing of the open_by_handle_at system call. They are using a
rule like this:
-a always,exit -F path=/path/to/file -F perm=wr
and expecting that we have an audit record when opened using the
name_to_handle_at/open_by_handle_at syscall pair.
I run a study of my system by adding audit rules for each of the syscalls.
What I found was that the name_to_handle_at seems to be used by systemd and
it only passes a relative file name. This makes the audit event next to
useless.
And interestingly I have no events for open_by_handle_at in spite of systemd
preparing to use it. So, I don't have any idea what the audit event would
look like.
In any event, they are asking what upstream audit is going to do about this?
In looking into open_by_handle_at, I found that it was used in an exploit
against docker some time ago where it was possible to bruteforce the handle.
Of cource you need CAP_DAC_READ_SEARCH to call it.
https://www.programmersought.com/article/54607139735/
I think we should do something, not sure what. Simply adding the syscall to
the open perms machinery will get an event, but probably nothing usable. You
could at least see who is doing it and with what program.
In the meantime, people can use the syscall rules to audit for any occurance.
I think the default rules do include it.
Cheers,
-Steve
5 years
[PATCH v24 00/25] LSM: Module stacking for AppArmor
by Casey Schaufler
This patchset provides the changes required for
the AppArmor security module to stack safely with any other.
v24: Rebase to 5.11-rc1
Incorporate feedback from v23
- Address the IMA team's concerns about "label collisions".
A label collision occurs when there is ambiguity about
which of multiple LSMs is being targeted in the definition
of an integrity check rule. A system with Smack and
AppArmor would be unable to distinguish which LSM is
important to an integrity rule referrencing the label
"unconfined" as that label is meaningful to both.
Provide a boot option to specify which LSM will be used in
IMA rules when multiple LSMs are present. (patch 04)
Pull LSM "slot" identification from later audit patches in
in support of this (patch 03).
- Pick up a few audit events that need to include supplimental
subject context records that had been missed in the
previous version.
v23: Rebase to 5.10-rc4
Incorporate feedback from v22
- Change /proc/*/attr/display to /proc/*/attr/interface_lsm to
make the purpose clearer. (patch 0012)
- Include ABI documentation. (patch 0012, 0022)
- Introduce LSM documentation updates with the patches where
the interfaces are added rather than at the end. (patch 0012, 0022)
Include more maintainers and mail lists in To: and Cc: directives.
v22: Rebase to 5.10-rc1
v21: Rebase to 5.9-rc4
Incorporate feedback from v20
- Further revert UDS SO_PEERSEC to use scaffolding around
the interfaces that use lsmblobs and store only a single
secid. The possibility of multiple security modules
requiring data here is still a future problem.
- Incorporate Richard Guy Briggs' non-syscall auxiliary
records patch (patch 0019-0021) in place of my "supplimental"
records implementation. [I'm not sure I've given proper
attestation. I will correct as appropriate]
v20: Rebase to 5.9-rc1
Change the BPF security module to use the lsmblob data. (patch 0002)
Repair length logic in subject label processing (patch 0015)
Handle -EINVAL from the empty BPF setprocattr hook (patch 0020)
Correct length processing in append_ctx() (patch 0022)
v19: Rebase to 5.8-rc6
Incorporate feedback from v18
- Revert UDS SO_PEERSEC implementation to use lsmblobs
directly, rather than allocating as needed. The correct
treatment of out-of-memory conditions in the later case
is difficult to define. (patch 0005)
- Use a size_t in append_ctx() (patch 0021)
- Fix a memory leak when creating compound contexts. (patch 0021)
Fix build error when CONFIG_SECURITY isn't set (patch 0013)
Fix build error when CONFIG_SECURITY isn't set (patch 0020)
Fix build error when CONFIG_SECURITY isn't set (patch 0021)
v18: Rebase to 5.8-rc3
Incorporate feedback from v17
- Null pointer checking in UDS (patch 0005)
Match changes in IMA code (patch 0012)
Fix the behavior of LSM context supplimental audit
records so that there's always exactly one when it's
appropriate for there to be one. This is a substantial
change that requires extention of the audit_context beyond
syscall events. (patch 0020)
v17: Rebase to 5.7-rc4
v16: Rebase to 5.6
Incorporate feedback from v15 - Thanks Stephen, Mimi and Paul
- Generally improve commit messages WRT scaffolding
- Comment ima_lsm_isset() (patch 0002)
- Some question may remain on IMA warning (patch 0002)
- Mark lsm_slot as __lsm_ro_after_init not __init_data (patch 0002)
- Change name of lsmblob variable in ima_match_rules() (patch 0003)
- Instead of putting a struct lsmblob into the unix_skb_parms
structure put a pointer to an allocated instance. There is
currently only space for 5 u32's in unix_skb_parms and it is
likely to get even tighter. Fortunately, the lifecycle
management of the allocated lsmblob is simple. (patch 0005)
- Dropped Acks due to the above change (patch 0005)
- Improved commentary on secmark labeling scaffolding. (patch 0006)
- Reduced secmark related labeling scaffolding. (patch 0006)
- Replace use of the zeroth entry of an lsmblob in scaffolding
with a function lsmblob_value() to hopefully make it less
obscure. (patch 0006)
- Convert security_secmark_relabel_packet to use lsmblob as
this reduces much of the most contentious scaffolding. (patch 0006)
- Dropped Acks due to the above change (patch 0006)
- Added BUILD_BUG_ON() for CIPSO tag 6. (patch 0018)
- Reworked audit subject information. Instead of adding fields in
the middle of existing records add a new record to the event. When
a separate record is required use subj="?". (patch 0020)
- Dropped Acks due to the above change (patch 0020)
- Reworked audit object information. Instead of adding fields in
the middle of existing records add a new record to the event. When
a separate record is required use obj="?". (patch 0021)
- Dropped Acks due to the above change (patch 0021)
- Enhanced documentation (patch 0022)
- Removed unnecessary error code check in security_getprocattr()
(patch 0021)
v15: Rebase to 5.6-rc1
- Revise IMA data use (patch 0002)
Incorporate feedback from v14
- Fix lockdown module registration naming (patch 0002)
- Revise how /proc/self/attr/context is gathered. (patch 0022)
- Revise access modes on /proc/self/attr/context. (patch 0022)
- Revise documentation on LSM external interfaces. (patch 0022)
v14: Rebase to 5.5-rc5
Incorporate feedback from v13
- Use an array of audit rules (patch 0002)
- Significant change, removed Acks (patch 0002)
- Remove unneeded include (patch 0013)
- Use context.len correctly (patch 0015)
- Reorder code to be more sensible (patch 0016)
- Drop SO_PEERCONTEXT as it's not needed yet (patch 0023)
v13: Rebase to 5.5-rc2
Incorporate feedback from v12
- Print lsmblob size with %z (Patch 0002)
- Convert lockdown LSM initialization. (Patch 0002)
- Restore error check in nft_secmark_compute_secid (Patch 0006)
- Correct blob scaffolding in ima_must_appraise() (Patch 0009)
- Make security_setprocattr() clearer (Patch 0013)
- Use lsm_task_display more widely (Patch 0013)
- Use passed size in lsmcontext_init() (Patch 0014)
- Don't add a smack_release_secctx() hook (Patch 0014)
- Don't print warning in security_release_secctx() (Patch 0014)
- Don't duplicate the label in nfs4_label_init_security() (Patch 0016)
- Remove reviewed-by as code has significant change (Patch 0016)
- Send the entire lsmblob for Tag 6 (Patch 0019)
- Fix description of socket_getpeersec_stream parameters (Patch 0023)
- Retain LSMBLOB_FIRST. What was I thinking? (Patch 0023)
- Add compound context to LSM documentation (Patch 0023)
v12: Rebase to 5.5-rc1
Fixed a couple of incorrect contractions in the text.
v11: Rebase to 5.4-rc6
Incorporate feedback from v10
- Disambiguate reading /proc/.../attr/display by restricting
all use of the interface to the current process.
- Fix a merge error in AppArmor's display attribute check
v10: Ask the security modules if the display can be changed.
v9: There is no version 9
v8: Incorporate feedback from v7
- Minor clean-up in display value management
- refactor "compound" context creation to use a common
append_ctx() function.
v7: Incorporate feedback from v6
- Make setting the display a privileged operation. The
availability of compound contexts reduces the need for
setting the display.
v6: Incorporate feedback from v5
- Add subj_<lsm>= and obj_<lsm>= fields to audit records
- Add /proc/.../attr/context to get the full context in
lsmname\0value\0... format as suggested by Simon McVittie
- Add SO_PEERCONTEXT for getsockopt() to get the full context
in the same format, also suggested by Simon McVittie.
- Add /sys/kernel/security/lsm_display_default to provide
the display default value.
v5: Incorporate feedback from v4
- Initialize the lsmcontext in security_secid_to_secctx()
- Clear the lsmcontext in all security_release_secctx() cases
- Don't use the "display" on strictly internal context
interfaces.
- The SELinux binder hooks check for cases where the context
"display" isn't compatible with SELinux.
v4: Incorporate feedback from v3
- Mark new lsm_<blob>_alloc functions static
- Replace the lsm and slot fields of the security_hook_list
with a pointer to a LSM allocated lsm_id structure. The
LSM identifies if it needs a slot explicitly. Use the
lsm_id rather than make security_add_hooks return the
slot value.
- Validate slot values used in security.c
- Reworked the "display" process attribute handling so that
it works right and doesn't use goofy list processing.
- fix display value check in dentry_init_security
- Replace audit_log of secids with '?' instead of deleting
the audit log
v3: Incorporate feedback from v2
- Make lsmblob parameter and variable names more
meaningful, changing "le" and "l" to "blob".
- Improve consistency of constant naming.
- Do more sanity checking during LSM initialization.
- Be a bit clearer about what is temporary scaffolding.
- Rather than clutter security_getpeersec_dgram with
otherwise unnecessary checks remove the apparmor
stub, which does nothing useful.
Patch 01 moves management of the sock security blob
from the individual modules to the infrastructure.
Patches 02-03 introduce a structure "lsmblob" that will gradually
replace the "secid" as a shorthand for security module information.
At this point lsmblob contains an array of u32 secids, one "slot"
for each of the security modules compiled into the kernel that
used secids. A "slot" is allocated when a security module requests
one.
Patch 04 provides mechanism for the IMA subsystem to identify
explicitly which LSM is subject to IMA policy. This includes
a boot option for specifying the default and an additional option
in IMA rules "lsm=".
Patches 05-13 change LSM interfaces to use the lsmblob instead
of secids. It is important that the lsmblob be a fixed size entity
that does not have to be allocated. Several of the places
where it is used would have performance and/or locking
issues with dynamic allocation.
Patch 14 provides a mechanism for a process to identify which
security module's hooks should be used when displaying or
converting a security context string. A new interface
/proc/self/attr/interface_lsm contains the name of the security
module to show. Reading from this file will present the name of
the module, while writing to it will set the value. Only names
of active security modules are accepted. Internally, the name
is translated to the appropriate "slot" number for the module
which is then stored in the task security blob. Setting the
display requires that all modules using the /proc interfaces
allow the transition. The interface LSM of other processess
can be neither read nor written. All suggested cases for
reading the interface LSM of a different process have race
conditions.
Patch 15 Starts the process of changing how a security
context is represented. Since it is possible for a
security context to have been generated by more than one
security module it is now necessary to note which module
created a security context so that the correct "release"
hook can be called. There are several places where the
module that created a security context cannot be inferred.
This is achieved by introducing a "lsmcontext" structure
which contains the context string, its length and the
"slot" number of the security module that created it.
The security_release_secctx() interface is changed,
replacing the (string,len) pointer pair with a lsmcontext
pointer.
Patches 16-18 convert the security interfaces from
(string,len) pointer pairs to a lsmcontext pointer.
The slot number identifying the creating module is
added by the infrastructure. Where the security context
is stored for extended periods the data type is changed.
The Netlabel code is converted to save lsmblob structures
instead of secids in Patch 19. This is not strictly
necessary as there can only be one security module that
uses Netlabel at this point. Using a lsmblob is much
cleaner, as the interfaces that use the data have all
been converted.
Patch 20 adds checks to the binder hooks which verify
that both ends of a transaction use the same interface LSM.
Patches 21-23 add addition audit records for subject and
object LSM data when there are multiple security modules
with such data. The AUDIT_MAC_TASK_CONTEXTS record is used
in conjuction with a "subj=?" field to identify the subject
data. The AUDIT_MAC_OBJ_CONTEXTS record is used in conjuction
with a "obj=?" field to identify the object data. The
AUDIT_MAC_TASK_CONTEXTS record identifies the security module
with the data: "subj_selinux=xyz_t subj_apparmor=abc". The
AUDIT_MAC_OBJ_CONTEXTS record identifies the security module
with the data: "obj_selinux=xyz_t obj_apparmor=abc". While
AUDIT_MAC_TASK_CONTEXTS records will always contain an entry
for each possible security modules, AUDIT_MAC_OBJ_CONTEXTS
records will only contain entries for security modules for
which the object in question has data.
An example of the MAC_TASK_CONTEXTS (1420) record is:
type=UNKNOWN[1420]
msg=audit(1600880931.832:113)
subj_apparmor==unconfined
subj_smack=_
An example of the MAC_OBJ_CONTEXTS (1421) record is:
type=UNKNOWN[1421]
msg=audit(1601152467.009:1050):
obj_selinux=unconfined_u:object_r:user_home_t:s0
Patch 24 adds a new interface for getting the compound security
contexts, /proc/self/attr/context. An example of the content
of this file is:
selinux\0one_u:one_r:one_t:s0-s0:c0.c1023\0apparmor\0unconfined\0
Finally, with all interference on the AppArmor hooks removed,
Patch 25 removes the exclusive bit from AppArmor. An unnecessary
stub hook was also removed.
The Ubuntu project is using an earlier version of this patchset in
their distribution to enable stacking for containers.
Performance measurements to date have the change within the "noise".
The sockperf and dbench results are on the order of 0.2% to 0.8%
difference, with better performance being as common as worse. The
benchmarks were run with AppArmor and Smack on Ubuntu.
https://github.com/cschaufler/lsm-stacking.git#stack-5.11-rc1-v24
Signed-off-by: Casey Schaufler <casey(a)schaufler-ca.com>
Casey Schaufler (25):
LSM: Infrastructure management of the sock security
LSM: Add the lsmblob data structure.
LSM: provide lsm name and id slot mappings
IMA: avoid label collisions with stacked LSMs
LSM: Use lsmblob in security_audit_rule_match
LSM: Use lsmblob in security_kernel_act_as
LSM: Use lsmblob in security_secctx_to_secid
LSM: Use lsmblob in security_secid_to_secctx
LSM: Use lsmblob in security_ipc_getsecid
LSM: Use lsmblob in security_task_getsecid
LSM: Use lsmblob in security_inode_getsecid
LSM: Use lsmblob in security_cred_getsecid
IMA: Change internal interfaces to use lsmblobs
LSM: Specify which LSM to display
LSM: Ensure the correct LSM context releaser
LSM: Use lsmcontext in security_secid_to_secctx
LSM: Use lsmcontext in security_inode_getsecctx
LSM: security_secid_to_secctx in netlink netfilter
NET: Store LSM netlabel data in a lsmblob
LSM: Verify LSM display sanity in binder
audit: add support for non-syscall auxiliary records
Audit: Add new record for multiple process LSM attributes
Audit: Add a new record for multiple object LSM attributes
LSM: Add /proc attr entry for full LSM context
AppArmor: Remove the exclusive flag
Documentation/ABI/testing/ima_policy | 8 +-
Documentation/ABI/testing/procfs-attr-context | 14 +
.../ABI/testing/procfs-attr-lsm_display | 22 +
Documentation/security/lsm.rst | 28 +
drivers/android/binder.c | 26 +-
fs/ceph/xattr.c | 6 +-
fs/nfs/nfs4proc.c | 8 +-
fs/nfsd/nfs4xdr.c | 20 +-
fs/proc/base.c | 2 +
include/linux/audit.h | 43 +-
include/linux/cred.h | 3 +-
include/linux/lsm_hooks.h | 36 +-
include/linux/security.h | 185 +++++-
include/net/netlabel.h | 11 +-
include/net/scm.h | 15 +-
include/net/xfrm.h | 13 +-
include/uapi/linux/audit.h | 2 +
kernel/audit.c | 175 ++++--
kernel/audit.h | 11 +-
kernel/auditfilter.c | 36 +-
kernel/auditsc.c | 191 +++---
kernel/cred.c | 12 +-
net/ipv4/cipso_ipv4.c | 26 +-
net/ipv4/ip_sockglue.c | 12 +-
net/netfilter/nf_conntrack_netlink.c | 24 +-
net/netfilter/nf_conntrack_standalone.c | 11 +-
net/netfilter/nfnetlink_queue.c | 38 +-
net/netfilter/nft_meta.c | 10 +-
net/netfilter/xt_SECMARK.c | 7 +-
net/netlabel/netlabel_domainhash.c | 4 +-
net/netlabel/netlabel_kapi.c | 6 +-
net/netlabel/netlabel_unlabeled.c | 106 ++--
net/netlabel/netlabel_unlabeled.h | 2 +-
net/netlabel/netlabel_user.c | 23 +-
net/netlabel/netlabel_user.h | 2 +-
net/xfrm/xfrm_policy.c | 10 +-
net/xfrm/xfrm_state.c | 20 +-
security/apparmor/include/apparmor.h | 3 +-
security/apparmor/include/net.h | 6 +-
security/apparmor/include/procattr.h | 2 +-
security/apparmor/lsm.c | 105 ++--
security/apparmor/procattr.c | 22 +-
security/bpf/hooks.c | 12 +-
security/commoncap.c | 7 +-
security/integrity/ima/ima.h | 15 +-
security/integrity/ima/ima_api.c | 17 +-
security/integrity/ima/ima_appraise.c | 6 +-
security/integrity/ima/ima_main.c | 54 +-
security/integrity/ima/ima_policy.c | 97 ++-
security/integrity/integrity_audit.c | 6 +-
security/loadpin/loadpin.c | 8 +-
security/lockdown/lockdown.c | 7 +-
security/safesetid/lsm.c | 8 +-
security/security.c | 561 ++++++++++++++++--
security/selinux/hooks.c | 99 ++--
security/selinux/include/classmap.h | 2 +-
security/selinux/include/objsec.h | 5 +
security/selinux/include/security.h | 1 +
security/selinux/netlabel.c | 25 +-
security/selinux/ss/services.c | 4 +-
security/smack/smack.h | 6 +
security/smack/smack_access.c | 2 +-
security/smack/smack_lsm.c | 91 +--
security/smack/smack_netfilter.c | 8 +-
security/smack/smackfs.c | 13 +-
security/tomoyo/tomoyo.c | 8 +-
security/yama/yama_lsm.c | 7 +-
67 files changed, 1741 insertions(+), 634 deletions(-)
create mode 100644 Documentation/ABI/testing/procfs-attr-context
create mode 100644 Documentation/ABI/testing/procfs-attr-lsm_display
--
2.25.4
5 years
[GIT PULL] Audit patches for v5.12
by Paul Moore
Hi Linus,
Three very trivial patches for audit this time. All pass the
audit-testsuite and apply cleanly to your tree as of a few minutes
ago; please merge these for v5.12.
Thanks,
-Paul
--
The following changes since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62:
Linux 5.11-rc2 (2021-01-03 15:55:30 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
tags/audit-pr-20210215
for you to fetch changes up to 127c8c5f0589cea2208c329bff7dcb36e375f46c:
audit: Make audit_filter_syscall() return void (2021-01-27 21:55:14 -0500)
----------------------------------------------------------------
audit/stable-5.12 PR 20210215
----------------------------------------------------------------
Davidlohr Bueso (1):
audit: Remove leftover reference to the audit_tasklet
Yang Yang (1):
audit: Make audit_filter_syscall() return void
Zheng Yongjun (1):
kernel/audit: convert comma to semicolon
kernel/audit.c | 4 ++--
kernel/auditsc.c | 16 ++++++++--------
2 files changed, 10 insertions(+), 10 deletions(-)
--
paul moore
www.paul-moore.com
5 years
security_task_getsecid() and subjective vs objective task creds
by Paul Moore
Hi all,
When looking into a problem I noticed that audit was recording the
wrong subject label for a process. Doing a bit of digging I realized
this was caused by the SELinux security_task_getsecid() implementation
returning the objective security label (taken from task->real_cred),
and not the subjective security label (taken from task->cred).
Looking around at the other LSMs which implement this hook, Smack and
AppArmor, it appears they both do the same thing: return the objective
security ID for the process. Looking quickly at the various non-LSM
callers of the security_task_getsecid() hook, it unfortunately looks
like all of them expect the subjective security ID to be returned.
The only caller I'm not 100% confident in is binder, but from what I
can tell it looks like they are expecting the subjective ID too.
At least we are consistently wrong :)
How do we want to fix this? The obvious fix is to change the SELinux,
AppArmor, and Smack security_task_getsecid() implementations to return
the subjective security ID (->cred), and likely make a note in
lsm_hooks.h, but if someone can see a case where we would need both
the subjective and objective security labels speak up and we can
introduce a new hook for the subjective label, and likely add a "_obj"
to the end of the existing hook to help make it more clear. If
neither of those options are acceptable, we could convert all of the
existing callers to use something like the line below (assumes
current), but that is the least appealing option as far as I'm
concerned.
security_cred_getsecid(current_cred(), &sid);
Opinions?
--
paul moore
www.paul-moore.com
5 years
[PATCH ghak124 v3] audit: log nftables configuration change events
by Richard Guy Briggs
iptables, ip6tables, arptables and ebtables table registration,
replacement and unregistration configuration events are logged for the
native (legacy) iptables setsockopt api, but not for the
nftables netlink api which is used by the nft-variant of iptables in
addition to nftables itself.
Add calls to log the configuration actions in the nftables netlink api.
This uses the same NETFILTER_CFG record format but overloads the table
field.
type=NETFILTER_CFG msg=audit(2020-05-28 17:46:41.878:162) : table=?:0;?:0 family=unspecified entries=2 op=nft_register_gen pid=396 subj=system_u:system_r:firewalld_t:s0 comm=firewalld
...
type=NETFILTER_CFG msg=audit(2020-05-28 17:46:41.878:162) : table=firewalld:1;?:0 family=inet entries=0 op=nft_register_table pid=396 subj=system_u:system_r:firewalld_t:s0 comm=firewalld
...
type=NETFILTER_CFG msg=audit(2020-05-28 17:46:41.911:163) : table=firewalld:1;filter_FORWARD:85 family=inet entries=8 op=nft_register_chain pid=396 subj=system_u:system_r:firewalld_t:s0 comm=firewalld
...
type=NETFILTER_CFG msg=audit(2020-05-28 17:46:41.911:163) : table=firewalld:1;filter_FORWARD:85 family=inet entries=101 op=nft_register_rule pid=396 subj=system_u:system_r:firewalld_t:s0 comm=firewalld
...
type=NETFILTER_CFG msg=audit(2020-05-28 17:46:41.911:163) : table=firewalld:1;__set0:87 family=inet entries=87 op=nft_register_setelem pid=396 subj=system_u:system_r:firewalld_t:s0 comm=firewalld
...
type=NETFILTER_CFG msg=audit(2020-05-28 17:46:41.911:163) : table=firewalld:1;__set0:87 family=inet entries=0 op=nft_register_set pid=396 subj=system_u:system_r:firewalld_t:s0 comm=firewalld
For further information please see issue
https://github.com/linux-audit/audit-kernel/issues/124
Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com>
---
Changelog:
v3:
- inline message type rather than table
v2:
- differentiate between xtables and nftables
- add set, setelem, obj, flowtable, gen
- use nentries field as appropriate per type
- overload the "tables" field with table handle and chain/set/flowtable
include/linux/audit.h | 18 ++++++++
kernel/auditsc.c | 24 ++++++++--
net/netfilter/nf_tables_api.c | 103 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 142 insertions(+), 3 deletions(-)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 3fcd9ee49734..604ede630580 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -12,6 +12,7 @@
#include <linux/sched.h>
#include <linux/ptrace.h>
#include <uapi/linux/audit.h>
+#include <uapi/linux/netfilter/nf_tables.h>
#define AUDIT_INO_UNSET ((unsigned long)-1)
#define AUDIT_DEV_UNSET ((dev_t)-1)
@@ -98,6 +99,23 @@ enum audit_nfcfgop {
AUDIT_XT_OP_REGISTER,
AUDIT_XT_OP_REPLACE,
AUDIT_XT_OP_UNREGISTER,
+ AUDIT_NFT_OP_TABLE_REGISTER,
+ AUDIT_NFT_OP_TABLE_UNREGISTER,
+ AUDIT_NFT_OP_CHAIN_REGISTER,
+ AUDIT_NFT_OP_CHAIN_UNREGISTER,
+ AUDIT_NFT_OP_RULE_REGISTER,
+ AUDIT_NFT_OP_RULE_UNREGISTER,
+ AUDIT_NFT_OP_SET_REGISTER,
+ AUDIT_NFT_OP_SET_UNREGISTER,
+ AUDIT_NFT_OP_SETELEM_REGISTER,
+ AUDIT_NFT_OP_SETELEM_UNREGISTER,
+ AUDIT_NFT_OP_GEN_REGISTER,
+ AUDIT_NFT_OP_OBJ_REGISTER,
+ AUDIT_NFT_OP_OBJ_UNREGISTER,
+ AUDIT_NFT_OP_OBJ_RESET,
+ AUDIT_NFT_OP_FLOWTABLE_REGISTER,
+ AUDIT_NFT_OP_FLOWTABLE_UNREGISTER,
+ AUDIT_NFT_OP_INVALID,
};
extern int is_audit_feature_set(int which);
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 468a23390457..3a9100e95fda 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -75,6 +75,7 @@
#include <linux/uaccess.h>
#include <linux/fsnotify_backend.h>
#include <uapi/linux/limits.h>
+#include <uapi/linux/netfilter/nf_tables.h>
#include "audit.h"
@@ -136,9 +137,26 @@ struct audit_nfcfgop_tab {
};
static const struct audit_nfcfgop_tab audit_nfcfgs[] = {
- { AUDIT_XT_OP_REGISTER, "register" },
- { AUDIT_XT_OP_REPLACE, "replace" },
- { AUDIT_XT_OP_UNREGISTER, "unregister" },
+ { AUDIT_XT_OP_REGISTER, "xt_register" },
+ { AUDIT_XT_OP_REPLACE, "xt_replace" },
+ { AUDIT_XT_OP_UNREGISTER, "xt_unregister" },
+ { AUDIT_NFT_OP_TABLE_REGISTER, "nft_register_table" },
+ { AUDIT_NFT_OP_TABLE_UNREGISTER, "nft_unregister_table" },
+ { AUDIT_NFT_OP_CHAIN_REGISTER, "nft_register_chain" },
+ { AUDIT_NFT_OP_CHAIN_UNREGISTER, "nft_unregister_chain" },
+ { AUDIT_NFT_OP_RULE_REGISTER, "nft_register_rule" },
+ { AUDIT_NFT_OP_RULE_UNREGISTER, "nft_unregister_rule" },
+ { AUDIT_NFT_OP_SET_REGISTER, "nft_register_set" },
+ { AUDIT_NFT_OP_SET_UNREGISTER, "nft_unregister_set" },
+ { AUDIT_NFT_OP_SETELEM_REGISTER, "nft_register_setelem" },
+ { AUDIT_NFT_OP_SETELEM_UNREGISTER, "nft_unregister_setelem" },
+ { AUDIT_NFT_OP_GEN_REGISTER, "nft_register_gen" },
+ { AUDIT_NFT_OP_OBJ_REGISTER, "nft_register_obj" },
+ { AUDIT_NFT_OP_OBJ_UNREGISTER, "nft_unregister_obj" },
+ { AUDIT_NFT_OP_OBJ_RESET, "nft_reset_obj" },
+ { AUDIT_NFT_OP_FLOWTABLE_REGISTER, "nft_register_flowtable" },
+ { AUDIT_NFT_OP_FLOWTABLE_UNREGISTER, "nft_unregister_flowtable" },
+ { AUDIT_NFT_OP_INVALID, "nft_invalid" },
};
static int audit_match_perm(struct audit_context *ctx, int mask)
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 3558e76e2733..b9e7440cc87d 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -12,6 +12,7 @@
#include <linux/netlink.h>
#include <linux/vmalloc.h>
#include <linux/rhashtable.h>
+#include <linux/audit.h>
#include <linux/netfilter.h>
#include <linux/netfilter/nfnetlink.h>
#include <linux/netfilter/nf_tables.h>
@@ -693,6 +694,16 @@ static void nf_tables_table_notify(const struct nft_ctx *ctx, int event)
{
struct sk_buff *skb;
int err;
+ char *buf = kasprintf(GFP_KERNEL, "%s:%llu;?:0",
+ ctx->table->name, ctx->table->handle);
+
+ audit_log_nfcfg(buf,
+ ctx->family,
+ ctx->table->use,
+ event == NFT_MSG_NEWTABLE ?
+ AUDIT_NFT_OP_TABLE_REGISTER :
+ AUDIT_NFT_OP_TABLE_UNREGISTER);
+ kfree(buf);
if (!ctx->report &&
!nfnetlink_has_listeners(ctx->net, NFNLGRP_NFTABLES))
@@ -1428,6 +1439,17 @@ static void nf_tables_chain_notify(const struct nft_ctx *ctx, int event)
{
struct sk_buff *skb;
int err;
+ char *buf = kasprintf(GFP_KERNEL, "%s:%llu;%s:%llu",
+ ctx->table->name, ctx->table->handle,
+ ctx->chain->name, ctx->chain->handle);
+
+ audit_log_nfcfg(buf,
+ ctx->family,
+ ctx->chain->use,
+ event == NFT_MSG_NEWCHAIN ?
+ AUDIT_NFT_OP_CHAIN_REGISTER :
+ AUDIT_NFT_OP_CHAIN_UNREGISTER);
+ kfree(buf);
if (!ctx->report &&
!nfnetlink_has_listeners(ctx->net, NFNLGRP_NFTABLES))
@@ -2691,6 +2713,17 @@ static void nf_tables_rule_notify(const struct nft_ctx *ctx,
{
struct sk_buff *skb;
int err;
+ char *buf = kasprintf(GFP_KERNEL, "%s:%llu;%s:%llu",
+ ctx->table->name, ctx->table->handle,
+ ctx->chain->name, ctx->chain->handle);
+
+ audit_log_nfcfg(buf,
+ ctx->family,
+ rule->handle,
+ event == NFT_MSG_NEWRULE ?
+ AUDIT_NFT_OP_RULE_REGISTER :
+ AUDIT_NFT_OP_RULE_UNREGISTER);
+ kfree(buf);
if (!ctx->report &&
!nfnetlink_has_listeners(ctx->net, NFNLGRP_NFTABLES))
@@ -3693,6 +3726,17 @@ static void nf_tables_set_notify(const struct nft_ctx *ctx,
struct sk_buff *skb;
u32 portid = ctx->portid;
int err;
+ char *buf = kasprintf(gfp_flags, "%s:%llu;%s:%llu",
+ ctx->table->name, ctx->table->handle,
+ set->name, set->handle);
+
+ audit_log_nfcfg(buf,
+ ctx->family,
+ set->field_count,
+ event == NFT_MSG_NEWSET ?
+ AUDIT_NFT_OP_SET_REGISTER :
+ AUDIT_NFT_OP_SET_UNREGISTER);
+ kfree(buf);
if (!ctx->report &&
!nfnetlink_has_listeners(ctx->net, NFNLGRP_NFTABLES))
@@ -4809,6 +4853,17 @@ static void nf_tables_setelem_notify(const struct nft_ctx *ctx,
u32 portid = ctx->portid;
struct sk_buff *skb;
int err;
+ char *buf = kasprintf(GFP_KERNEL, "%s:%llu;%s:%llu",
+ ctx->table->name, ctx->table->handle,
+ set->name, set->handle);
+
+ audit_log_nfcfg(buf,
+ ctx->family,
+ set->handle,
+ event == NFT_MSG_NEWSETELEM ?
+ AUDIT_NFT_OP_SETELEM_REGISTER :
+ AUDIT_NFT_OP_SETELEM_UNREGISTER);
+ kfree(buf);
if (!ctx->report && !nfnetlink_has_listeners(net, NFNLGRP_NFTABLES))
return;
@@ -5890,6 +5945,19 @@ static int nf_tables_dump_obj(struct sk_buff *skb, struct netlink_callback *cb)
obj->ops->type->type != filter->type)
goto cont;
+ if (reset) {
+ char *buf = kasprintf(GFP_KERNEL,
+ "%s:%llu;?:0",
+ table->name,
+ table->handle);
+
+ audit_log_nfcfg(buf,
+ family,
+ obj->handle,
+ AUDIT_NFT_OP_OBJ_RESET);
+ kfree(buf);
+ }
+
if (nf_tables_fill_obj_info(skb, net, NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq,
NFT_MSG_NEWOBJ,
@@ -6000,6 +6068,17 @@ static int nf_tables_getobj(struct net *net, struct sock *nlsk,
if (NFNL_MSG_TYPE(nlh->nlmsg_type) == NFT_MSG_GETOBJ_RESET)
reset = true;
+ if (reset) {
+ char *buf = kasprintf(GFP_KERNEL, "%s:%llu;?:0",
+ table->name, table->handle);
+
+ audit_log_nfcfg(buf,
+ family,
+ obj->handle,
+ AUDIT_NFT_OP_OBJ_RESET);
+ kfree(buf);
+ }
+
err = nf_tables_fill_obj_info(skb2, net, NETLINK_CB(skb).portid,
nlh->nlmsg_seq, NFT_MSG_NEWOBJ, 0,
family, table, obj, reset);
@@ -6075,6 +6154,16 @@ void nft_obj_notify(struct net *net, const struct nft_table *table,
{
struct sk_buff *skb;
int err;
+ char *buf = kasprintf(GFP_KERNEL, "%s:%llu;?:0",
+ table->name, table->handle);
+
+ audit_log_nfcfg(buf,
+ family,
+ obj->handle,
+ event == NFT_MSG_NEWOBJ ?
+ AUDIT_NFT_OP_OBJ_REGISTER :
+ AUDIT_NFT_OP_OBJ_UNREGISTER);
+ kfree(buf);
if (!report &&
!nfnetlink_has_listeners(net, NFNLGRP_NFTABLES))
@@ -6701,6 +6790,17 @@ static void nf_tables_flowtable_notify(struct nft_ctx *ctx,
{
struct sk_buff *skb;
int err;
+ char *buf = kasprintf(GFP_KERNEL, "%s:%llu;%s:%llu",
+ flowtable->table->name, flowtable->table->handle,
+ flowtable->name, flowtable->handle);
+
+ audit_log_nfcfg(buf,
+ ctx->family,
+ flowtable->hooknum,
+ event == NFT_MSG_NEWFLOWTABLE ?
+ AUDIT_NFT_OP_FLOWTABLE_REGISTER :
+ AUDIT_NFT_OP_FLOWTABLE_UNREGISTER);
+ kfree(buf);
if (ctx->report &&
!nfnetlink_has_listeners(ctx->net, NFNLGRP_NFTABLES))
@@ -6822,6 +6922,9 @@ static void nf_tables_gen_notify(struct net *net, struct sk_buff *skb,
struct sk_buff *skb2;
int err;
+ audit_log_nfcfg("?:0;?:0", 0, net->nft.base_seq,
+ AUDIT_NFT_OP_GEN_REGISTER);
+
if (nlmsg_report(nlh) &&
!nfnetlink_has_listeners(net, NFNLGRP_NFTABLES))
return;
--
1.8.3.1
5 years
Building user-space audit
by Alan Evangelista
I'm trying to build the user-space part of the Linux Auditing Framework in
https://github.com/linux-audit/audit-userspace. First, the README tells me
to "see the README-install file" for building instructions and there is no
such file.
Second, I tried the standard build procedure using autotools:
aclocal; autoconf; automake; ./configure; make
./configure fails with the following error message:
configure: error: zos remote support was requested but the openldap library
was not found
- Is there any out-of-the-box way to build a *minimal* auditd for the
x86_64 platform or I'd need to remove non-essential features such as zos
remote support manually (in this case, removing it from configure.ac) ?
- If there is not, where are the build dependencies documented?
Thanks in advance.
5 years, 1 month
