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

[Jamie Strandboge]

On Wed, 12 Jan 2011 14:20:51 -0800, John Johansen
<john.johansen at canonical.com> wrote:
> 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.

I looked at this a little. I can say the binaries don't have an executable
stack (I checked this some time ago), but not sure why PROT_EXEC is getting
pulled in. There are some internal functions for dealing with memory that
are likely the culprit. I don't really have a lot of time to debug/suggest
solutions to Google for this, but can at least file a bug and maybe
something will come out of it.

Jamie