[apparmor] [opensuse-factory] Features making it into 12.1 for blog

John Johansen john.johansen at canonical.com
Tue Sep 27 02:09:31 UTC 2011


On 09/26/2011 04:38 PM, Christian Boltz wrote:
> Hello,
> 
> on Montag, 26. September 2011, Ludwig Nussel wrote:
>> Christian Boltz wrote:
>>> - start aa-notify using sudo:
>>>       sudo HOME="$HOME" DISPLAY="$DISPLAY" /usr/sbin/aa-notify -p
> 
> For the records: at least HOME=... isn't needed anymore - the upstream 
> version (post-2.7beta2) now sets $HOME correctly.
> 
>>>   This is also where I found the bug mentioned above - sudo drops
>>>   lots of environment variables for security reasons. In practise,
>>>   it drops too many of them and breaks aa-notify :-(
>>
>> IOW aa-notify is either broken by design or not meant to be run as
>> user. 
> 
> I'm not sure about your first option ;-)) but I'm sure the second one 
> doesn't apply.
> 
> aa-notify must be started as root (to be able to read audit.log) and 
> then drops the privileges to the user (which is autodetected from the 
> $SUDO_* environment variables when started with sudo) to display the 
> notifications.
> 
> Well, to be exact: aa-notify sets its EUID/EGID to the user, switches 
> back to root once per second to check audit.log for changes, and back to 
> the user afterwards and displays a notification if needed. That's still 
> simplified, but you should get the picture.
> 
> The interesting part is that it works with sudo on Ubuntu out of the 
> box. They seem to use a less strict configuration that doesn't remove 
> most of the environment variables - for example, $HOME isn't changed to 
> /root on Ubuntu, and $DISPLAY isn't removed - see "sudo env" results 
> from Ubuntu on http://paste.opensuse.org/70652816. 
> This is probably a compile-time config option because using a known-
> working /etc/sudoers from Ubuntu didn't make it work on my openSUSE 11.4 
> system.
> 
> In other words, it's the usual problem: everything works until I 
> test it. Then I find a bug, find another bug, and then it tends to 
> explode... ;-)
> 
>> A better solution would be to have a dbus system service that
>> can read the audit log or even subscribe to events directly. The UI
>> would run in the user's session and connect to that system service.
>> To restrict who can read the events policykit can be used.
> 
> I don't know much about dbus and policykit, but your idea sounds good.
> 
> Unfortunately it also sounds like it would require a (complete?) rewrite 
> of aa-notify, which will need some time...
> 
Not a complete rewrite, just a few fn's to add a new source, and any of
the bits around it.  This is already done for audit and syslog, and
push based alternatives are planned but they won't happen for this release.



More information about the AppArmor mailing list