Is there a way to find out if and in case which linux security LSM (apparmor, selinux, grsecurity) is used by the kernel? To be more specific let's assume I am a legimate root user of the machine? If information available also it would be nice to furthermore know: With regard to the question, is there a difference with considering the machine being (a) a local computer, (b) a dedicated server and (c) a virtual server "vServer" ## update ## I know that I could for instance install the user-space stuff (on a debian for instance apt-get install apparmor) and check if it yields results related to the specific LSM. So I could do for apparmor sudo apparmor_status which would then for instance yield: apparmor module is not loaded. which helps me rule out that option. Yet I was looking for a more general approach covering most/all LSM. ## update2 ## I have discovered the path /sys/kernel/security. Maybe this is helpful finding an answer?

I have a binary program that creates an empty folder in the HOME directory everytime it starts up. I don't like that and want to use the [SMACK](https://www.kernel.org/doc/html/latest/admin-guide/LSM/Smack.html) mechanism to stop it from doing that. My idea is to label the HOME directory with tag HOME and the program process with tag NoWriteHome, then write three SMACK rules:

$ sudo setfattr -n security.SMACK64     -v 'HOME'        "/home/${USER}"
$ sudo setfattr -n security.SMACK64EXEC -v 'NoWriteHome' "${PATH_TO_EXECUTABLE}"
$ cat  _           HOME    rwxat
> NoWriteHome _       rwxat
> NoWriteHome HOME    r-x--
> EOF

I did an experiment on /usr/bin/bash and it worked as expected:

$ cd
$ touch a
touch: cannot touch 'a': Permission denied

But when it comes to the program, it failed to start while loading dynamic libraries:

$ (
> export QT_PLUGIN_PATH="/opt/Wolfram/WolframEngine/14.0/SystemFiles/Libraries/Linux-x86-64/Qt/plugins/"
> export LD_LIBRARY_PATH="/opt/Wolfram/WolframEngine/14.0/SystemFiles/Libraries/Linux-x86-64:/opt/Wolfram/WolframEngine/14.0/SystemFiles/Libraries/Linux-x86-64/Qt/lib"
> export PATH="/opt/Wolfram/WolframEngine/14.0/Executables:${PATH}"
> export ESPEAK_DATA="/opt/Wolfram/WolframEngine/14.0/SystemFiles/FrontEnd/SystemResources/X/espeak-data"
> /opt/Wolfram/WolframEngine/14.0/SystemFiles/FrontEnd/Binaries/Linux-x86-64/WolframPlayer -topDirectory /opt/Wolfram/WolframEngine/14.0
> )
/opt/Wolfram/WolframEngine/14.0/SystemFiles/FrontEnd/Binaries/Linux-x86-64/WolframPlayer: error while loading shared libraries: libML64i4.so: cannot open shared object file: No such file or directory

Does anyone know why access to library files is denied? Is there something wrong with my SMACK rules?

I am writing an LSM, and I am compiling it using my kernel 6.2.0-20-generic. When I browse the files in /lib/modules/6.2.0-20-generic/build, I can see that there is a struct named lsm_id. But When I examine the recent Linux source tree in Github, I can not see this struct. I tried downloading a different version but I could not find this struct anywhere in any of the Linux kernel source codes. I can see that there is a patch that has been released this year but I am not sure why I can not see it in the source tree and how it got in my kernel source code in /lib/modules? I want to have the source code of the kernel with patches applied, is there any way to get that? Link for the patch https://patchwork.kernel.org/project/linux-security-module/patch/20211124014332.36128-4-casey@schaufler-ca.com/ Thanks!

I want to restrict access to files in /proc as much as possible using SELinux. When I try to chcon a directory in /proc, it fails:

$ chcon -t staff_proc_t /proc/acpi
chcon: failed to change context of '/proc/acpi' to ‘system_u:object_r:staff_proc_t’: Operation not supported

Apparently, the /proc filesystem does not allow changing the context directly. How can I set SELinux contexts on /proc entries? If that is not possible, I would like to prohibit access to these files by other means. I would like to hide mountpoint information, ACPI directory, /proc/config.gz etc.

I'm interested to write a kernel program that can have all possible controls on syscalls, such as intersection, filtering, and make changes in their arguments. I look up for two goals: 1. read system calls and their arguments and decide to block or allow them according to a policy. 2. have access to change their argument and pass them to the user. In fact (I do not know if this allegory is true or not?), I want to do something like simple virtualization for a process that can change its view to the kernel and its system calling (like it requested a file in "/tmp/new_folder/foo.txt" by open syscall and we return "/tmp/another_folder/foo2.txt" instead). I insist that this be done with ebpf. But if there is another way, I would welcome it. Also, I should say, I know the usage of **bcc** in this case. it seems to designed for tracing but not filtering and influencing. as well as I tried **seccomp** and it is better than bcc, but seccomp can't be used for access arguments and it is an important factor for me. so I think my answer may be in something like **lsm**. but I don't know how and didn't find any good doc for it. Thanks for any help.

