Brainstorm: Sandboxing...everything!

techprophet · 2009-08-08 19:16:19

What if each program had it's own permission set that allowed it to read only its own files and directories (along with, perhaps, .bashrc, .gconf, etc), and write to a symlinked ~/.programname directory?

The programs would be entirely unable to read anything else, or write anything else (short of getting you to give it root permissions).

As of right now, the only pro I can really think of for this is preventing malicious creation of .desktop files and/or ~ erasure.

There are probably a million things wrong with this...and only a few things it would solve, but the hive mind is stronger than that of a lone worker.

Dusty · 2009-08-08 20:17:49

That's pretty much the architecture Android uses.

Dusty

techprophet · 2009-08-08 21:02:09

Dusty wrote:

That's pretty much the architecture Android uses.
Dusty

Aye, that's where I got the idea from. That and Google Chrome (which sandboxes each tab)

Dieter@be · 2009-08-08 21:07:35

isn't this also what apparmor is about?

Stefan Husmann · 2009-08-08 21:18:59

If I get you right,you mean for instance a picture created by gimp cold not be altered by, let say, inkscape? Seems ridiculous to me.

techprophet · 2009-08-08 22:09:03

Stefan Husmann wrote:

If I get you right,you mean for instance a picture created by gimp cold not be altered by, let say, inkscape? Seems ridiculous to me.

Just one of the problems I hadn't thought of. There is probably a solution...somewhere.

Arisna · 2009-08-09 04:54:39

I guess there would need to be a privileged framework for shoveling data files between sandboxes. That might defeat the purpose of this, though.

techprophet · 2009-08-09 12:13:13

Arisna wrote:

I guess there would need to be a privileged framework for shoveling data files between sandboxes. That might defeat the purpose of this, though.

Maybe, unless you change the ~/.programname/ directories for each application to ~/programname/ (ie not hidden), it would let the user see the files and move them around more easily, while still locking in the applications.

Arisna · 2009-08-10 01:11:27

Hey, that sounds like a good tweak. It still might allow misbehaving applications to craft malicious data files that would do bad stuff in other programs... or something.

havok · 2009-08-10 16:41:33

i rather like this idea. maybe .app/ could have symlinks or something to ~Documents/Pictures for incscape and gimp for example.

ive been thinkin of trying to recompile world to use gobolinux' FHS, it would make application sandboxin quite abit easier. I guess i would just need to write a script to modify PKGBUILDS and a wrapper to makepkg, and a wrapper around yaourt for aur, a pacman-lookalike script to allways compile from abs, and wrap it all to calling their symlink scripts..

broch · 2009-08-10 17:06:33

jails may be an option. Not chroot as this is not a security measure (never was actually). Still linux jail implementation is far from original BSD.

techprophet · 2009-08-10 20:25:46

broch wrote:

jails may be an option. Not chroot as this is not a security measure (never was actually). Still linux jail implementation is far from original BSD.

Yeah, tried chroot before, then learned to write a program to break out of them.

broch · 2009-08-11 03:15:30

techprophet wrote:

broch wrote:
jails may be an option. Not chroot as this is not a security measure (never was actually). Still linux jail implementation is far from original BSD.
Yeah, tried chroot before, then learned to write a program to break out of them.

yup,
chroot never was designed to be a security tool (though for some reason or other a lot of users and developers assumed that chroot is designed for security). I remember Allan Cox rumbling about this for quite a while. In contrast jails are designed with security in the mind, so you could try this. There is jails implementation, (not chroot jail) called openvz:

http://wiki.openvz.org/Main_Page

I hope that this will be useful

techprophet · 2009-08-11 11:34:46

broch wrote:

techprophet wrote:
broch wrote:
jails may be an option. Not chroot as this is not a security measure (never was actually). Still linux jail implementation is far from original BSD.
Yeah, tried chroot before, then learned to write a program to break out of them.
yup,
chroot never was designed to be a security tool (though for some reason or other a lot of users and developers assumed that chroot is designed for security). I remember Allan Cox rumbling about this for quite a while. In contrast jails are designed with security in the mind, so you could try this. There is jails implementation, (not chroot jail) called openvz:
http://wiki.openvz.org/Main_Page
I hope that this will be useful

