[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#575838: marked as done (chroots as a security risk; mitigation via permissions)

Your message dated Wed, 19 Oct 2016 21:08:19 +0200
with message-id <87pomwf97g.fsf@deep-thought.43-1.org>
and subject line Re: Bug#575838: chroots as a security risk; mitigation via permissions
has caused the Debian Bug report #575838,
regarding chroots as a security risk; mitigation via permissions
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
575838: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575838
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: debootstrap
Tags: security
Severity: normal

I've noticed that it's not uncommon for one to use debootstrap to create
a chroot, and leave the chroot lying around, and not realize that one
has introduced several setuid/setgid binaries into the system, that are
not getting regular security updates.

At least these, and often more when more packages are installed in the chroot:

205699   72 -rwsr-xr-x   1 root     root        66152 Apr 29  2008 ./bin/mount
206693   36 -rwsr-xr-x   1 root     root        32792 Dec 10  2007 ./bin/ping
206184   36 -rwsr-xr-x   1 root     root        33112 Dec  6 06:35 ./bin/su
206692   28 -rwsr-xr-x   1 root     root        28560 Dec 10  2007 ./bin/ping6
205700   48 -rwsr-xr-x   1 root     root        46040 Apr 29  2008 ./bin/umount
206359   12 -rwsr-xr-x   1 root     root        10512 Oct 18 19:24 ./usr/lib/pt_chown
206263   40 -rwsr-xr-x   1 root     root        39104 Dec  6 06:35 ./usr/bin/passwd
206260   36 -rwsr-xr-x   1 root     root        33376 Dec  6 06:35 ./usr/bin/chsh
206259   36 -rwsr-xr-x   1 root     root        36416 Dec  6 06:35 ./usr/bin/chfn
206262   56 -rwsr-xr-x   1 root     root        49536 Dec  6 06:35 ./usr/bin/gpasswd
206182   28 -rwsr-xr-x   1 root     root        28600 Dec  6 06:35 ./usr/bin/newgrp
205145   32 -rwxr-sr-x   1 root     shadow      29944 Mar 24  2009 ./sbin/unix_chkpwd
205681   12 -rwxr-sr-x   1 root     tty         11728 Apr 29  2008 ./usr/bin/wall
206261   24 -rwxr-sr-x   1 root     shadow      24376 Dec  6 06:35 ./usr/bin/expiry
206258   60 -rwxr-sr-x   1 root     shadow      55168 Dec  6 06:35 ./usr/bin/chage
206441   32 -rwxr-sr-x   1 root     crontab     32048 Sep 28  2008 ./usr/bin/crontab
205931   12 -rwxr-sr-x   1 root     tty         10928 Nov 20  2007 ./usr/bin/bsd-write

As a secondary problem, not all users in the chroot are the same as those
outside, so it's possible some of these run setuid to the wrong user
if run from outside the chroot. For example, in a more populated chroot, I see:

247252  104 -rwxr-sr-x   1 root     mlocate     99240 Jan 14  2009 ./usr/bin/ssh-agent

So, I wonder if it's worth having debootstrap mitigate this exposure?
It could just make the top of the chroot mode 700. d-i would then have
to be changed to fix the permissions of /target after debootstrap runs.
It's possible that this would break assumptions made by eg, pbuilder, about
user visibility into a chroot, I don't know.

-- 
see shy jo

Attachment: signature.asc
Description: Digital signature


--- End Message ---
--- Begin Message --- 
tag 575838 + wontfix
thanks

Joey Hess writes:
> I've noticed that it's not uncommon for one to use debootstrap to create
> a chroot, and leave the chroot lying around, and not realize that one
> has introduced several setuid/setgid binaries into the system, that are
> not getting regular security updates.
[...]
> So, I wonder if it's worth having debootstrap mitigate this exposure?
> It could just make the top of the chroot mode 700. d-i would then have
> to be changed to fix the permissions of /target after debootstrap runs.
> It's possible that this would break assumptions made by eg, pbuilder, about
> user visibility into a chroot, I don't know.

I understand the problem, but don't think that debootstrap is the right
place to address this.  I would expect quite a bit of software to get
confused if / is not accessible.

In my opinion the right way to have binaries in chroots not accessible
from the outside is to have an intermediate directory that is only
accessible by root, for example:

  root:root drwx------ /srv/chroot
  root:root drwxr-xr-x /srv/chroot/unstable
  root:root drwxr-xr-x /srv/chroot/unstable/{bin,dev,...}

However setting up such a hierarchy is outside of the scope of
debootstrap itself.

Ansgar

--- End Message ---
Reply to: