Changes between Version 91 and Version 92 of mmcco

Timestamp:

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

Author:

mmcco

Comment:

a word

mmcco

@@ -177 +177 @@
 OpenBSD's new privilege revocation system call [http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/pledge.2 pledge(2)] is based on the concept that programs do most of their privileged operations during initialization, eventually dropping into a main loop that is "boring and full of buffer overflows". The `pledge(2)` model therefore allows the process all privileges until it makes the system call. This is fundamentally different from approaches such as App^^Armor's, which have a static privilege list stored outside the program that is always enforced.
 
-The `pledge(2)` model makes more sense for network programs like Pidgin and is easier to implement. In these cases, we trust the ''binary'' to not be malicious, but we don't trust the remote network entities it interacts with, and we don't trust the binary to protect us from them. Why lock down the process before it interacts with the network? Many other access control frameworks results attempt to protect the system from potentially malicious binaries, which can add complicating rigidity.
+The `pledge(2)` model makes more sense for network programs like Pidgin and is easier to implement. In these cases, we trust the ''binary'' to not be malicious, but we don't trust the remote network entities it interacts with, and we don't trust the binary to protect us from them. Why lock down the process before it interacts with the network? Many other access control frameworks attempt to protect the system from potentially malicious binaries, which can add complicating rigidity.
 
 This sort of approach can be used in App^^Armor's through its `aa_change_hat` and `aa_change_profile` functions. However, this is less elegant and seems rarely used.