[opensuse-factory] Apparmor crashes when trying to scan profile
Hey guys, When I try to scan the profile that is generated for firefox, apparmor crashes. I have filed a bug with the exact error here: http://bugzilla.opensuse.org/show_bug.cgi?id=900163 As far as I can tell it should work fine as I followed the instruction on active doc but clearly there is something wrong. If someone could take a look at it/help me figure out what is wrong it would be much appreciated. Regards, Uzair -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Dienstag, 7. Oktober 2014 schrieb alanbortu:
When I try to scan the profile that is generated for firefox, apparmor crashes. I have filed a bug with the exact error here: http://bugzilla.opensuse.org/show_bug.cgi?id=900163
As far as I can tell it should work fine as I followed the instruction on active doc but clearly there is something wrong. If someone could take a look at it/help me figure out what is wrong it would be much appreciated.
Ah, charset "fun" with python3... Your /var/log/messages contains lines that aren't valid utf8, and python3 by default expects everything to be utf8. (For comparison: python2 doesn't do charset magic and "just works"[tm].) Please apply the following patch to /usr/lib/python3.4/site-packages/apparmor/logparser.py === modified file 'utils/apparmor/logparser.py' --- utils/apparmor/logparser.py 2014-08-20 22:55:44 +0000 +++ utils/apparmor/logparser.py 2014-09-22 23:11:23 +0000 @@ -330,7 +330,7 @@ #event_type = None try: #print(self.filename) - self.LOG = open_file_read(self.filename) + self.LOG = open(self.filename, 'r', errors='surrogateescape') except IOError: raise AppArmorException('Can not read AppArmor logfile: ' + self.filename) #LOG = open_file_read(log_open) This is probably not the final patch (it breaks compability with python2, which we keep upstream), but it should work ;-) I'll update the bugreport when the official/upstream patch is ready. Regards, Christian Boltz --
good luck, Usually "good luck" is going together with "as I told you before" :) [> Greg KH and Johannes Nohl in opensuse-project]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Oct 8, 2014 at 4:50 PM, Christian Boltz
=== modified file 'utils/apparmor/logparser.py' --- utils/apparmor/logparser.py 2014-08-20 22:55:44 +0000 +++ utils/apparmor/logparser.py 2014-09-22 23:11:23 +0000 @@ -330,7 +330,7 @@ #event_type = None try: #print(self.filename) - self.LOG = open_file_read(self.filename) + self.LOG = open(self.filename, 'r', errors='surrogateescape') except IOError: raise AppArmorException('Can not read AppArmor logfile: ' + self.filename) #LOG = open_file_read(log_open)
This is probably not the final patch (it breaks compability with python2, which we keep upstream), but it should work ;-)
You should open the file in binary mode if you expect byte strings -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Mittwoch, 8. Oktober 2014 schrieb Claudio Freire:
On Wed, Oct 8, 2014 at 4:50 PM, Christian Boltz wrote:
+ self.LOG = open(self.filename, 'r', errors='surrogateescape')
This is probably not the final patch (it breaks compability with python2, which we keep upstream), but it should work ;-)
You should open the file in binary mode if you expect byte strings
In theory you are right. In practise, this opens another can of worms because python3 errors out if you for example compare the content of a "binary" variable (containing only ASCII text) with some non-binary ASCII text. I already had some "fun" with this... ;-) With python2, this "just worked" - but I'd like to avoid using the old version unless really needed. [insert rant about incompatible changes between python versions here] That said - the log lines that are relevant for AppArmor are guaranteed to be ASCII (filenames with non-ASCII characters are encoded in the log), which means the patch only modifies lines that are read and instantly thrown away ;-) Regards, Christian Boltz --
IIRC gab es ÜHER mal so seltsame rechteckige Blöcke mit vielen einzelnen Blättern aus Zellulosefasern in denen man Rezepte nachlesen konnte... aber frag' mich jetzt nur nicht, wie die hießen. Du redest doch wohl nicht von ermordeten Bäumen? [>T. Braun und S. Posner]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/08/2014 03:50 PM, Christian Boltz wrote:
Hello,
Am Dienstag, 7. Oktober 2014 schrieb alanbortu:
When I try to scan the profile that is generated for firefox, apparmor crashes. I have filed a bug with the exact error here: http://bugzilla.opensuse.org/show_bug.cgi?id=900163
As far as I can tell it should work fine as I followed the instruction on active doc but clearly there is something wrong. If someone could take a look at it/help me figure out what is wrong it would be much appreciated.
Ah, charset "fun" with python3...
Your /var/log/messages contains lines that aren't valid utf8, and python3 by default expects everything to be utf8. (For comparison: python2 doesn't do charset magic and "just works"[tm].)
Please apply the following patch to /usr/lib/python3.4/site-packages/apparmor/logparser.py
=== modified file 'utils/apparmor/logparser.py' --- utils/apparmor/logparser.py 2014-08-20 22:55:44 +0000 +++ utils/apparmor/logparser.py 2014-09-22 23:11:23 +0000 @@ -330,7 +330,7 @@ #event_type = None try: #print(self.filename) - self.LOG = open_file_read(self.filename) + self.LOG = open(self.filename, 'r', errors='surrogateescape') except IOError: raise AppArmorException('Can not read AppArmor logfile: ' + self.filename) #LOG = open_file_read(log_open)
This is probably not the final patch (it breaks compability with python2, which we keep upstream), but it should work ;-)
I'll update the bugreport when the official/upstream patch is ready.
Regards,
Christian Boltz
Thank you for the reply and explanation , how do I apply this patch? I am just a silly end user :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Mittwoch, 8. Oktober 2014 schrieb alanbortu:
On 10/08/2014 03:50 PM, Christian Boltz wrote:
Am Dienstag, 7. Oktober 2014 schrieb alanbortu:
When I try to scan the profile that is generated for firefox, apparmor crashes. I have filed a bug with the exact error here: http://bugzilla.opensuse.org/show_bug.cgi?id=900163
Please apply the following patch to
Thank you for the reply and explanation , how do I apply this patch? I am just a silly end user :)
There is a little tool named "patch" that can do it for you. In this case, the easiest way is to edit (as root) /usr/lib/python3.4/site-packages/apparmor/logparser.py Search for the line self.LOG = open_file_read(self.filename) (that should be line 333) and replace it with self.LOG = open(self.filename, 'r', errors='surrogateescape') Note that python is quite picky about whitespace, so make sure to have exactly the same number of spaces at the beginning of the line. That should also explain how a patch "works" - lines starting with "-" are deleted, lines starting with "+" are added and lines starting with a space are there for context so that you can see the lines around the added and deleted lines. Regards, Christian Boltz -- Bei Windows hat man Mailreader, der alles kann. Bei Linux hat man ein MUA, das eigentlich gar nichts kann, aber das verdammt gut. [Bernd Brodesser in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/08/2014 07:43 PM, Christian Boltz wrote:
Search for the line self.LOG = open_file_read(self.filename) (that should be line 333) and replace it with self.LOG = open(self.filename, 'r', errors='surrogateescape')
Note that python is quite picky about whitespace, so make sure to have exactly the same number of spaces at the beginning of the line.
That should also explain how a patch "works" - lines starting with "-" are deleted, lines starting with "+" are added and lines starting with a space are there for context so that you can see the lines around the added and deleted lines.
It worked, thanks a lot :D -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Another isssue, when I run aa-genprof firefox, do some actions, scan the logs and finish, all I get is this: http://paste.opensuse.org/view/raw/87541501 I have tried all sorts of things but no matter what I do, I get a basic profile like that which is so strict I cannot even start firefox when in enforce mode. Any ideas on what is going on? Will file a bug later today after work but figured I should ask for input before doing so. Thanks, Uzair -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Oct 9, 2014 at 7:12 AM, alanbortu
Another isssue, when I run aa-genprof firefox, do some actions, scan the logs and finish, all I get is this: http://paste.opensuse.org/view/raw/87541501
I have tried all sorts of things but no matter what I do, I get a basic profile like that which is so strict I cannot even start firefox when in enforce mode. Any ideas on what is going on? Will file a bug later today after work but figured I should ask for input before doing so.
I guess it's because what you run with "firefox" is a wrapper (didn't know that, just found out, huh): ~> which firefox /usr/bin/firefox ~> file /usr/bin/firefox /usr/bin/firefox: symbolic link to `../lib64/firefox/firefox.sh' ~> cat /usr/lib64/firefox/firefox.sh #!/bin/sh ... bla ... ## ## Variables ## MOZ_DIST_BIN="/usr" MOZ_DIST_LIB="/usr/lib64/firefox" MOZ_APPNAME="firefox" MOZ_PROGRAM="$MOZ_DIST_LIB/$MOZ_APPNAME" ... bla ... exec $MOZ_PROGRAM "$@" I suggest you do aa-genprof /usr/lib64/firefox/firefox -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Donnerstag, 9. Oktober 2014 schrieb Claudio Freire:
On Thu, Oct 9, 2014 at 7:12 AM, alanbortu
wrote: Another isssue, when I run aa-genprof firefox, do some actions, scan the logs and finish, all I get is this: http://paste.opensuse.org/view/raw/87541501
I have tried all sorts of things but no matter what I do, I get a basic profile like that which is so strict I cannot even start firefox when in enforce mode. Any ideas on what is going on? Will file a bug later today after work but figured I should ask for input before doing so. I guess it's because what you run with "firefox" is a wrapper (didn't know that, just found out, huh):
~> which firefox /usr/bin/firefox ~> file /usr/bin/firefox /usr/bin/firefox: symbolic link to `../lib64/firefox/firefox.sh' ~> cat /usr/lib64/firefox/firefox.sh
aa-genprof already noticed that - the profile was created for the symlink target /usr/lib64/firefox/firefox.sh
I suggest you do aa-genprof /usr/lib64/firefox/firefox
In theory, aa-genprof should catch it when another binary is executed, and ask in which mode it should be executed. In practise, aa-genprof just generated a very basic profile [1], but didn't add any rules besides that. I'm not surprised that firefox won't run with this profile ;-) Can you please run aa-genprof firefox again and, if it still/again fails, paste the screen log of the whole aa-genprof run? (Just to be sure - you pressed "s" for "(S)can sytem log" in aa-genprof at least once before pressing "f" for (F)inish?) Regards, Christian Boltz [1] in case you are interested - it internally calls aa-autodep --
beim Übersetzen von qcad steigt die Prozessorauslastung von cc1plus bis auf 98% an. Dasist doch nicht üblich, oder? Warum stört Dich das? Du hast doch die ganze CPU bezahlt, oder? Oder hast Du nur 'ne halbe? [> Stefan Schlörholz und Andreas Kyek in suse-linux]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Oct 9, 2014 at 3:55 PM, Christian Boltz
I suggest you do aa-genprof /usr/lib64/firefox/firefox
In theory, aa-genprof should catch it when another binary is executed, and ask in which mode it should be executed.
In practise, aa-genprof just generated a very basic profile [1], but didn't add any rules besides that. I'm not surprised that firefox won't run with this profile ;-)
It generated a profile for bash, right up to the point where it called exec.
Even though it used the symlink target, it still smells like a profile
of the bash wrapper.
On Thu, Oct 9, 2014 at 4:11 PM, Christian Boltz
Hello,
Am Mittwoch, 8. Oktober 2014 schrieb Claudio Freire:
On Wed, Oct 8, 2014 at 4:50 PM, Christian Boltz wrote:
+ self.LOG = open(self.filename, 'r', errors='surrogateescape')
This is probably not the final patch (it breaks compability with python2, which we keep upstream), but it should work ;-)
You should open the file in binary mode if you expect byte strings
In theory you are right.
In practise, this opens another can of worms because python3 errors out if you for example compare the content of a "binary" variable (containing only ASCII text) with some non-binary ASCII text. I already had some "fun" with this... ;-)
In that case, you can decode the ASCII text (with proper error behavior) right after reading the lines (and encode right before writing) with codecs.open. That will be compatible with both versions of python, and is in fact the right way of handling text files. That will modify lines with encoding errors, though. So if you want to keep those intact, you will have to do the decoding/encoding manually. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Donnerstag, 9. Oktober 2014 schrieb Claudio Freire:
On Thu, Oct 9, 2014 at 3:55 PM, Christian Boltz wrote:
I suggest you do aa-genprof /usr/lib64/firefox/firefox
In theory, aa-genprof should catch it when another binary is executed, and ask in which mode it should be executed.
In practise, aa-genprof just generated a very basic profile [1], but didn't add any rules besides that. I'm not surprised that firefox won't run with this profile ;-)
It generated a profile for bash, right up to the point where it called exec.
Even though it used the symlink target, it still smells like a profile of the bash wrapper.
Yes, but this profile at least needs a rule that allows to execute the "real" binary ;-) After some discussion on IRC we found out what causes the problem. rsyslog uses a very interesting[tm] timestamp format, which isn't matched by the AppArmor log parsing library. (That seems to be a config option, Ubuntu also uses rsyslog, but has a different timestamp format.) The workaround is to use auditd for logging AppArmor-related events: zypper in audit rcauditd start systemctl enable auditd.service aa-logprof and aa-genprof will automatically switch to using /var/log/audit/audit.log if the file exists.
On Thu, Oct 9, 2014 at 4:11 PM, Christian Boltz wrote:
Am Mittwoch, 8. Oktober 2014 schrieb Claudio Freire:
On Wed, Oct 8, 2014 at 4:50 PM, Christian Boltz wrote:
+ self.LOG = open(self.filename, 'r', errors='surrogateescape')
This is probably not the final patch (it breaks compability with python2, which we keep upstream), but it should work ;-)
You should open the file in binary mode if you expect byte strings
In theory you are right.
In practise, this opens another can of worms because python3 errors out if you for example compare the content of a "binary" variable (containing only ASCII text) with some non-binary ASCII text. I already had some "fun" with this... ;-)
In that case, you can decode the ASCII text (with proper error behavior) right after reading the lines (and encode right before writing) with codecs.open.
That will be compatible with both versions of python, and is in fact the right way of handling text files.
Well, s/fact/& still/ ;-) See http://bugs.python.org/issue8796 and [insert rant here]
That will modify lines with encoding errors, though. So if you want to keep those intact, you will have to do the decoding/encoding manually.
That's what the original code did (open_file_read() is just a wrapper for codecs.open [1]) - obviously not too successful. Maybe we need different parameters... Hmm, adding errors='replace' (or 'ignore') should work. I'll need to test that tomorrow ;-) Regards, Christian Boltz [1] def open_file_read(path, encoding='UTF-8'): '''Open specified file read-only''' try: orig = codecs.open(path, 'r', encoding) except Exception: raise return orig -- Journal is just for "fun" (well, strange values of "fun") for now and the foreseeable future. [Stefan Seyfried in opensuse-factory] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
In practise, this opens another can of worms because python3 errors out if you for example compare the content of a "binary" variable (containing only ASCII text) with some non-binary ASCII text. I already had some "fun" with this... ;-)
In that case, you can decode the ASCII text (with proper error behavior) right after reading the lines (and encode right before writing) with codecs.open.
That will be compatible with both versions of python, and is in fact the right way of handling text files.
Well, s/fact/& still/ ;-) See http://bugs.python.org/issue8796 and [insert rant here]
Ah, yes. I remembered that, googled before posting, and couldn't find it, so I assumed I remembered wrong.
That will modify lines with encoding errors, though. So if you want to keep those intact, you will have to do the decoding/encoding manually.
That's what the original code did (open_file_read() is just a wrapper for codecs.open [1]) - obviously not too successful. Maybe we need different parameters...
Ah, didn't delve into what open_file_read was.
Hmm, adding errors='replace' (or 'ignore') should work. I'll need to test that tomorrow ;-)
Indeed. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/09/2014 07:37 PM, Christian Boltz wrote:
Hello, The workaround is to use auditd for logging AppArmor-related events:
zypper in audit rcauditd start systemctl enable auditd.service
aa-logprof and aa-genprof will automatically switch to using /var/log/audit/audit.log if the file exists.
It seems to have stopped working :( I no longer get prompted to permit/block things and the profile is back to the generic one from before with firefox being unable to start. http://paste.opensuse.org/73720738 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, just FYI: AppArmor 2.9 final was released yesterday and fixes several bugs, especially in the aa-* tools. It's already available in security:apparmor - feel free to install it from there and test it. SR 257521 to Factory is pending. I'll also submit it to 13.2 ASAP (this has to be done from Factory, so the timing depends on getting it accepted into Factory). Regards, Christian Boltz -- Warning: Sleeping Sigmonster! Please do not disturb. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/09/2014 02:55 PM, Christian Boltz wrote:
Hello,
Can you please run aa-genprof firefox again and, if it still/again fails, paste the screen log of the whole aa-genprof run?
(Just to be sure - you pressed "s" for "(S)can sytem log" in aa-genprof at least once before pressing "f" for (F)inish?)
Regards,
Christian Boltz
Here you are: http://paste.opensuse.org/view/raw/26656311 No matter how many times I scan (whether it is once or 4 times) I always get that profile. All the files in the directory are owned by root with 644 permissions. Thanks for the support, Uzair -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
alanbortu
-
Christian Boltz
-
Claudio Freire