Looks interesting. It says it's designed for servers, but you never know...

beroal · 2009-08-11 16:30:46

techprophet wrote:

What if each program had it's own permission set that allowed it to read only its own files and directories ... There are probably a million things wrong with this

There is nothing wrong with this, excluding the fact that Unix is designed in other way. Principle of least privilege. Instead of sandboxing you can think of it from an opposite point of view.

Suppose that C is a child process of P.
Unix: by default C has all rights that P has, P can restrict rights of C.
Principle of least privilege: by default C has no rights, P can give rights to C.

techprophet · 2009-08-11 21:43:21

beroal wrote:

techprophet wrote:
What if each program had it's own permission set that allowed it to read only its own files and directories ... There are probably a million things wrong with this
There is nothing wrong with this, excluding the fact that Unix is designed in other way. Principle of least privilege. Instead of sandboxing you can think of it from an opposite point of view.
Suppose that C is a child process of P.
Unix: by default C has all rights that P has, P can restrict rights of C.
Principle of least privilege: by default C has no rights, P can give rights to C.

I never was much of a writer, and you said it much better than I could.

This is, in essence, what I was trying to say.

cerbie · 2009-08-24 00:33:57

The problem is really trust. To get multiple applications able to work on the same data, you ultimately have to trust them (and their users, and their developers, and their maintainers, and...). Now, keeping mass deletions and such from being committed could be handy (including a fully transactional/logging FS). But, you necessarily either (a) add user prompts, (b) reduce functionality, and/or (c) radically change current and future applications, and their supporting environments.

