[apparmor] [profile] Firefox: aa-profile(8) - multiple results; audit all unexpected shadow or passwd read/writes.

[Seth Arnold]

On Wed, Dec 14, 2016 at 07:44:18PM +0100, daniel curtis wrote:
> Since Firefox has been updated to the version 49/50 and since e10s is
> [...]
> Is it normal, or something need to be changed in, for example, Firefox
> profile? What do you think? Now, the second question - blueprints for a

This is normal; part of the electrolysis changes in Firefox is adding more
processes. I think the goal is one process per tab though perhaps they'll
use even more than that. This is the best way to start reducing the
privileges needed for e.g. rendering images, movies, flash objects, etc.
Once there's multiple processes doing specific tasks they can start
rolling out better sandboxing. Multiple processes also allows Firefox to
use multiple CPU cores, which is increasingly important as CPU speeds have
hit their ceiling but are having no trouble adding more and more cores.

> Firefox profile [1] Under *Misc we can find an interesting thing:
> 
> * general rule to audit all unexpected shadow or passwd read/writes
> 
> This blueprints has been registered by Mr Kees Cook on 2009-04-27; long
> time ago, so maybe it's not necessary at all? Anyway, I thought about it
> and I would like to ask if there is a reason to add, for example, these two
> rules:
> 
> audit deny /etc/shadow rw,
> audit deny /etc/passwd rw,
> 
> I don't see any 'audit deny' rules in a Firefox profile shipped with a
> default Ubuntu installation (at least to 12.04 LTS release). There are also
> 'passwd-' and 'shadow-' files, right? If above rules are OK, does these
> last two files also should be added?

Most of Ubuntu has ignored the blueprints for years; feel free to do the
same. ;)

There'd be no real point to auditing denying writes to these files from
the Firefox profile -- AppArmor wouldn't even see the attempt to write to
these files if Firefox is being run by a standard user, because the
traditional Unix access controls would forbid the attempt before querying
AppArmor for permission. They would simply take up extra space in the
profile (and thus take up space in unswappable kernel memory) on the
_possibility_ that Firefox would be run as root and someone would have an
exploit against Firefox when run by root. It's pretty unlikely.

What makes more sense is the 'audit deny' rules in the file:
abstractions/ubuntu-browsers.d/user-files
which are included via the file:
abstractions/ubuntu-browsers.d/firefox

$ grep 'audit deny' abstractions/ubuntu-browsers.d/user-files
  audit deny @{HOME}/.ssh/** mrwkl,
  audit deny @{HOME}/.gnome2_private/** mrwkl,
  audit deny @{HOME}/.kde{,4}/share/apps/kwallet/** mrwkl,
  audit deny @{HOME}/.gnupg/** mrwkl,

It's plausible that an attack could be written against these higher-value
files. So we want to be warned about it if something attempts to use them.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20161214/c678e90f/attachment.pgp>