[ge-talk] Security services provided by OS

[Adrian Sanabria]

Chroot jails are used in UNIX server environments all the time. It is less
used in user/workstation environments, but there is no reason not to that I
can think of. I can't remember trying it recently, but I think the solution
to get access to MP3s and /dev/audio would be to set links inside the chroot
jail before going into the jail. It should work like this from the
mp3player's point of view (generally):

ln /dev/audio /usr/local/mp3player/dev/audio
ln /home/music /usr/local/mp3player/music
chroot /usr/local/mp3player /bin/bash

Now, the mp3player can access everything inside /home/music, but nothing
outside it, because if it goes above "music", it ends up in
/usr/local/mp3player, which will be "/" (top-level root) inside the jail.

Just an idea though, let me know if I'm completely overlooking something
obvious.

--Adrian

On 1/7/07, Paul van Nugteren <pmvannugteren at eml.cc> wrote:
>
> Are you sure? Seems a pretty obvious idea...
>
> > Protection #2 (prevent application from destroying files) actually has a
> > very simple solution which no OS really uses, which is quite puzzling.
> > Simply restrict the application from only modifying files in its current
> > directory or lower, but never higher.  ie. an application in
> > /boot/apps/Sandbox  can only modify files in the Sandbox directory and
> > lower
> > (and obviously ~/config/settings/Sandbox).  If an application needs to
> do
> > anything outside it's boundaries, pop up an alert asking for permission
> /
> > password.  There is also a third directory which we will allow access
> to,
> > and that is wherever the user open/saved a file to.  This approach
> allows
> > audio players to access my MP3 directory, but never /boot/beos/system).
> > Spawned applications inherit directory restrictions.
>
>
> Still the mp3 player needs to write to '/dev/audio'. I think the system
> should never allow it too read anything else than music files, but what
> about private voice recordings? It could read those and secretly upload.
>
>
>
>
> http://www.fastmail.fm
>
> _______________________________________________
> glasselevator-talk mailing list
> glasselevator-talk at bug-br.org.br
> http://www.bug-br.org.br/mailman/listinfo/glasselevator-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.bug-br.org.br/pipermail/glasselevator-talk/attachments/20070107/ff0d7737/attachment.html