FI, if you want Inkscape to use that file the GIMP created, you could have to drag it into Inkscape, with this operation being done at the user level, separate from the application, and sandboxed from it. This action explicitly gives Inkscape permission to work on the file (it's important to do it this way so that you can insert new files into already-created ones). However, such an implementation would require a massive overhaul of current applications, and cause legacy application problems. It would be like MS' LUA and UAC, but much worse.

An alternative, though, might be to have user-managed sandboxes, where you would add permissions to files, and possibly even add processes (such that two processes could share one sandbox). The sandbox would be the highest level of data management available to a normal user (clarification: an application is a set of data, including itself and the other binary files it needs to load when it starts). So you might take your Pictures directory, add it to a sandbox, add Inkscape to the sandbox, then add GIMP to the sandbox. Again, it would be handy to, by default, allow creation-but-not-editing of files within ~/ to just work, automatically adding permissions to the sandbox used by the app. Said sandboxes could be serialized and re-used, possibly representing them as directory structures, when opened. This method would need a touch of shell work to be truly useful (that is, scripts to make it work seamlessly and elegantly in CLI and GUI at the same time), and user-level jails (it could be simulated with chroot, for proof-of-concept). It would also need work by DEs for support (lighter WMs could just use compatible apps, not unlike current tray support). Finally, it would necessitate massive user training. On the bright side, it wouldn't be hard for users to learn (though they would compromise the security advantages, if allowed), the workings make for metaphors that do not require hiding the high-level logic from users, tons of applications themselves would need little, if any, changes, it would fit well into corporate desire to limit users' ability to mess with things ("no, you cannot add these two things to the same sandbox"), and DE integration could make the whole setup done with visual containers to use drag&drop with (intuitive and flexible), replacing metaphors like the taskbar.

Ah, pipe dreams...

techprophet · 2009-08-24 00:49:49

cerbie wrote:

The problem is really trust. To get multiple applications able to work on the same data, you ultimately have to trust them (and their users, and their developers, and their maintainers, and...). Now, keeping mass deletions and such from being committed could be handy (including a fully transactional/logging FS). But, you necessarily either (a) add user prompts, (b) reduce functionality, and/or (c) radically change current and future applications, and their supporting environments.
FI, if you want Inkscape to use that file the GIMP created, you could have to drag it into Inkscape, with this operation being done at the user level, separate from the application, and sandboxed from it. This action explicitly gives Inkscape permission to work on the file (it's important to do it this way so that you can insert new files into already-created ones). However, such an implementation would require a massive overhaul of current applications, and cause legacy application problems. It would be like MS' LUA and UAC, but much worse.
An alternative, though, might be to have user-managed sandboxes, where you would add permissions to files, and possibly even add processes (such that two processes could share one sandbox). The sandbox would be the highest level of data management available to a normal user (clarification: an application is a set of data, including itself and the other binary files it needs to load when it starts). So you might take your Pictures directory, add it to a sandbox, add Inkscape to the sandbox, then add GIMP to the sandbox. Again, it would be handy to, by default, allow creation-but-not-editing of files within ~/ to just work, automatically adding permissions to the sandbox used by the app. Said sandboxes could be serialized and re-used, possibly representing them as directory structures, when opened. This method would need a touch of shell work to be truly useful (that is, scripts to make it work seamlessly and elegantly in CLI and GUI at the same time), and user-level jails (it could be simulated with chroot, for proof-of-concept). It would also need work by DEs for support (lighter WMs could just use compatible apps, not unlike current tray support). Finally, it would necessitate massive user training. On the bright side, it wouldn't be hard for users to learn (though they would compromise the security advantages, if allowed), the workings make for metaphors that do not require hiding the high-level logic from users, tons of applications themselves would need little, if any, changes, it would fit well into corporate desire to limit users' ability to mess with things ("no, you cannot add these two things to the same sandbox"), and DE integration could make the whole setup done with visual containers to use drag&drop with (intuitive and flexible), replacing metaphors like the taskbar.
Ah, pipe dreams...

Dragging the files to the app or using an allow <program> <directory or file> command was what I was thinking.

pipe dreams indeed....

beroal · 2009-08-24 10:12:07

cerbie wrote:

FI, if you want Inkscape to use that file the GIMP created, you could have to drag it into Inkscape, with this operation being done at the user level, separate from the application, and sandboxed from it. This action explicitly gives Inkscape permission to work on the file (it's important to do it this way so that you can insert new files into already-created ones). However, such an implementation would require a massive overhaul of current applications, and cause legacy application problems. It would be like MS' LUA and UAC, but much worse.

Actually the problem is solved exactly as you describe here, and the solution is called "file powerbox" (see "A Capability Based Client: The DarpaBrowser" by Marc Stiegler and Mark Miller). A sample implementation is Plash. It reimplements standard C library (libc.so) and Gnome's standard "Open File" dialog window. It imposes some limitations, e.g. "Open File" dialog window cannot be extended with custom controls. I didn't use it so can't tell how intuitive and handy it is. A user selects files in a separate process — file powerbox. They claim that no recompilation of sandboxed applications is required.

Arch Linux

#1 2009-08-08 19:16:19

Brainstorm: Sandboxing...everything!

#2 2009-08-08 20:17:49

Re: Brainstorm: Sandboxing...everything!

#3 2009-08-08 21:02:09

Re: Brainstorm: Sandboxing...everything!

#4 2009-08-08 21:07:35

Re: Brainstorm: Sandboxing...everything!

#5 2009-08-08 21:18:59

Re: Brainstorm: Sandboxing...everything!

#6 2009-08-08 22:09:03

Re: Brainstorm: Sandboxing...everything!

#7 2009-08-09 04:54:39

Re: Brainstorm: Sandboxing...everything!

#8 2009-08-09 12:13:13

Re: Brainstorm: Sandboxing...everything!

#9 2009-08-10 01:11:27

Re: Brainstorm: Sandboxing...everything!

#10 2009-08-10 16:41:33

Re: Brainstorm: Sandboxing...everything!

#11 2009-08-10 17:06:33

Re: Brainstorm: Sandboxing...everything!

#12 2009-08-10 20:25:46

Re: Brainstorm: Sandboxing...everything!

#13 2009-08-11 03:15:30

Re: Brainstorm: Sandboxing...everything!

#14 2009-08-11 11:34:46

Re: Brainstorm: Sandboxing...everything!

#15 2009-08-11 16:30:46

Re: Brainstorm: Sandboxing...everything!

#16 2009-08-11 21:43:21

Re: Brainstorm: Sandboxing...everything!

#17 2009-08-24 00:33:57

Re: Brainstorm: Sandboxing...everything!

#18 2009-08-24 00:49:49

Re: Brainstorm: Sandboxing...everything!

#19 2009-08-24 10:12:07

Re: Brainstorm: Sandboxing...everything!

Board footer