Ysgrifennodd Marcus Meissner:

On Mon, Jan 22, 2007 at 07:35:33PM +0000, Peter Bradley wrote:

...

For some reason, Acroread has stopped working. No great loss, I know, but I'd like to know what's going on. In /var/log/messages, I get:

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)

Huh? Anyone have any ideas?

Was this after todays security update?

ciao, Marcus

Hi Marcus, Yes and no. I've done the upgrade, but the problems started yesterday. I'll have a go at AppArmor and "report back" :) Peter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

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