arkose desktop integration without root permissions

Bug #1219836 reported by daemon dog
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Arkose - Desktop Application Sandboxing
New
Undecided
Unassigned

Bug Description

Blueprints aren't setup so I'm adding here hope that is ok.

It would be nice if Arkose had an inbuilt mechanism to create a container and start an application for users of a specific group without requiring root permissions. I'm not sure if suid and dropping root permission after the container is created etc. is a way to do this. I would conceptually see Arkose as a lowering of permissions to increase security in which case requiring root permissions would seem contrary to this requirement. The way I see it this sort of technology should be a standard part of a linux distribution including fully integrated control and configuration mechanisms etc. For example if I get a document or other attachment via email I should be able to default the attachment to open in a sandbox without additional setup and entering a password (I want to avoid giving the attachment root permission by mistake!). Likewise I would like to avoid making arkose a point of attack on a system.

At the moment what I'm trying to achive is the ability to default an application to start in a sandbox e.g. unknown http links in an email. Likewise if I configure a computer for another user I would like the browser to start in a sandbox without prompting for a password. What i've done as a temporary solution is to manipulate sudo to allow the application to start as root without prompting. I tried pkexec but it didn't seem to work properly when I tried directly via arkose but it looks like pkexec is being used with the wrapper?

The following is as applies to Ubuntu 12.04

sudoers entries...

sudo nano /etc/sudoers.d/arkose

ALL ALL=(ALL) NOPASSWD:/usr/bin/arkose firefox *
ALL ALL=(ALL) NOPASSWD:/usr/bin/arkose chromium-browser *

To allow other users to connect to the x server

sudo xhost local:root

Also may need to add this to sudoers after env reset

Defaults env_keep=DISPLAY
Defaults env_keep+=XAUTHORITY

Changing the default browser

Method 1

mkdir -p ~/.local/share/applications
cp /usr/share/applications/firefox.desktop ~/.local/share/applications/custom-browser.desktop

nano ~/.local/share/applications/custom-browser.desktop

-Exec=firefox %u
+Exec=gksudo arkose "firefox -no-remote %u"

or

+Exec=gksudo arkose "chromium-browser %u"

Example .desktop file

#!/usr/bin/env xdg-open

[Desktop Entry]
Version=1.0
Name=Secure Web Browser
Comment=Sandboxed Web Browser
Exec=gksudo arkose "firefox -no-remote %u"
Terminal=false
X-MultipleArgs=false
Type=Application
Icon=firefox
Categories=GNOME;GTK;Network;WebBrowser;
MimeType=text/html;text/xml;application/xhtml+xml;application/xml;application/rss+xml;application/rdf+xml;image/gif;image/jpeg;image/png;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/ftp;x-scheme-handler/chrome;video/webm;application/x-xpinstall;
StartupNotify=true
Actions=NewWindow;NewPrivateWindow;

Note: gksudo appears to remove quotes from Exec string and rewrite as gksudo arkose firefox -no-remote "%u"

update-desktop-database ~/.local/share/applications
xdg-settings set default-web-browser custom-browse.desktop

testing...

xdg-open http://www.stgraber.org/category/arkose/

Method 2

Create custom-browse.desktop as above but copy to /usr/share/applications

sudo cp ~/.local/share/applications/custom-browser.desktop /usr/share/applications/

Method 3

sudo nano /usr/share/applications/chromium-browser.desktop

-Exec=chromium-browser %u
+Exec=gksudo arkose "chromium-browser %u"

Other...

It might be nice if there was a way to attach a profile to an application for sandboxing. For example if there was a arkose.d in etc and I added firefox.conf then this would be used automatically (via some specification in the profile) when I start firefox?

I had some random issues with firefox and it was difficult to get it to start in arkose initially. These issues seemed to relate to some files that firefox requires that get created on first run (starting it a second time in the sanbox seemed to cure this). It wasn't consistent though indicating a possible race/timing issue. Also without the -no-remote option it was easy for the application to start outside the sandbox, presumably it only has regular user permissions at this point but it did make me wonder how easy it is to bypass the sandbox especially during startup. Suprisingly chromium worked without any issues and even gave itself a trendy blue background behind the tabs (not sure if that is intentional but was actually quite helpful - would be nice if ther was some default visulisation for sandboxed apps).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.