[apparmor] new extras/usr.lib.chromium-browser.chromium-browser profile

John Johansen john.johansen at canonical.com
Wed Jan 12 22:20:51 UTC 2011


On 01/12/2011 10:23 AM, Kees Cook wrote:
> On Wed, Jan 12, 2011 at 12:15:00AM -0600, Jamie Strandboge wrote:
>>   # chromium mmaps all kinds of things for speed.
>>   /etc/passwd m,
>>   /usr/share/fonts/truetype/**/*.tt[cf] m,
>>   /usr/share/fonts/**/*.pfb m,
>>   /usr/share/mime/mime.cache m,
>>   /usr/share/icons/**/*.cache m,
>>   owner /dev/shm/pulse-shm* m,
>>   owner @{HOME}/.local/share/mime/mime.cache m,
>>   owner /tmp/** m,
> 
> This isn't right. mmap(... PROT_READ ...) doesn't map to the "m" flag,
> only mmap(... PROT_EXEC ...) is "m". If something is using mmap on
> non-executable files and it requires "m", it usually means that they're
> running with an executable stack, which triggers the READ_IMPLIES_EXEC
> personality.
> 
> I'm uncomfortable with allowing "m" for non-executables (though it's
> probably a non-issue). So, I don't really want to ACK this as-is. I'd
> rather figure out why chromium is misbehaving with its mmap. That said I'm
> not NACKing it either, so if someone else is happy with it, go for it. :)
> 
I'm with kees this needs to be looked at closer, in the end I expect if
we want a profile to work we may to accept that this is what chromium
is doing.



More information about the AppArmor mailing list