Changes between Version 86 and Version 87 of mmcco

Timestamp:

Dec 31, 2015, 10:23:46 PM (8 years ago)

Author:

mmcco

Comment:

update and simplify

mmcco

@@ -162 +162 @@
 === The value of multiprocess design ===
 
-There isn't a simple, intuitive, widely-used, and easy-to-learn Mandatory Access Control (MAC) or similar framework yet. Options include FreeBSD's Capsicum, Linux's App^^Armor, and OpenBSD's newly released tame syscall. To further complicate things, these frameworks are generally baked into the kernel and are therefore platform-specific.
+Privilege revocation of large, monolithic programs like Pidgin requires complicated access control frameworks. Options include FreeBSD's Capsicum and Linux's App^^Armor. These frameworks are baked into the kernel and are therefore platform-specific.
 
 [https://tails.boum.org/ Tails], an anonymity-focused operating system based on Tor and Debian, includes Pidgin and OTR by default. They've written an App^^Armor profile for Pidgin that's now included in the Debian/^^Ubuntu package `apparmor-profiles-extra`.
 
-All existing MAC frameworks are pretty cumbersome and have a slow learning curve. (tame is trying to buck this trend, but it's far too new and rarely used to be an option yet.) So, the best model is:
+Because of these frameworks' complexity, the best model is:
 
 * program developers make their code multiprocess and refrain from using unnecessary privileges
-* packagers and OS/distro developers use this to write good MAC profiles
-
-Put more bluntly: it probably isn't worth developers' time to learn AppArmor et al. in order to write profiles. As long as MAC frameworks are big and complicated, the above method is far more efficient. Simple programs that use very few privileges (Pidgin definitely doesn't qualify) may be exceptions.
-
-Anecdotally, it'd be nice to start the convention of using a tag like `PRIVSEP` in code to help packagers find points of potential lockdown. Lacking these, searching for `fork()` and `exec()`-family functions with cscope or something similar is a good approach. Beyond that, running the program in a debugger and breaking on new process creation is educational, as is understanding its initialization and `main()` logic well.
+* packagers and OS/distro developers write MAC profiles
+
+This method allows for more specialization and is therefore far more efficient.
+
+=== Code annotations ===
+
+Anecdotally, it'd be nice to start the convention of using a tag like `PRIVSEP` in code to help packagers find points of potential lockdown. Lacking these, locating `fork()` and `exec()`-family functions with cscope or something similar is a good approach. Running the program in a [http://www.sourceware.org/gdb/onlinedocs/gdb/Forks.html debugger] and breaking on new process creation is also educational, as is understanding its initialization and `main()` logic well.
 
 === Breakages ===