<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Mac on Le Site de François</title><link>https://lesitedefrancois.be/en/tags/mac/</link><description>Recent content in Mac on Le Site de François</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 François</copyright><atom:link href="https://lesitedefrancois.be/en/tags/mac/index.xml" rel="self" type="application/rss+xml"/><item><title>AppArmor (Application Armor)</title><link>https://lesitedefrancois.be/en/security/apparmor/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/apparmor/</guid><description>&lt;p&gt;&lt;strong&gt;AppArmor (Application Armor)&lt;/strong&gt; is a &lt;strong&gt;Mandatory Access Control (MAC)&lt;/strong&gt; system implemented as a major &lt;strong&gt;LSM&lt;/strong&gt; (Linux Security Module), developed originally by Immunix and now maintained by Canonical. It is the default MAC system on Ubuntu, Debian, and their derivatives, and the default container confinement mechanism for containerd and Docker on those distributions. Where &lt;strong&gt;SELinux&lt;/strong&gt; assigns security labels to every object on the system and enforces policy based on label interactions, AppArmor takes a fundamentally different approach: it confines programs by &lt;strong&gt;filesystem path&lt;/strong&gt;. A profile for &lt;code&gt;nginx&lt;/code&gt; lists the specific file paths that nginx is allowed to read, write, and execute, the network operations it may perform, and the Linux capabilities it may use — anything not listed is denied. No relabelling of the filesystem is required and no extended attributes are set: AppArmor&amp;rsquo;s confinement decisions are made purely from the path of the file being accessed and the identity of the confined process. This path-based model makes AppArmor profiles far simpler to read, write, and audit than SELinux policy, and eliminates the mislabelled-file failure mode that is the most common SELinux operational problem.&lt;/p&gt;</description></item><item><title>LSM (Linux Security Module)</title><link>https://lesitedefrancois.be/en/security/lsm/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/lsm/</guid><description>&lt;p&gt;&lt;strong&gt;Linux Security Modules (LSM)&lt;/strong&gt; is a hook-based framework integrated into the Linux kernel since 2.6 (2003) that provides a general mechanism for implementing Mandatory Access Control (MAC) without modifying the core kernel. Its origin is the NSA&amp;rsquo;s presentation of SELinux at the 2001 Linux Kernel Summit: Linus Torvalds accepted the need for flexible access control but refused to hardcode a single security model, directing instead the development of a framework into which any security model could be plugged. The result is LSM: a set of strategically placed hook functions throughout the kernel&amp;rsquo;s execution paths — over 240 hooks in recent kernels — at points where security-relevant decisions occur: file open, process creation, capability checks, socket operations, IPC access, memory mapping, and more. Each hook is a call into the currently active security module(s), which examine the operation&amp;rsquo;s context and return allow or deny. The core kernel enforces whatever the security module decides.&lt;/p&gt;</description></item><item><title>SELinux (Security-Enhanced Linux)</title><link>https://lesitedefrancois.be/en/security/selinux/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/selinux/</guid><description>&lt;p&gt;&lt;strong&gt;SELinux (Security-Enhanced Linux)&lt;/strong&gt; is a &lt;strong&gt;Mandatory Access Control (MAC)&lt;/strong&gt; implementation developed by the NSA and released as open source in 2000, merged into the mainline Linux kernel in 2.6 via the &lt;strong&gt;LSM&lt;/strong&gt; framework in 2003. Its defining characteristic is &lt;strong&gt;default deny&lt;/strong&gt;: unlike the standard Linux Discretionary Access Control model (file permission bits), where anything not explicitly forbidden is permitted, SELinux refuses all access that is not explicitly allowed by policy. Every process and every object — every file, socket, pipe, device node, and IPC object — carries a &lt;strong&gt;security context&lt;/strong&gt; (also called a label) of the form &lt;code&gt;user:role:type:level&lt;/code&gt;. The policy is a compiled set of rules, loaded at boot, that defines precisely which combinations of process context and object context may interact and how. An Apache web server process running in the &lt;code&gt;httpd_t&lt;/code&gt; domain can read files labelled &lt;code&gt;httpd_sys_content_t&lt;/code&gt; but is denied access to files labelled &lt;code&gt;user_home_t&lt;/code&gt; or &lt;code&gt;shadow_t&lt;/code&gt;, regardless of what Unix file permission bits say. If the web server is compromised, the attacker is confined to what &lt;code&gt;httpd_t&lt;/code&gt; permits — typically a narrow, well-defined set of files and network operations — rather than having the full access of the user account running Apache.&lt;/p&gt;</description></item></channel></rss>