FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 03-20-2012, 07:11 PM
Ivan Krylov
 
Default Bug#664784: ITP: sandbox -- A helper utility to run programs in a sandboxed environment

Package: wnpp
Severity: wishlist
Owner: Ivan Krylov <krylov.r00t@gmail.com>

* Package name : sandbox
Version : 2.5
Upstream Author : Gentoo Foundation <vapier@gentoo.org>
* URL : http://gentoo.org/
* License : GPL-2.0+
Programming Lang: C
Description : A helper utility to run programs in a sandboxed environment

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.
.
For example, in the Gentoo world it is used for building applications as root
and being sure that the build system does not do crazy things outside of its
build directory. Such as install files to the live root file system or modify
config files on the fly.
.
For people who are familiar with the Debian "fakeroot" project or the RPM based
"InstallWatch", sandbox is in the same vein of projects.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120320201143.12461.16661.reportbug@infinitea">ht tp://lists.debian.org/20120320201143.12461.16661.reportbug@infinitea
 
Old 03-21-2012, 10:35 AM
Simon McVittie
 
Default Bug#664784: ITP: sandbox -- A helper utility to run programs in a sandboxed environment

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F69BD0A.1020206@debian.org">http://lists.debian.org/4F69BD0A.1020206@debian.org
 
Old 03-21-2012, 03:56 PM
Goswin von Brederlow
 
Default Bug#664784: ITP: sandbox -- A helper utility to run programs in a sandboxed environment

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87mx79opt2.fsf@frosties.localnet">http://lists.debian.org/87mx79opt2.fsf@frosties.localnet
 

Thread Tools




All times are GMT. The time now is 08:08 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org