All of lore.kernel.org
 help / color / mirror / Atom feed
From: daw@mozart.cs.berkeley.edu (David Wagner)
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] User chroot
Date: 27 Jun 2001 00:48:14 GMT	[thread overview]
Message-ID: <9hbage$djn$1@abraham.cs.berkeley.edu> (raw)
In-Reply-To: <20010627014534.B2654@ondska> <9hb6rq$49j$1@cesium.transmeta.com>

H. Peter Anvin wrote:
>By author:    Jorgen Cederlof <jc@lysator.liu.se>
>> If we only allow user chroots for processes that have never been
>> chrooted before, and if the suid/sgid bits won't have any effect under
>> the new root, it should be perfectly safe to allow any user to chroot.
>
>Safe, perhaps, but also completely useless: there is no way the user
>can set up a functional environment inside the chroot.

Why is it useless?  It sounds useful to me, on first glance.  If I want
to run a user-level network daemon I don't trust (for instance, fingerd),
isolating it in a chroot area sounds pretty nice: If there is a buffer
overrun in the daemon, you can get some protection [*] against the rest
of your system being trashed.  Am I missing something obvious?

[*] Yes, I know chroot is not sufficient on its own to completely
    protect against this, but it is a useful part of the puzzle, and
    there are other things we can do to deal with the remaining holes.

  reply	other threads:[~2001-06-27  0:51 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-26 23:45 [PATCH] User chroot Jorgen Cederlof
2001-06-26 23:46 ` H. Peter Anvin
2001-06-27  0:48   ` David Wagner [this message]
2001-06-27 12:56     ` Marco Colombo
2001-06-27 13:56     ` Admin Mailing Lists
2001-06-27  3:32   ` Albert D. Cahalan
2001-06-27  4:24     ` H. Peter Anvin
2001-06-27  6:31       ` Kai Henningsen
2001-06-27 20:55       ` Albert D. Cahalan
2001-06-27 21:03         ` H. Peter Anvin
2001-06-27 21:19           ` Albert D. Cahalan
2001-06-28  7:47         ` Sean Hunter
2001-06-28 18:25           ` Albert D. Cahalan
2001-06-27 15:39   ` Marcus Sundberg
2001-06-27 17:55   ` Jorgen Cederlof
2001-06-27  6:37 ` Kai Henningsen
2001-06-27 18:14   ` H. Peter Anvin
2001-06-28  6:54     ` Kai Henningsen
2001-06-29 13:46     ` Jorgen Cederlof
     [not found] <0C01A29FBAE24448A792F5C68F5EA47D1205FB@nasdaq.ms.ensim.com>
2001-06-27  0:37 ` Paul Menage
2001-06-27  0:45   ` H. Peter Anvin
2001-06-27  0:53     ` David Wagner
2001-06-27  0:51   ` David Wagner
2001-06-27  1:08   ` Mohammad A. Haque
2001-06-27  1:24     ` Paul Menage
2001-06-27  1:40       ` Alexander Viro
2001-06-27  2:17         ` Paul Menage
2001-06-27  6:35           ` Kai Henningsen
2001-06-27  7:19         ` Chris Wedgwood
2001-06-27  7:43           ` Alexander Viro
2001-06-27  4:39     ` David Wagner
  -- strict thread matches above, loose matches on Subject: below --
2001-06-27 13:57 Jesse Pollard
2001-06-27 17:42 ` David Wagner
2001-06-27 23:11 Andries.Brouwer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='9hbage$djn$1@abraham.cs.berkeley.edu' \
    --to=daw@mozart.cs.berkeley.edu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.