Tip of the day: when troubleshooting #AppArmor profiles, don't forget to reload the profile with apparmor_parser every time you make a change to the profile.
Not that I'm speaking from personal experience or anything... #facepalm#Linux
The working branch of my userspace parser for binary #AppArmor profiles that are usually parsed by the kernel can now parse any profile I throw at it.
I don't do the DFA unpacking and analysis yet but given that I'm stuck at home (extreme allergy to whatever is in the air recently) I think I will get to that today.
I've been working on improving visibility into what apparmor_parser compiles by effectively de-compiling it back to human-readable data.
I don't seem to have enough google-fu to solve this myself: On my #Debian installations, #dmesg is full of #AppArmor logs for #Vivaldi. Almost all of them are "ALLOW" entries, which seems completely irrelevant.
Is there a way to get AppArmor not to spam dmesg with messages? I can't find any settings about the amount of log messages in the AppArmor manual page or documentation.
In this weeks episode of the #Ubuntu Security Podcast #AppArmor unprivileged user namespace restrictions are back on the agenda as we survey the latest improvements to this hardening feature in the upcoming Ubuntu 24.04 LTS, plus we discuss SMTP smuggling in Postfix, runC container escapes and Qualys’ recent disclosure of a privilege escalation exploit for GNU libc and more https://ubuntusecuritypodcast.org/episode-218/
Given the drive towards using selinux or apparmor more within Linux, I really would be grateful, if applications could actually check, what path exists and not try to open 32 paths in /dev/ just in case they exist.
The same applies to linkers, who don't look into folders, but instead blindly try to open files, which might never exist.
This type of behavior creates a lot of noise and clutter and makes it hard to restrict the access of applications. #linux#apparmor#selinux
Thanks again to @ubuntu for organizing the #UbuntuSummit. It was an honor to me to have presented a talk about building large set of #apparmor profiles
Is there any human readable documentation on how the binary format of #Apparmor works?
I try to figure out, if patching files to have the FORCE_COMPLAIN mode active, without having the play text version is feasible #linuxsecurity#linux
Hi, #Debian friends! Do any of you run Debian with #SELinux? If so, what is your experience like? What are some common issues to watch for?
I see that the Debian kernel supports SELinux, and there is some good documentation for it in the Debian handbook, but it does not seem to be commonly used with the OS (#AppArmor seems much more common with Debian). So my main concern is that using it in Debian may be unpredictable or more of a challenge than with distributions that use SELinux by default.
The background for my question is that my workplace mainly runs Red Hat variants, and we are very likely gradually changing our fleet to Debian. So I’m comfortable with SELinux, and I prefer its ‘deny everything by default’ approach over making and carefully testing profiles for individual applications.
I’ve spent quite a bit of time with #AppArmor lately, and it’s good, but there aren’t many ‘official’ profiles for it, and making new ones for some applications can be a real challenge.