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
pgpGxt3PNDdqO.pgp
Description: PGP signature