I'm using ebpf and bcc to write an ebpf-lsm program. I want to block a connected USB device and send its info to userspace and the user send me whether I bind that device or no. how can I do this? I know using ebpf maps we can receive data from userspace, well how can I wait for that? in another word, how can I block ebpf program until user responses? thank you for any guidness!

can someone explain to me why SELinux is officially broken under Ubuntu while AppArmor works fine ? AppArmor is build on the "Linux Security Modules" framework and so is SELinux. As a result, shouldn't both run smoothly under Ubuntu? I probably have a wrong understanding of the "Linux Security Modules" framework. Thanks!

What is the core [or kernel level] difference of SELinux and Apparmor?

I know this is kind of an odd question. An IDS/IPS basically autonomously recognizes and optionally prevents intrusions. And while SELinux and AppArmor seem to be trying to do the same, they are never labelled as IDS/IPS. Am I missing something? This is a purely academic question. Would such tool be considered Host Based IDS/IPS?

I'm currently developing a Linux Security Module which is stored in the security directory of the kernel source tree. When I compile and install the kernel using the following commands, the module is loaded and everything is working fine:

fakeroot make -j9 -f debian/rules.gen binary-arch_amd64_none_amd64
apt remove linux-image-4.19.0-9-amd64-unsigned 
dpkg -i linux-image-4.19.0-9-amd64-unsigned_4.19.118-2_amd64.deb

If I make the changes to the module and rebuild the kernel using the commands above however, they won't be included in the new image, unless I delete all build output and recompile the whole kernel. Is there a way to only rebuild a specific part of the kernel i.e. only the security directory?

I want to intercept event and then modify output. So main question not about how to get notification about event, but how to modify output. **Example** Content of file.txt Current user is When some app owned by user (or by user with group that have access) will try to read file, app will get modified (by listener process) content for example Current user is name_of_user

There are two groups of LSM hooks under Security hooks for inode operations : inode_* and path_*. Many of them look identical. For example, inode_link and path_link. What is the difference between the inode and path hooks? When each should be used?

The Yama security module is supposed to be able to prevent users from running the ptrace system call, yet even with kernel.yama.ptrace_scope set to 3, users can still run strace (which uses ptrace). From the docs: 3 - no attach: no processes may use ptrace with PTRACE_ATTACH nor via PTRACE_TRACEME. Once set, this sysctl value cannot be changed. The Yama module does seem to be loaded: /var/log/dmesg:[ 0.000127] Yama: becoming mindful. This is on RHEL7, with SELinux also installed, which may be relevant. LSMs are supposed to be stackable, and I am seeing the above message in dmesg, so it appears to be active. As an aside, once set to 3, the sysctl value is immutable - I don't know if that implies that the Yama module is active or not. Interestingly, on Ubuntu (without Apparmor, I believe), setting the value to 3 does prevent ptrace from running - running strace -p (as root) gives a permission denied error. I'm concerned, as Yama is supposed to mitigate against a couple of other vulnerabilities. It has just occurred to me to reboot without SELinux and see if it works in that contest - I'll update once I have done so. Is Yama deprecated (there's a SELinux boolean which handles this behaviour - it's deny_ptrace)? I can find very little in the way of documentation. **UPDATE:** (even without SElinux loaded yama does nothing) Oct 2 12:30:00 xx kernel: Command line: BOOT_IMAGE=/vmlinuz-3.10.0-862.11.6.el7.x86_64 root=/dev/mapper/rpool-root ro crashkernel=auto rd.lvm.lv=rpool/root rd.lvm.lv=rpool/swap rhgb ipv6.disable=1 biosdevname=0 net.ifnames=0 quiet audit=1 fips=1 boot=/dev/sda1 audit=1 CONFIG_SECURITY_YAMA=y selinux=0 Oct 2 12:30:00 xx kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0-862.11.6.el7.x86_64 root=/dev/mapper/rpool-root ro crashkernel=auto rd.lvm.lv=rpool/root rd.lvm.lv=rpool/swap rhgb ipv6.disable=1 biosdevname=0 net.ifnames=0 quiet audit=1 fips=1 boot=/dev/sda1 audit=1 CONFIG_SECURITY_YAMA=y selinux=0 Oct 2 12:30:00 xx kernel: SELinux: Disabled at boot. Oct 2 12:30:00 xx kernel: EVM: security.selinux Oct 2 12:30:00 xx systemd: systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN) Oct 2 12:30:03 xx systemd: systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN) And Yama still doesn't deny ptrace: xx:root@~ #strace -p 2195 strace: Process 2195 attached restart_syscall(strace: Process 2195 detached xx:root@~ #sysctl -a -r yama kernel.yama.ptrace_scope = 3

