Re: Bug#664784: ITP: sandbox -- A helper utility to run programs in a sandboxed environment

[Goswin von Brederlow <goswin-v-b@web.de>]

Simon McVittie <smcv@debian.org> writes:

> On 20/03/12 20:11, Ivan Krylov wrote:
>>  Sandbox is a library (and helper utility) to run programs in a "sandboxed"
>>  environment.  This is used as a QA measure to try and prevent applications from
>>  modifying files they should not.
>
> Is sandbox secure (in the sense that an actively malicious program run
> inside a sandbox, whose author is fully aware of how sandbox works, is
> prevented from breaking out), or does it only protect against common
> mistakes and not against deliberate abuse?
>
> If sandbox is not suitable for sandboxing deliberately malicious
> programs, I think it's important for its package description to say so.
>
> (For instance, chroot(2) is not secure against malicious programs with
> CAP_SYS_CHROOT. If I understand it correctly, schroot, as commonly used
> in Debian infrastructure, is secure if its user cannot get root
> privileges and all setuid-root binaries inside the chroot are secure.)
>
>>  For people who are familiar with the Debian "fakeroot" project or the RPM based
>>  "InstallWatch", sandbox is in the same vein of projects.
>
> Is it really, though? fakeroot is just an LD_PRELOAD hack which pretends
> to have root privileges: it doesn't allow the program to do anything
> that it couldn't already do (its real privileges are those of the user
> running it). As a result, fakeroot "fails safe" if a privileged action
> isn't supported by fakeroot - it just won't work. In contrast, a
> mechanism that gives real root privileges will "fail open", and allow
> all privileged actions that it doesn't specifically deny.
>
>     S

Is it any better than bind mounting / read-only recursively somewhere,
(s)chrooting there and running the code without CAP_SYS_CHROOT (e.g. as
user)?

Or using unionfs to allow writes but store them in a different directory
tree.

MfG
        Goswin