Re: [apparmor] Using r, w, m, c altogether
Ah Thanks
I get it now
On Wed, Jun 26, 2013 at 8:35 AM, John Johansen
john.johan...@canonical.com wrote:
On 06/25/2013 05:21 PM, Seth Arnold wrote:
On Wed, Jun 26, 2013 at 07:54:46AM +0800, Aaron Lewis wrote:
Hi,
Looks like I can use rwmc altogether, am I wrong?
owner @{HOME}/.config/google-googletalkplugin/{**,} rwmc,
I can't see 'c' support in our current parser source code, not can I get
this to work in a test profile:
c is not supported as an independent permission. We have cx for child profile
transitions.
The audit logs do unfortunately report c for the the create permission as
the kernel does have the permission set broken down finer than what is
currently exposed in the language.
currently the w permission implies c,
http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Reference#File_permissions
has a guide (reproduced below) of how the letter permissions map to the wider
set of permissions
Short form permissions map to
r - read, meta-read, mmap_r
w - create, delete, trunc, write, meta-write, chmod, chown, mmap_w, mprot_wx,
partial rename (where it implies partial source rename permissions and full
destination renamed permission)
a - append, create
l - link (may be combined with other permissions to determine if allowed)
k - lock (combines with ???write to determine if exclusive lock is allowed)
m - mmap_x, mprot_wx
x - exec, (if ix then also mmap_x)
$ echo /t { / rwmc, } | apparmor_parser -Q -d
Warning from stdin (line 1): apparmor_parser: cannot use or update cache,
disable, or force-complain via stdin
AppArmor parser error, in stdin line 1: syntax error, unexpected TOK_ID,
expecting TOK_MODE
But removing the 'c':
$ echo /t { / rwm, } | apparmor_parser -Q -d
Warning from stdin (line 1): apparmor_parser: cannot use or update cache,
disable, or force-complain via stdin
- Debugging built structures -
Name: /t
Profile Mode: Enforce
--- Entries ---
Mode: rwam:rwam Name: (/)
$
When the kernel logs a denied mode of 'c', it is indeed a process trying
to create the file, but there is currently no way to give _only_ this
privilege to a process. 'w' will also grant this permission.
All you need is 'rwm'.
Thanks
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
--
Best Regards,
Aaron Lewis - PGP: 0xDFE6C29E ( http://keyserver.veridis.com )
Finger Print: 9482 448F C7C3 896C 1DFE 7DD3 2492 A7D0 DFE6 C29E
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
[apparmor] IPC syntax - again
So this is long and has taken far to long to write, I am sure their are things I have missed and some of the logic may be missing. In fact I don't really consider this email complete but we need to make a decision asap, so Lets look at this at a more generic layer and then start applying it to other types of ipc, and give some examples so can bring this into the larger discussion. Firstly ipc is all about communication between subjects, so everything that isn't caps or resource control. There are several basic patterns and features that distinguish different types of ipc beyond the specific features of a given ipc. Some general patterns (with ascii art!) 1. Direct Private +---+ +---+ | | | | | P1 | -- | P2 | | | | | |___| |___| 2. Direct Private Proxied (handle) +---+ +---+ | | +--++--+ | | | P1 | - |h1| |h2| - | P2 | | | |__||__| | | |___| |___| 3. Direct Shared Proxy (handle) +---+ +---+ | | +--++--+ | | | P1 | - |h1| |h2| - | P2 | | | |__||__| | | |___| ^ |___| | +---+ | | | | | P3 | + | | |___| 4. Bus | || | || +---+ +---++---+ | | | || | | P1 | | P2 || P3 | | | | || | |___| |___||___| 5. Proxied Bus | || +--+ +--+ +--+ |h1| |h2| |h3| |__| |__| |__| | || +---+ +---++---+ | | | || | | P1 | | P2 || P3 | | | | || | |___| |___||___| 6. Shared Proxied Bus | | +--+ +--+ + |h1| -+ |h3| | |__| | |__| v v| +---+ +---++---+ | | | || | | P1 | | P2 || P3 | | | | || | |___| |___||___| 7. Indirect Object +--+ | | +- | Obj1 | -+ | |__| | | | | | +---+ | | +---+ | | | | | | | P1 | ---+ +--- | P2 | | | | | |___| |___| 8. Proxied Indirect Object +--+ | | +- | Obj1 | -+ | |__| | +--+ +--+ |h1| |h2| +---+|__| |__| +---+ | | | | | | | P1 | ---+ +--- | P2 | | | | | |___| |___| 9. Shared Proxied Indirect Object +--+ | | +--- | Obj1 | ---+ | |__| | +--+ +--+ |h1| |h2| +---+|__| +---+ |__| +---+ | | | | || | | | P1 | ---+--- | P3 |+--- | P2 | | | | | | | |___| |___| |___| In practice we don't actually have to deal with all of these as most resources are accessed via proxy (handle) and if the handle is not shared as is the case for diagrams (2,5,8) there is a one to one mapping between the proxy and the subject as such we can ignore the proxy in these case as it has the same labeling as the subject it represents. Beyond proxied or not, and direct vs indirect there are a few other properties that can be considered for none share object ipc, there is a local (subject) side and a remote peer side - is the peer address available - is the peer labeling available - can the local address and
[apparmor] [PATCH] fix missing long opt arg value
Using --subdomainfs without an argument triggers a segfault. This was due
to the long option missing the has_arg flag.
Signed-off-by: Kees Cook k...@ubuntu.com
=== modified file 'parser/parser_main.c'
--- parser/parser_main.c2013-05-02 18:32:56 +
+++ parser/parser_main.c2013-06-26 18:04:16 +
@@ -91,7 +91,7 @@
{add, 0, 0, 'a'},
{binary, 0, 0, 'B'},
{base,1, 0, 'b'},
- {subdomainfs, 0, 0, 'f'},
+ {subdomainfs, 1, 0, 'f'},
{help,2, 0, 'h'},
{replace, 0, 0, 'r'},
{reload, 0, 0, 'r'}, /* undocumented reload
option == replace */
--
Kees Cook
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
