Simon McVittie <s...@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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mx79opt2.fsf@frosties.localnet
