Re: [apparmor] [patch] raise exception if sub_str_to_mode() is called with invalid mode string (was: Re: [patch] add tests for aamode.py)
On Mon, Dec 22, 2014 at 07:24:19PM +0100, Christian Boltz wrote: Raise an exception if sub_str_to_mode() is called with invalid mode string or if a mode_char is not in MODE_HASH. Also update the testcase for asdf42 (which raises AppArmorBug now) and add a test that simulates MODE_HASH and MODE_MAP_SET getting out of sync (tests the second part of the if condition). Acked-by: Steve Beattie st...@nxnw.org. Thanks. -- Steve Beattie sbeat...@ubuntu.com http://NxNW.org/~steve/ signature.asc Description: Digital signature -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
[apparmor] Fwd: Re: [pkg-apparmor] aa-unconfined shows tor as being unconfined, aa-status says different
Hi, (Cc:ed Peter Palfrader (weasel), who maintains tor in Debian and the Debian AppArmor Packaging Team.) While playing around with `aa-unconfined` i saw that /usr/bin/tor is marked as not being confined. In Debian, `tor` comes with an apparmor profile which is called system_tor and lives in /etc/apparmor.d. `aa-unconfined` seems to ignore this, but `aa-status` tells me that the `system_tor` profile is well active. Do I need to worry about the tor process not being confined? Asked differently, do profiles need to be named a certain way (eg. `usr/bin/something`) to be taken into account by `aa-unconfined`? How do other distributions handle this particular profile? As intrigeri says [1], one of these tools might be buggy. Cheers, Ulrike [1] http://lists.alioth.debian.org/pipermail/pkg-apparmor-team/2015-February/000386.html -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [pkg-apparmor] Fwd: Re: aa-unconfined shows tor as being unconfined, aa-status says different
On Mon, Feb 02, 2015 at 10:22:27AM +, u wrote:
(Cc:ed Peter Palfrader (weasel), who maintains tor in Debian and the
Debian AppArmor Packaging Team.)
While playing around with `aa-unconfined` i saw that /usr/bin/tor is
marked as not being confined.
In Debian, `tor` comes with an apparmor profile which is called
system_tor and
lives in /etc/apparmor.d.
`aa-unconfined` seems to ignore this, but `aa-status` tells me that the
`system_tor` profile is well active.
This is a bug in aa-unconfined. It's not been updated to take into
account the possibility of profile names that are not path based
(i.e. begins with '/'); specifically, the aa-unconfined code contains:
with aa.open_file_read(/proc/%s/attr/current%pid) as current:
for line in current:
if line.startswith(/) or line.startswith(null):
attr = line.strip()
Do I need to worry about the tor process not being confined?
In this case, it does not appear that you do. To confirm, you'll want
to ensure that the tor process(es) is showing up in the 'XX processes
are in enforce mode.' in the output of aa-status.
More generally, for debugging purposes, to identify what apparmor
profile the kernel has applied to a given process, find the pid of
the process that you're interested in and then examine the contents
of /proc/PID/attr/current (replacing PID with the pid you identified
earlier). If it contains 'unconfined', then there is no apparmor
policy applied. Otherwise, it should contain the name of the profile
('system_tor' in the case of tor).
Thanks!
--
Steve Beattie
sbeat...@ubuntu.com
http://NxNW.org/~steve/
signature.asc
Description: Digital signature
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [Patch][parser] fix: globbing for af_unix abstract names
On Mon, Feb 02, 2015 at 01:28:55PM -0800, John Johansen wrote: On 01/30/2015 03:14 PM, John Johansen wrote: v2. per Christian's request on IRC grouping of the glob switch into a single fn I like moving the switch into a function as well. Acked-by: Steve Beattie st...@nxnw.org for both trunk and 2.9. And thanks for adding to the unit tests (yeah, I know, we need to add corresponding language and regression tests as well). -- Steve Beattie sbeat...@ubuntu.com http://NxNW.org/~steve/ signature.asc Description: Digital signature -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [pkg-apparmor] Fwd: Re: aa-unconfined shows tor as being unconfined, aa-status says different
Hi,
Steve Beattie:
On Mon, Feb 02, 2015 at 10:22:27AM +, u wrote:
`aa-unconfined` seems to ignore this, but `aa-status` tells me that the
`system_tor` profile is well active.
This is a bug in aa-unconfined. It's not been updated to take into
account the possibility of profile names that are not path based
(i.e. begins with '/'); specifically, the aa-unconfined code contains:
with aa.open_file_read(/proc/%s/attr/current%pid) as current:
for line in current:
if line.startswith(/) or line.startswith(null):
attr = line.strip()
Do I need to worry about the tor process not being confined?
In this case, it does not appear that you do. To confirm, you'll want
to ensure that the tor process(es) is showing up in the 'XX processes
are in enforce mode.' in the output of aa-status.
More generally, for debugging purposes, to identify what apparmor
profile the kernel has applied to a given process, find the pid of
the process that you're interested in and then examine the contents
of /proc/PID/attr/current (replacing PID with the pid you identified
earlier). If it contains 'unconfined', then there is no apparmor
policy applied. Otherwise, it should contain the name of the profile
('system_tor' in the case of tor).
Thanks! I've added this info to the Debian wiki [1]
Ulrike
[1] https://wiki.debian.org/AppArmor/Debug
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [pkg-apparmor] Fwd: Re: aa-unconfined shows tor as being unconfined, aa-status says different
Hello,
Am Montag, 2. Februar 2015 schrieb u:
Christian Boltz:
Am Montag, 2. Februar 2015 schrieb u:
While playing around with `aa-unconfined` i saw that /usr/bin/tor
is
marked as not being confined.
Does it work if you change aa-unconfined line 66? Untested
pseudo-patch: -if line.startswith(/) or
line.startswith(null):
+ if line.strip() != unconfined:
Actually, yes!
If I use your line, i get:
1609 /usr/bin/tor confined by 'system_tor (enforce)'
instead of
1609 /usr/bin/tor not confined
Thanks for testing!
Some IRC discussion brought up that it's probably better to check for
' (complain)' and ' (enforce)', so here's the patch:
Fix aa-unconfined to work with profile names that don't start with / or null
I propose this patch for 2.9 and trunk.
[ aa-unconfined--named-profiles.diff ]
=== modified file 'utils/aa-unconfined'
--- utils/aa-unconfined 2014-09-14 18:17:00 +
+++ utils/aa-unconfined 2015-02-02 18:50:07 +
@@ -63,8 +63,9 @@
if os.path.exists(/proc/%s/attr/current%pid):
with aa.open_file_read(/proc/%s/attr/current%pid) as current:
for line in current:
-if line.startswith(/) or line.startswith(null):
-attr = line.strip()
+line = line.strip()
+if line.endswith(' (complain)', 1) or line.endswith('
(enforce)', 1): # enforce at least one char as profile name
+attr = line
cmdline = apparmor.common.cmd([cat, /proc/%s/cmdline%pid])[1]
pname = cmdline.split(\0)[0]
Regards,
Christian Boltz
--
[Antiviren-Software] D i e b r a u c h e na l l e
Nicht nur aus Gründen der Sicherheit vor Betrügern,
sondern insbesondere als Schutz vor Bankern und Juristen.
[Ernst Scott in opensuse-de]
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [Patch][parser] fix: globbing for af_unix abstract names
On 01/30/2015 03:14 PM, John Johansen wrote:
v2. per Christian's request on IRC grouping of the glob switch into a single fn
=== modified file 'parser/af_unix.cc'
--- parser/af_unix.cc 2014-10-08 20:20:20 +
+++ parser/af_unix.cc 2015-01-30 17:46:36 +
@@ -243,7 +243,7 @@
buffer \\x01;
} else {
/* skip leading @ */
- ptype = convert_aaregex_to_pcre(addr + 1, 0, buf, pos);
+ ptype = convert_aaregex_to_pcre(addr + 1, 0, glob_null,
buf, pos);
if (ptype == ePatternInvalid)
return false;
/* kernel starts abstract with \0 */
@@ -267,7 +267,7 @@
if (label) {
int pos;
- ptype = convert_aaregex_to_pcre(label, 0, buf, pos);
+ ptype = convert_aaregex_to_pcre(label, 0, glob_default, buf,
pos);
if (ptype == ePatternInvalid)
return false;
/* kernel starts abstract with \0 */
=== modified file 'parser/dbus.cc'
--- parser/dbus.cc 2014-10-08 20:20:20 +
+++ parser/dbus.cc 2015-01-30 17:47:35 +
@@ -228,7 +228,7 @@
busbuf.append(buffer.str());
if (bus) {
- ptype = convert_aaregex_to_pcre(bus, 0, busbuf, pos);
+ ptype = convert_aaregex_to_pcre(bus, 0, glob_default, busbuf,
pos);
if (ptype == ePatternInvalid)
goto fail;
} else {
@@ -238,7 +238,7 @@
vec[0] = busbuf.c_str();
if (name) {
- ptype = convert_aaregex_to_pcre(name, 0, namebuf, pos);
+ ptype = convert_aaregex_to_pcre(name, 0, glob_default, namebuf,
pos);
if (ptype == ePatternInvalid)
goto fail;
vec[1] = namebuf.c_str();
@@ -248,7 +248,7 @@
}
if (peer_label) {
- ptype = convert_aaregex_to_pcre(peer_label, 0,
+ ptype = convert_aaregex_to_pcre(peer_label, 0, glob_default,
peer_labelbuf, pos);
if (ptype == ePatternInvalid)
goto fail;
@@ -259,7 +259,7 @@
}
if (path) {
- ptype = convert_aaregex_to_pcre(path, 0, pathbuf, pos);
+ ptype = convert_aaregex_to_pcre(path, 0, glob_default, pathbuf,
pos);
if (ptype == ePatternInvalid)
goto fail;
vec[3] = pathbuf.c_str();
@@ -269,7 +269,7 @@
}
if (interface) {
- ptype = convert_aaregex_to_pcre(interface, 0, ifacebuf, pos);
+ ptype = convert_aaregex_to_pcre(interface, 0, glob_default,
ifacebuf, pos);
if (ptype == ePatternInvalid)
goto fail;
vec[4] = ifacebuf.c_str();
@@ -279,7 +279,7 @@
}
if (member) {
- ptype = convert_aaregex_to_pcre(member, 0, memberbuf, pos);
+ ptype = convert_aaregex_to_pcre(member, 0, glob_default,
memberbuf, pos);
if (ptype == ePatternInvalid)
goto fail;
vec[5] = memberbuf.c_str();
=== modified file 'parser/mount.cc'
--- parser/mount.cc 2014-12-12 14:21:31 +
+++ parser/mount.cc 2015-01-30 17:47:53 +
@@ -554,7 +554,7 @@
}
list_for_each(opts, ent) {
- ptype = convert_aaregex_to_pcre(ent-value, 0, buffer, pos);
+ ptype = convert_aaregex_to_pcre(ent-value, 0, glob_default,
buffer, pos);
if (ptype == ePatternInvalid)
return FALSE;
=== modified file 'parser/parser.h'
--- parser/parser.h 2014-10-08 20:20:20 +
+++ parser/parser.h 2015-01-30 17:50:02 +
@@ -334,7 +334,9 @@
#define default_match_pattern [^\\000]*
#define anyone_match_pattern [^\\000]+
-extern pattern_t convert_aaregex_to_pcre(const char *aare, int anchor,
+#define glob_default 0
+#define glob_null 1
+extern pattern_t convert_aaregex_to_pcre(const char *aare, int anchor, int
glob,
std::string pcre, int *first_re_pos);
extern int build_list_val_expr(std::string buffer, struct value_list *list);
extern int convert_entry(std::string buffer, char *entry);
=== modified file 'parser/parser_regex.c'
--- parser/parser_regex.c 2015-01-29 22:54:08 +
+++ parser/parser_regex.c 2015-02-02 21:22:08 +
@@ -84,9 +84,27 @@
*dptr = 0;
}
+static error_type append_glob(std::string pcre, int glob,
+ const char *default_glob, const char *null_glob)
+{
+ switch (glob) {
+ case glob_default:
+ pcre.append(default_glob);
+ break;
+ case glob_null:
+ pcre.append(null_glob);
+ break;
+ default:
+
Re: [apparmor] [pkg-apparmor] Fwd: Re: aa-unconfined shows tor as being unconfined, aa-status says different
Hello, Am Montag, 2. Februar 2015 schrieb u: While playing around with `aa-unconfined` i saw that /usr/bin/tor is marked as not being confined. In Debian, `tor` comes with an apparmor profile which is called system_tor and lives in /etc/apparmor.d. `aa-unconfined` seems to ignore this, but `aa-status` tells me that the `system_tor` profile is well active. Do I need to worry about the tor process not being confined? If in doubt, cat /proc/$tor_pid/attr/current Asked differently, do profiles need to be named a certain way (eg. `usr/bin/something`) to be taken into account by `aa-unconfined`? How do other distributions handle this particular profile? As intrigeri says [1], one of these tools might be buggy. I'd guess this is a bug in aa-unconfined - it only checks for profile names starting with / or null: if os.path.exists(/proc/%s/attr/current%pid): with aa.open_file_read(/proc/%s/attr/current%pid) as current: for line in current: if line.startswith(/) or line.startswith(null): attr = line.strip() Does it work if you change aa-unconfined line 66? Untested pseudo-patch: -if line.startswith(/) or line.startswith(null): + if line.strip() != unconfined: Regards, Christian Boltz -- Was habt Ihr denn? emacs ist doch ein tolles Betriebssystem! Das einzige was ihm fehlt, ist ein vernünftiger Editor (vim?) [Jan Trippler in suse-linux] -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [pkg-apparmor] Fwd: Re: aa-unconfined shows tor as being unconfined, aa-status says different
On 02/02/2015 07:51 AM, Christian Boltz wrote: Hello, Am Montag, 2. Februar 2015 schrieb u: While playing around with `aa-unconfined` i saw that /usr/bin/tor is marked as not being confined. In Debian, `tor` comes with an apparmor profile which is called system_tor and lives in /etc/apparmor.d. `aa-unconfined` seems to ignore this, but `aa-status` tells me that the `system_tor` profile is well active. Do I need to worry about the tor process not being confined? If in doubt, cat /proc/$tor_pid/attr/current Asked differently, do profiles need to be named a certain way (eg. `usr/bin/something`) to be taken into account by `aa-unconfined`? How do other distributions handle this particular profile? As intrigeri says [1], one of these tools might be buggy. I'd guess this is a bug in aa-unconfined - it only checks for profile names starting with / or null: if os.path.exists(/proc/%s/attr/current%pid): with aa.open_file_read(/proc/%s/attr/current%pid) as current: for line in current: if line.startswith(/) or line.startswith(null): attr = line.strip() Does it work if you change aa-unconfined line 66? Untested pseudo-patch: -if line.startswith(/) or line.startswith(null): + if line.strip() != unconfined: hrmmm, the null check is interesting. The only place you should hit that is in learning mode when there is no profile associated, which from a confinement pov is unconfined so I would probably keep that if line.strip() != unconfined or line.startswith(null): of course that won't work for namespaced stuff but no one is using that yet. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
[apparmor] [Merge] lp:~chkpnt/apparmor/ssl_certs into lp:apparmor
Gregor Dschung has proposed merging lp:~chkpnt/apparmor/ssl_certs into lp:apparmor. Requested reviews: AppArmor Developers (apparmor-dev) For more details, see: https://code.launchpad.net/~chkpnt/apparmor/ssl_certs/+merge/248191 /etc/apparmor.d/abstractions/ssl_certs now contains entries for /etc/pki/trust and /etc/pki/trust/anchors -- Your team AppArmor Developers is requested to review the proposed merge of lp:~chkpnt/apparmor/ssl_certs into lp:apparmor. === modified file 'profiles/apparmor.d/abstractions/ssl_certs' --- profiles/apparmor.d/abstractions/ssl_certs 2013-11-25 23:41:04 + +++ profiles/apparmor.d/abstractions/ssl_certs 2015-01-31 15:57:27 + @@ -12,6 +12,10 @@ /etc/ssl/ r, /etc/ssl/certs/ r, /etc/ssl/certs/* r, + /etc/pki/trust/ r, + /etc/pki/trust/* r, + /etc/pki/trust/anchors/ r, + /etc/pki/trust/anchors/** r, /usr/share/ca-certificates/ r, /usr/share/ca-certificates/** r, /usr/share/ssl/certs/ca-bundle.crt r, -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [pkg-apparmor] Fwd: Re: aa-unconfined shows tor as being unconfined, aa-status says different
Hello, Am Montag, 2. Februar 2015 schrieb John Johansen: On 02/02/2015 07:51 AM, Christian Boltz wrote: Does it work if you change aa-unconfined line 66? Untested pseudo-patch: -if line.startswith(/) or line.startswith(null): + if line.strip() != unconfined: hrmmm, the null check is interesting. The only place you should hit that is in learning mode when there is no profile associated, which Right. from a confinement pov is unconfined I'd say it's complain mode (with a strange[tm] profile mode, but still complain mode). The old code included null* profiles - but it excluded profile names not starting with / so I would probably keep that if line.strip() != unconfined or line.startswith(null): Hint: a line that starts with null will always be != 'unconfined', so the additional check doesn't change anything ;-) of course that won't work for namespaced stuff but no one is using that yet. That's another can of worms ;-) Regards, Christian Boltz -- If you spend more on coffee than on IT security, then you will be hacked. [Richard A. Clarke / 2002] -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [pkg-apparmor] Fwd: Re: aa-unconfined shows tor as being unconfined, aa-status says different
On 02/02/2015 10:58 AM, Christian Boltz wrote:
Hello,
Am Montag, 2. Februar 2015 schrieb u:
Christian Boltz:
Am Montag, 2. Februar 2015 schrieb u:
While playing around with `aa-unconfined` i saw that /usr/bin/tor
is
marked as not being confined.
Does it work if you change aa-unconfined line 66? Untested
pseudo-patch: -if line.startswith(/) or
line.startswith(null):
+ if line.strip() != unconfined:
Actually, yes!
If I use your line, i get:
1609 /usr/bin/tor confined by 'system_tor (enforce)'
instead of
1609 /usr/bin/tor not confined
Thanks for testing!
Some IRC discussion brought up that it's probably better to check for
' (complain)' and ' (enforce)', so here's the patch:
Fix aa-unconfined to work with profile names that don't start with / or null
I propose this patch for 2.9 and trunk.
[ aa-unconfined--named-profiles.diff ]
=== modified file 'utils/aa-unconfined'
--- utils/aa-unconfined 2014-09-14 18:17:00 +
+++ utils/aa-unconfined 2015-02-02 18:50:07 +
@@ -63,8 +63,9 @@
if os.path.exists(/proc/%s/attr/current%pid):
with aa.open_file_read(/proc/%s/attr/current%pid) as current:
for line in current:
-if line.startswith(/) or line.startswith(null):
-attr = line.strip()
+line = line.strip()
+if line.endswith(' (complain)', 1) or line.endswith('
(enforce)', 1): # enforce at least one char as profile name
+attr = line
cmdline = apparmor.common.cmd([cat, /proc/%s/cmdline%pid])[1]
pname = cmdline.split(\0)[0]
This wfm,
Acked-by: John Johansen john.johan...@canonical.com
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
