The default build using the google repos results in chromium grinding to a halt with a black window when run in a sandbox. Is it technically possible to run chrome in a sandbox, would building from source fix this at all?
On Sun, 2011-06-19 at 13:57 +0100, GSO wrote:
The default build using the google repos results in chromium grinding to a halt with a black window when run in a sandbox. Is it technically possible to run chrome in a sandbox, would building from source fix this at all?
I do not think it will work since both sandbox an chrome use namespace and chrome cant run if sandbox already runs in a namespace (or something along those lines is my understanding if this issue)
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
I've posted over on chromium-discuss https://groups.google.com/a/chromium.org/group/chromium-discuss/browse_threa... no reply so far though
The main wiki page on the subject seems to be here... https://code.google.com/p/chromium/wiki/LinuxSandboxing There seem to be various sandbox compiling options, might one of these be an option!
Chromium seems to work OK in the sandbox with the --no-sandbox chromium option, though with the obvious caveats... https://groups.google.com/group/google-chrome-help-troubleshooting/browse_th...
On 19 June 2011 17:53, Dominick Grift domg472@gmail.com wrote:
On Sun, 2011-06-19 at 13:57 +0100, GSO wrote:
The default build using the google repos results in chromium grinding to
a
halt with a black window when run in a sandbox. Is it technically
possible
to run chrome in a sandbox, would building from source fix this at all?
I do not think it will work since both sandbox an chrome use namespace and chrome cant run if sandbox already runs in a namespace (or something along those lines is my understanding if this issue)
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/20/2011 03:46 AM, GSO wrote:
I've posted over on chromium-discuss https://groups.google.com/a/chromium.org/group/chromium-discuss/browse_threa...
- no reply so far though
The main wiki page on the subject seems to be here... https://code.google.com/p/chromium/wiki/LinuxSandboxing There seem to be various sandbox compiling options, might one of these be an option!
Chromium seems to work OK in the sandbox with the --no-sandbox chromium option, though with the obvious caveats... https://groups.google.com/group/google-chrome-help-troubleshooting/browse_th...
On 19 June 2011 17:53, Dominick Grift <domg472@gmail.com mailto:domg472@gmail.com> wrote:
On Sun, 2011-06-19 at 13:57 +0100, GSO wrote: > The default build using the google repos results in chromium grinding to a > halt with a black window when run in a sandbox. Is it technically possible > to run chrome in a sandbox, would building from source fix this at all? I do not think it will work since both sandbox an chrome use namespace and chrome cant run if sandbox already runs in a namespace (or something along those lines is my understanding if this issue) > -- > selinux mailing list > selinux@lists.fedoraproject.org <mailto:selinux@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/selinux-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
We have been looking into this issue, and are not sure what is causing the problem. It is definitely related to namespace. If you run in permissive mode and run
sandbox -X xterm
Then run chrome you will see it complain about the namespace. One issue we saw was we were removing the Capabilities bounding set and thought chrome could not get capabilities, but we changed seunshare to not modify the bounding set, so now we do not believe it is caused by capabilities.
I believe it is something to do with namespace interaction.
This thread went offline, however to bring things back online, it appears at least the binary download (running on SL6) of Firefox 5 just released does not work in the sandbox either. The SELinux audit messages are:
Jun 22 21:40:22 localhost kernel: SELinux: Permission audit_access in class dir not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission execmod in class dir not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission audit_access in class lnk_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission open in class lnk_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission execmod in class lnk_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission audit_access in class chr_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission audit_access in class blk_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission execmod in class blk_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission audit_access in class sock_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission execmod in class sock_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission audit_access in class fifo_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission execmod in class fifo_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission syslog in class capability2 not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: the above unknown classes and permissions will be allowed Jun 22 21:40:24 localhost dbus: avc: received policyload notice (seqno=5) Jun 22 21:40:24 localhost dbus: avc: received policyload notice (seqno=5) Jun 22 21:40:24 localhost dbus: avc: received policyload notice (seqno=5) Jun 22 21:40:24 localhost dbus: avc: received policyload notice (seqno=5) Jun 22 21:40:24 localhost dbus: avc: received policyload notice (seqno=5) Jun 22 21:40:24 localhost dbus: [system] Reloaded configuration
The sandbox window starts up but crashes before any sign of FF materialises, works fine in permissive mode or unsandboxed otherwise. I've put the FF binaries in /opt.
On 19 June 2011 17:53, Dominick Grift domg472@gmail.com wrote:
On Sun, 2011-06-19 at 13:57 +0100, GSO wrote:
The default build using the google repos results in chromium grinding to
a
halt with a black window when run in a sandbox. Is it technically
possible
to run chrome in a sandbox, would building from source fix this at all?
I do not think it will work since both sandbox an chrome use namespace and chrome cant run if sandbox already runs in a namespace (or something along those lines is my understanding if this issue)
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/23/2011 06:29 AM, GSO wrote:
This thread went offline, however to bring things back online, it appears at least the binary download (running on SL6) of Firefox 5 just released does not work in the sandbox either. The SELinux audit messages are:
Jun 22 21:40:22 localhost kernel: SELinux: Permission audit_access in class dir not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission execmod in class dir not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission audit_access in class lnk_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission open in class lnk_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission execmod in class lnk_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission audit_access in class chr_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission audit_access in class blk_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission execmod in class blk_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission audit_access in class sock_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission execmod in class sock_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission audit_access in class fifo_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission execmod in class fifo_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission syslog in class capability2 not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: the above unknown classes and permissions will be allowed Jun 22 21:40:24 localhost dbus: avc: received policyload notice (seqno=5) Jun 22 21:40:24 localhost dbus: avc: received policyload notice (seqno=5) Jun 22 21:40:24 localhost dbus: avc: received policyload notice (seqno=5) Jun 22 21:40:24 localhost dbus: avc: received policyload notice (seqno=5) Jun 22 21:40:24 localhost dbus: avc: received policyload notice (seqno=5) Jun 22 21:40:24 localhost dbus: [system] Reloaded configuration
The sandbox window starts up but crashes before any sign of FF materialises, works fine in permissive mode or unsandboxed otherwise. I've put the FF binaries in /opt.
On 19 June 2011 17:53, Dominick Grift <domg472@gmail.com mailto:domg472@gmail.com> wrote:
On Sun, 2011-06-19 at 13:57 +0100, GSO wrote: > The default build using the google repos results in chromium grinding to a > halt with a black window when run in a sandbox. Is it technically possible > to run chrome in a sandbox, would building from source fix this at all? I do not think it will work since both sandbox an chrome use namespace and chrome cant run if sandbox already runs in a namespace (or something along those lines is my understanding if this issue) > -- > selinux mailing list > selinux@lists.fedoraproject.org <mailto:selinux@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/selinux-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
I looked for firefox5 x86_64 and did not quickly find it, if you know where there is a link, I will look into what is going on, otherwise I will wait until Fedora Packages it. It does seem strange that you are getting those
Permission audit_access in class sock_file not defined in policy.
errors, What OS are you using? What kernel?
On 06/23/2011 06:29 AM, GSO wrote:
Jun 22 21:40:22 localhost kernel: SELinux: Permission execmod in class fifo_file not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: Permission syslog in class capability2 not defined in policy. Jun 22 21:40:22 localhost kernel: SELinux: the above unknown classes and permissions will be allowed
These aren't a big deal. It just tells me that you are running a new kernel and an old policy. (upstream kernel with RHEL6 policy?) They are not the cause of your problem. Something else being dontaudit'd is likely the cause of the problem if it all works in permissive.
-Eric
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Dominick Grift -
Eric Paris -
GSO