Although we don't have any prospect of a generic, non-root solution to
sandboxing on Linux we can target Apparmor on Ubuntu and SELInux on
Fedora.
Apparmor on Ubuntu is pretty straight-forward. It triggers based on
the path of the binary. We can hard link
/opt/chromium.org/chromium/chrome-renderer to chrome and have
different triggers for each.
The configs are kept in /etc/apparmor.d and here's one which works for
our renderers:
#include <tunables/global>
/dev/chromium/chrome/Hammer/chrome-renderer {
#include <abstractions/base>
#include <abstractions/fonts>
/proc/** r,
/dev/shm/** rwk,
/dev/chromium/chrome/Hammer/** r,
network,
}
The /dev/shm access is needed because we still have to change the
visited link table to use capabilities, not names. The "network" line
grants full network access, which is very unfortunate. It seems that
Apparmor thinks UNIX domain sockets are AF_INET and it cannot
distinguish between socket creation and use. There may be ways around
this, but I suspect it'll involve kernel patches. I can do that and
push upstream, but it'll take time to deploy and we have do the best
we can with what we've got.
If you drop this in a file in /etc/apparmour.d, then you can load the
profile in enforcing mode with:
# apparmor_parser -r <filename>
You can also put it in 'complain' mode (where violations are logged to
dmesg) with:
# apparmor_parser -Cr <filename.
mmoss: If I land a patch which checks for, and uses if found, |our
binary name| + "-renderer", is that reasonable? Could the packages
then make the hard link and ship an apparmor profile?
AGL
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
