login
Search
Hi,
I am trying to find a way so that regular users could run untested applications safely.I am not really worried about applications reading stuff they should not, but I _am_ worried about them creating a mess where they have no business writing.
Is there a way to restrict the capabilities of a process and its children so that they can only write under a certain directory ?
At the moment I create a new user for each such sandbox, and rely on (what I hope are) proper permissions on the filesystem to restrain the processes, but that approach is not really usable for regular users. chroot is even worse in that respect.LD_PRELOAD wrapper sandbox solutions are not safe enough for me...
Any hints would be appreciated!
Group Permission?
Hi Ho!
How about creating a new group to let all regular users play with those sandboxes?
So, a sandbox is owned by `nobody' in group `sandbox' and all regular users also belongs to group `sandbox'.
Unless you can highlight the specific reasons as to why the approaches that you have enumerated (i.e., filesystem permission bits, chroot, and LD_PRELOAD) are not good, I can say that filesystem permission bits should be enough for your purpose.
Best regards,
Eus (FSF member #4445)
In this digital era, where computing technology is pervasive, your freedom depends on the software controlling those computing devices.
Join free software movement today! It is free as in freedom, not as in free beer!
Join: http://www.fsf.org/jf?referrer=4445
What about /tmp, /var/tmp -
What about /tmp, /var/tmp - they theoretically open some possibilities to mount symlink attacks, etc.
LD_PRELOAD is not acceptable
LD_PRELOAD is not acceptable because it will not work on static binaries.
chroot requires the creation of a full jail - I'd like the sandboxed binaries to access the data and libraries in the main system. An example of such a sandboxed application could be a proprietary instant messenger (Skype comes in mind). chroot also requires root to setup each jail, and it also requires root priviledges to enter. This approach is practically unmaintainable in a production environment...
Creating a new user for each sandbox also requires root intervention. And once again you lose access to the user data...
And the problem with file permission bits is that disaster is just a chmod away at best...
What I am trying to determine is if there is a way for a single user to run untested code without messing up his files. Each user would be able to create multiple sandboxes that do not have write access to the user's files or to each other. And that should be performed without
root priviledges.
I am looking at SELinux, smack and AppArmor ATM. One of them might be helpful...
My short experience
With SELinux and AppArmor is easy to summarize: AppArmor is easier to setup and mantain. Of course it doesn't protect whole system from any kind of attacks, but only "registered" apps.
"AppArmor is *not* intended to protect every aspect of the system from every other aspect of the system: the intended usage is that only a small fraction of all programs on a Linux system will have AppArmor profiles. Rather, AppArmor is intended to protect the system against a particular threat."
s/threat/user :)
experience
No doubt can ordering be implemented in software above the file system.
I think they would be useful in the file system as well.
I recall I read Plan 9 had something like this instead of PATH, but I can't find it now.
You might want to look into
You might want to look into whether UID namespaces in new kernels will do what you want... They're still very experimental and rather poorly documented, grovel around in lkml threads to get the gist :)