On Mon, Jan 22, 2007 at 08:21:18PM +0000, Peter Bradley wrote:
Jan 22 19:32:45 linux kernel: SubDomain: REJECTING r access to /bin/bash (acroread(13724) profile /usr/X11R6/bin/acroread active /usr/X11R6/bin/acroread)
Yes and no. I've done the upgrade, but the problems started yesterday. I'll have a go at AppArmor and "report back"
Did it happen when you did something specifically? Acroread has a ton of little buttons and I wouldn't be surprised if one or more of them wanted to run a script or just calls out to system(3) to execute helpers.
Yes, it did seem to be AppArmor. I had to go through several iterations of the Wizard because setting one problem to "Allow" or "Inherit" (depending on what it offered me) caused a different problem the next time round. However after about half a dozen times around the block, it allowed acroread to run as before.
If you're expecting this kind of behaviour, it can be helpful to put a profile into 'learning mode'. You _can_ do this one-failure-at-a-time (and, in fact, I did for years :) but it quickly gets tiring. You can run: aa-complain acroread (or, if your installation is too old to have the handy aa- prefix, simply 'complain acroread') Now you can exercise your application and run a single aa-logprof (or the wizard) session at the end. Once you're done, you can run: aa-enforce acroread
Just to give you an example of what it was asking as it iterated, it was asking for permission on things like /bin/bash/ls - which I guess is to allow it to list files in the file open dialog ...
More likely it's running a shell script of some sort; /etc/bash.bashrc is my best guess. An application shouldn't need to call out to 'ls' to get a file listing.
There were also some other restrictions that AppArmor reported on Apache and on Zend. I clicked to allow those as well, which I hope hasn't done any harm. I can't imagine why it should.
Depends if the events were for active attacks. :) It's probably fine, but you're in the best position to judge the individual events.
Please let me know if you think I've done anything I shouldn't; but at least things are working again.
You did things just fine: we expect users to customize their apparmor profiles to fit how they use their machines. :) In fact, we ship a pile of disabled profiles in /etc/apparmor/profiles/extras/ These profiles are disabled by default beacuse they may be too old for us to have faith in them or because they may require a lot of site-specific configuration to ensure they work well. Feel free to copy profiles from here into /etc/apparmor.d/, reload policy, and customize as you wish. If you wish to turn on postfix, it'd be best to read the README in that directory -- there are a lot of interlinking pieces that should all be in place. The README helps sort out how to do this. (I'll even happily accept new submissions, bugfixes, etc. :) Thanks