I am going through some primers on LSM implementations so eventually I am digging a bit into AppArmor and SELinux. I am aware of this discussion but this does not make very clear one question I am having in regard to these two LSM implementations: Is it a fact that: - SELinux must be applied system-wide (thus the auto-relabeling process on first boot which takes as much time as a filesystem scan) - AppArmor provides the flexibility to define policies only on those processes / scripts you d' like? - via the interactive auditing process) (?)

I've compiled a kernel (linux-libre-xtreme) with [this configuration](https://git.parabola.nu/abslibre.git/plain/kernels/linux-libre-xtreme/config.x86_64) , it has most LSMs enabled: YAMA, SMACK, AppArmor, TOMOYO and SELinux. However, when I start the apparmor service with OpenRC I get: # rc-service apparmor start * Stopping AppArmor ... * Unloading AppArmor profiles * Root privileges not available [ !! ] * Starting AppArmor ... * Loading AppArmor profiles ... Cache read/write disabled: interface file missing. (Kernel needs AppArmor 2.4 compatibility patch.) Warning: unable to find a suitable fs in /proc/mounts, is it mounted? Use --subdomainfs to override. * /etc/apparmor.d/usr.bin.apache2 failed to load Cache read/write disabled: interface file missing. (Kernel needs AppArmor 2.4 compatibility patch.) Warning: unable to find a suitable fs in /proc/mounts, is it mounted? Use --subdomainfs to override. And other profiles also complain, however this doesn't happen with other kernel that I've compiled too (linux-libre-lts-apparmor, see its configuration [here](https://git.parabola.nu/abslibre.git/plain/kernels/linux-libre-lts-apparmor/config.x86_64)) What am I doing wrong? If I do cat /sys/module/apparmor/parameters/enabled with the linux-libre-xtreme kernel, I get N, but with linux-libre-lts-apparmor, it says Y, so I know it's not something with kernel parameters from the bootloader.

As I understand it, the Linux Security Module (LSM) framework has many hooks which are callbacks for security modules to register functions performing additional security checks before security-sensitive operations. Most of the time, these hooks are placed before the access to an internal data structure like `file`. One thing that I don't understand is why there are hooks in System V IPC APIs but not in the corresponding POSIX APIs. For example, there is `security_ipc_permission which is a hook describe in include/linux/lsm_hooks.h` as "affecting all System V IPC operations" and several more hooks specialized for each APIs such as the message queues but no counterpart for the POSIX APIs. Manual investigation reveals that the System V hooks are not used in the POSIX functions (as expected, given the description). But in the case of POSIX message queues and System V message queues for example, while they don't have the same interface, they provide roughly the same functionality. So my question is: what is the rationale for not putting LSM hooks in POSIX functions?

I am having trouble seeing the utility or use of the LSM attribute/caps implementations. I've put together a pseudo code snippet of sorts to try to express my concern and question. It's modeled after a diagram from (p 3) https://www.kernel.org/doc/ols/2002/ols2002-pages-604-617.pdf Kernel access check (approx) and LSM call: DAC op:__? // ? what operation would pass a DAC check yet not the LSM hook ? file:___ perms: u.. g.. o.. euid:100 egid:500 OK ----> LSM hook ( args ) 1) I don't know the args here, 2) Regardless of the args I can't make out what operation would pass a DAC check and be restricted here and why? ? read file ? allready handled by DAC ? network device ? allready handled by DAC, it's a file. ? execution ? x bit , allready handled ? executing a specific function ? no function call references here ? executing a specific syscall ? would be handled on exec on the target (read, write etc..) ? **What exactly can the LSM hook accomplish here that DAC hasn't allready addressed ??** Answers are welcome. sp I've read talk about attempting to have coders not use setuid root and use some CAP attribute instead to make this work for safer privileged escalation but I'm personally not a pundit for relying on a change in behavior nor a hook permissions check to assure the integrity of code running on a machine and I doubt I'm alone. I've also read it's not the intent of LSM here which addresses the design yet remains vague on precise uses over the current DAC permissions checks. It talks about why the hooks are where they are but not how to use them effectively to, again, accomplish something more than DAC.

i'm trying to understand allocation of inode_security_struct in Selinux. I looked for a source code of selinux and there is only one allocation of this struct [on line 230 in hooks.c file](http://lxr.free-electrons.com/source/security/selinux/hooks.c#L225) . This allocation is in LSM hook which is called when inode is created. My question is how Selinux allocate inodes which were created before selinux init? Thanks.

In researching this U&L Q&A titled: permission denied for ptrace under GDB , the question came up, "Is there other software similar to SELinux & AppArmor?". User @IwillnotexistIdonotexist mentioned 2 that I'd never heard of: Smack & Yama. He found them by searching through the Linux source code. So now we're up to 4. - SELinux - AppArmor - Smack - Yama Are there others?