base-files: Insecure PATH in /root/.profile

Automatically imported from Debian bug report #299007 http://bugs.debian.org/299007

Message-Id: <email address hidden>
Date: Fri, 11 Mar 2005 13:44:21 +1100
From: Paul Szabo <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: base-files: Insecure PATH in /root/.profile

Package: base-files
Version: 3.0.2
Severity: critical
Tags: patch security
Justification: root security hole

I recently noticed that /usr/local and /usr/local/{bin,sbin} are
group-writable and owned by root:staff. This is wrong: those directories
are in the default PATH for root. They (and files within) should be
root-owned: group staff users or become-any-user-but-root bugs should not
be able to trojan and thus get root.

The Debian Policy Manual [1] says:

  ... /usr/local take precedence over the equivalents in /usr.
  ... should have permissions 2775 and be owned by root.staff.

but it [2] also says:

  ... make sure that [it] is secure ...
  Files should be owned by root.root ... mode 644 or 755.
  Directories should be mode 755 or 2775 ... owned by the group that needs
  write access to it.

The Debian Reference [3] and Securing Debian Manual [4], [5] say

  [group] staff is ... for helpdesk types or junior sysadmins ... to do
  things in /usr/local and to create directories in /home.

  [group] staff: Allows users to add local modifications to the system
  (/usr/local, /home) without needing root privileges.

  The 'staff' group are usually help-desk/junior sysadmins, allowing them
  to work in /usr/local and create directories in /home.

(This is surely wrong, seems a SysV left-over: you need root privileges to
chown user directories in /home or in fact to create users in /etc/passwd.)

"Junior sysadmins" should not be able or encouraged to trojan root, even if
you trust them with the root password or give them sudo privileges.

Become-any-user-but-root and become-any-group-but-root bugs are quite
common. When a group of machines share user home directories via NFS
exported from somewhere with default root-squash, getting root on one
machine gives precisely that on all others of the group. There have been
"genuine" such bugs also e.g. in sendmail [6].

This security lapse has been discussed before [7], [8].

The solution is to remove /usr/local things from the default PATH in
/root/.profile (i.e. in /usr/share/base-files/dot.profile), leaving a
warning comment instead.

It would also be good to re-word the confused policy, and to make
/usr/local root-owned. (Maybe /usr/local/sbin could then be used again.)
Discuss on <email address hidden>, or "reportbug debian-policy"?

References:

[1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2
[2] http://www.debian.org/doc/debian-policy/ch-files.html#s10.9
[3] http://www.debian.org/doc/manuals/reference/ch-tune.en.html#s9.2.3
[4] http://www.debian.org/doc/manuals/securing-debian-howto/ch11.en.html#s11.1.12.1
[5] http://www.debian.org/doc/manuals/securing-debian-howto/ch11.en.html#s11.1.12.2
[6] http://hackersplayground.org/papers/sendmailholes.txt
[7] http://lists.debian.org/debian-doc/2001/08/msg00041.html
[8] http://lists.debian.org/debian-user/2003/12/msg02057.html

Cheers,

Paul Szabo <email address hidden> http...

I think you and I discussed this before, and we agreed that we should eliminate
this use of group staff, as it makes staff root-equivalent. Let's kill it for
Hoary.

(In reply to comment #2)
> I think you and I discussed this before, and we agreed that we should eliminate
> this use of group staff, as it makes staff root-equivalent. Let's kill it for
> Hoary.

Indeed.

 base-files (3.1.0ubuntu2) hoary; urgency=low
 .
   * debian/postinst: Do not install /usr/local and subdirectories with "staff"
     group writeability. This group is essentially root-equivalent, but there
     are cases where somebody can become any user but root (like NFS).
   * debian/rules: Do not install /home as root:staff, it makes no sense.
   * debian/2775-dirs: Remove "home".
   * Ubuntu bug #13795

This fixes new installations, but I don't think that we should touch existing
installations. Administrators may change permissions on purpose (or even use the
staff group for this purpose), so I doubt that we should mess with this. Matt,
if you disagree, please reopen this bug.

Message-ID: <email address hidden>
Date: Fri, 11 Mar 2005 11:42:52 +0100 (CET)
From: Santiago Vila <email address hidden>
To: Paul Szabo <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH in /root/.profile

severity 299007 wishlist
reassign 299007 debian-policy
thanks

On Fri, 11 Mar 2005, Paul Szabo wrote:

> Package: base-files
> Version: 3.0.2
> Severity: critical
> Tags: patch security
> Justification: root security hole
>
> I recently noticed that /usr/local and /usr/local/{bin,sbin} are
> group-writable and owned by root:staff. This is wrong: those directories
> are in the default PATH for root. They (and files within) should be
> root-owned: group staff users or become-any-user-but-root bugs should not
> be able to trojan and thus get root.
> [...]

This is not a bug. base-files follows policy. If you don't like
current policy, amend it. For your benefit, I'm doing a reassign.
Now you have to make a policy proposal. This is explained in the
debian-policy package.

Message-ID: <email address hidden>
Date: Fri, 11 Mar 2005 13:39:28 +0100 (CET)
From: Santiago Vila <email address hidden>
To: <email address hidden>
Cc: Paul Szabo <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

In this report, the submitter complains about /usr/local/bin being in
the PATH by default at the same time directories under /usr/local are
root:staff and world-writable. His complain is based on the existence
of become-any-group-but-root bugs.

If this is a bug at all, I think we should probably drop the root:staff
thing instead of changing the default PATH. So: Would anyone here
second the following patch, if it were a policy proposal?

diff -ru debian-policy-3.6.1.1.orig/policy.sgml debian-policy-3.6.1.1/policy.sgml
--- debian-policy-3.6.1.1.orig/policy.sgml 2004-06-25 23:11:36.000000000 +0200
+++ debian-policy-3.6.1.1/policy.sgml 2005-03-11 13:25:27.000000000 +0100
@@ -5062,8 +5062,8 @@
 then
   if mkdir /usr/local/share/emacs 2>/dev/null
   then
- chown root:staff /usr/local/share/emacs
- chmod 2775 /usr/local/share/emacs
+ chown root:root /usr/local/share/emacs
+ chmod 755 /usr/local/share/emacs
   fi
 fi
      </example>
@@ -5095,8 +5095,8 @@
    <p>
      The <file>/usr/local</file> directory itself and all the
      subdirectories created by the package should (by default) have
- permissions 2775 (group-writable and set-group-id) and be
- owned by <tt>root.staff</tt>.
+ permissions 755 and be
+ owned by <tt>root:root</tt>.
    </p>
  </sect1>

Message-ID: <20050311141732.GT6499@seventeen>
Date: Fri, 11 Mar 2005 15:17:32 +0100
From: Bill Allombert <email address hidden>
To: <email address hidden>
Cc: Paul Szabo <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote:
> In this report, the submitter complains about /usr/local/bin being in
> the PATH by default at the same time directories under /usr/local are
> root:staff and world-writable. His complain is based on the existence
> of become-any-group-but-root bugs.

Is there evidence of such bugs ? There is no binaries sgid staff in
Debian to start with.

> If this is a bug at all, I think we should probably drop the root:staff
> thing instead of changing the default PATH. So: Would anyone here
> second the following patch, if it were a policy proposal?

dpkg never change permissions of directories by itself, so users can
easily chown them to theirs liking. The policy snippet below has this
property (mkdir will fail if the directory already exist).

> diff -ru debian-policy-3.6.1.1.orig/policy.sgml debian-policy-3.6.1.1/policy.sgml
> --- debian-policy-3.6.1.1.orig/policy.sgml 2004-06-25 23:11:36.000000000 +0200
> +++ debian-policy-3.6.1.1/policy.sgml 2005-03-11 13:25:27.000000000 +0100
> @@ -5062,8 +5062,8 @@
> then
> if mkdir /usr/local/share/emacs 2>/dev/null
> then
> - chown root:staff /usr/local/share/emacs
> - chmod 2775 /usr/local/share/emacs
> + chown root:root /usr/local/share/emacs
> + chmod 755 /usr/local/share/emacs
> fi
> fi
> </example>

However, I disagree with the attitude of reassigning bug to
debian-policy. If submitters want to make a policy proposal,
they can propose it themselves. Maintainers creating policy
proposal they clearly object to without anyone claiming
support is a waste of time here. The purpose of this list
is not to serve as a shield maintainers can use to deflect
submitters.

Cheers,
--
Bill. <email address hidden>

Imagine a large red swirl here.

Message-ID: <email address hidden>
Date: Fri, 11 Mar 2005 15:26:16 +0100
From: Martin Pitt <email address hidden>
To: Santiago Vila <email address hidden>
Cc: <email address hidden>, Paul Szabo <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

--EVF5PPMfhYS0aIcm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

Santiago Vila [2005-03-11 13:39 +0100]:
> In this report, the submitter complains about /usr/local/bin being in
> the PATH by default at the same time directories under /usr/local are
> root:staff and world-writable. His complain is based on the existence
> of become-any-group-but-root bugs.
>=20
> If this is a bug at all, I think we should probably drop the root:staff
> thing instead of changing the default PATH. So: Would anyone here
> second the following patch, if it were a policy proposal?
>=20
> diff -ru debian-policy-3.6.1.1.orig/policy.sgml debian-policy-3.6.1.1/pol=
icy.sgml
> --- debian-policy-3.6.1.1.orig/policy.sgml 2004-06-25 23:11:36.000000000 =
+0200
> +++ debian-policy-3.6.1.1/policy.sgml 2005-03-11 13:25:27.000000000 +0100
> @@ -5062,8 +5062,8 @@
> then
> if mkdir /usr/local/share/emacs 2>/dev/null
> then
> - chown root:staff /usr/local/share/emacs
> - chmod 2775 /usr/local/share/emacs
> + chown root:root /usr/local/share/emacs
> + chmod 755 /usr/local/share/emacs
> fi
> fi
> </example>
> @@ -5095,8 +5095,8 @@
> <p>
> The <file>/usr/local</file> directory itself and all the
> subdirectories created by the package should (by default) have
> - permissions 2775 (group-writable and set-group-id) and be
> - owned by <tt>root.staff</tt>.
> + permissions 755 and be
> + owned by <tt>root:root</tt>.
> </p>
> </sect1>

I wholeheartedly agree and second this proposal. Also, /home should be
root:root 0755 instead of root:staff 2775; it is only confusing and
actually does not do anything useful.

Martin

--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntulinux.org
Debian GNU/Linux Developer http://www.debian.org

--EVF5PPMfhYS0aIcm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCMaqHDecnbV4Fd/IRAqhFAJ0Q78BxlSVW/2ObLManMAVxxeK37ACdEzlb
PjLMdvz0Z4l0IPCGhcZrD00=
=5kCq
-----END PGP SIGNATURE-----

--EVF5PPMfhYS0aIcm--

Message-ID: <email address hidden>
Date: Fri, 11 Mar 2005 16:23:27 +0100
From: <email address hidden> (Marco d'Itri)
Cc: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mar 11, Martin Pitt <email address hidden> wrote:

> I wholeheartedly agree and second this proposal. Also, /home should be
> root:root 0755 instead of root:staff 2775; it is only confusing and
> actually does not do anything useful.
Agreed.

--=20
ciao,
Marco

--7JfCtLOvnd9MIVvH
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCMbfuFGfw2OHuP7ERAu/qAJ9rNka7yqpVgCN17BDuGM6LXPDRTQCfRbN9
QJseS/ojl5iN1Bbag0rfd8c=
=zsZL
-----END PGP SIGNATURE-----

--7JfCtLOvnd9MIVvH--

Message-ID: <20050311172257.GA4728@seventeen>
Date: Fri, 11 Mar 2005 18:22:57 +0100
From: Bill Allombert <email address hidden>
To: <email address hidden>
Cc: Paul Szabo <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

On Fri, Mar 11, 2005 at 03:26:16PM +0100, Martin Pitt wrote:
> Hi!
>
> I wholeheartedly agree and second this proposal. Also, /home should be
> root:root 0755 instead of root:staff 2775; it is only confusing and
> actually does not do anything useful.

Obviously it does: it allows an administrator in the staff group to
install software in /usr/local without having to use root priviledge,
so prevent mistakes that would affect the /usr hierarchy. I don't see
what is confusing here?

This is even documented, see
/usr/share/doc/base-passwd/users-and-groups.txt.gz:

staff

    Allows users to add local modifications to the system (/usr/local, /home)
    without needing root privileges. Compare with group 'adm', which is more
    related to monitoring/security.

Cheers,
--
Bill. <email address hidden>

Imagine a large red swirl here.

Message-ID: <email address hidden>
Date: Fri, 11 Mar 2005 18:27:24 +0100 (CET)
From: Santiago Vila <email address hidden>
To: <email address hidden>
Cc: Paul Szabo <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

On Fri, 11 Mar 2005, Bill Allombert wrote:

> On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote:
> > In this report, the submitter complains about /usr/local/bin being in
> > the PATH by default at the same time directories under /usr/local are
> > root:staff and world-writable. His complain is based on the existence
> > of become-any-group-but-root bugs.
>
> Is there evidence of such bugs ? There is no binaries sgid staff in
> Debian to start with.

You don't need sgid staff binaries. Quoting the submitter:

 Become-any-user-but-root and become-any-group-but-root bugs are quite
 common. When a group of machines share user home directories via NFS
 exported from somewhere with default root-squash, getting root on one
 machine gives precisely that on all others of the group. There have been
 "genuine" such bugs also e.g. in sendmail [6].

The issue here is that "group staff" is equivalent to "user root", and
that we should better eliminate such equivalence from the default system.

> However, I disagree with the attitude of reassigning bug to
> debian-policy. If submitters want to make a policy proposal,
> they can propose it themselves.

Well, you have to be an official developer for that, so that's not
always possible.

In this case, you may consider this as a proposal made by me if you like.

This is not a bug in base-files because policy explicitly *mandates*
the root:staff thing, but as I see fewer and fewer people who find
the root:staff thing useful and more and more people who consider it
a potentially dangerous thing, I think that we would better drop the
staff thing from policy entirely, hence my reassign.

Message-ID: <email address hidden>
Date: Fri, 11 Mar 2005 10:17:14 -0800
From: Matt Zimmerman <email address hidden>
To: <email address hidden>
Subject: Agreed

I fully support removing this privilege of group staff; it simply makes
group staff root-equivalent.

--
 - mdz

Message-ID: <20050311191555.GC4728@seventeen>
Date: Fri, 11 Mar 2005 20:15:55 +0100
From: Bill Allombert <email address hidden>
To: <email address hidden>
Cc: Paul Szabo <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

On Fri, Mar 11, 2005 at 06:27:24PM +0100, Santiago Vila wrote:
> On Fri, 11 Mar 2005, Bill Allombert wrote:
>
> > On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote:
> > > In this report, the submitter complains about /usr/local/bin being in
> > > the PATH by default at the same time directories under /usr/local are
> > > root:staff and world-writable. His complain is based on the existence
> > > of become-any-group-but-root bugs.
> >
> > Is there evidence of such bugs ? There is no binaries sgid staff in
> > Debian to start with.
>
> You don't need sgid staff binaries. Quoting the submitter:
>
> Become-any-user-but-root and become-any-group-but-root bugs are quite
> common. When a group of machines share user home directories via NFS
> exported from somewhere with default root-squash, getting root on one
> machine gives precisely that on all others of the group. There have been
> "genuine" such bugs also e.g. in sendmail [6].

man exports, see squash_gids. I would say there are some many holes with
NFS that I am not sure it make any difference. The same apply to
sendmail.

> The issue here is that "group staff" is equivalent to "user root", and
> that we should better eliminate such equivalence from the default system.

No, it is not equivalent in the sense that if you are runing sgid staff
and you do rm -r /usr/lib instead of rm -r /usr/local/lib by mistake,
you do not hose your system. The first goal of the unix permissions is
to protect against errors rather than malices.

> > However, I disagree with the attitude of reassigning bug to
> > debian-policy. If submitters want to make a policy proposal,
> > they can propose it themselves.
>
> Well, you have to be an official developer for that, so that's not
> always possible.
>
> In this case, you may consider this as a proposal made by me if you like.

Oh, sorry then. I did not understand you backed the proposal. In that
case, it was completly normal to reassign the bug here, of course.

Cheers,
--
Bill. <email address hidden>

Imagine a large red swirl here.

Message-ID: <email address hidden>
Date: Fri, 11 Mar 2005 13:45:04 -0800
From: Steve Langasek <email address hidden>
To: Santiago Vila <email address hidden>, <email address hidden>
Cc: Paul Szabo <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

--H+4ONPRPur6+Ovig
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote:
> In this report, the submitter complains about /usr/local/bin being in
> the PATH by default at the same time directories under /usr/local are
> root:staff and world-writable. His complain is based on the existence
> of become-any-group-but-root bugs.

> If this is a bug at all, I think we should probably drop the root:staff
> thing instead of changing the default PATH. So: Would anyone here
> second the following patch, if it were a policy proposal?

Seconded in principle; I don't know if /usr/local/share/emacs is a good
example of a directory that needs to not be sgid staff, but certainly I
think that /usr/local/bin, /usr/local/sbin, and /usr/local/lib must not be.

--=20
Steve Langasek
postmodern programmer

> diff -ru debian-policy-3.6.1.1.orig/policy.sgml debian-policy-3.6.1.1/pol=
icy.sgml
> --- debian-policy-3.6.1.1.orig/policy.sgml 2004-06-25 23:11:36.000000000 =
+0200
> +++ debian-policy-3.6.1.1/policy.sgml 2005-03-11 13:25:27.000000000 +0100
> @@ -5062,8 +5062,8 @@
> then
> if mkdir /usr/local/share/emacs 2>/dev/null
> then
> - chown root:staff /usr/local/share/emacs
> - chmod 2775 /usr/local/share/emacs
> + chown root:root /usr/local/share/emacs
> + chmod 755 /usr/local/share/emacs
> fi
> fi
> </example>
> @@ -5095,8 +5095,8 @@
> <p>
> The <file>/usr/local</file> directory itself and all the
> subdirectories created by the package should (by default) have
> - permissions 2775 (group-writable and set-group-id) and be
> - owned by <tt>root.staff</tt>.
> + permissions 755 and be
> + owned by <tt>root:root</tt>.
> </p>
> </sect1>

--H+4ONPRPur6+Ovig
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCMhFgKN6ufymYLloRAh5AAKCwejprDR9G+Bvpb68SCOCJ1GxtoACgxAXF
RgpCHDpH9Q4FWHZA7MRDZ8k=
=WhHx
-----END PGP SIGNATURE-----

--H+4ONPRPur6+Ovig--

Message-ID: <email address hidden>
Date: Mon, 14 Mar 2005 14:36:01 +0000
From: Colin Watson <email address hidden>
To: Bill Allombert <email address hidden>, <email address hidden>
Cc: Paul Szabo <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

On Fri, Mar 11, 2005 at 06:22:57PM +0100, Bill Allombert wrote:
> On Fri, Mar 11, 2005 at 03:26:16PM +0100, Martin Pitt wrote:
> > I wholeheartedly agree and second this proposal. Also, /home should be
> > root:root 0755 instead of root:staff 2775; it is only confusing and
> > actually does not do anything useful.
>
> Obviously it does: it allows an administrator in the staff group to
> install software in /usr/local without having to use root priviledge,
> so prevent mistakes that would affect the /usr hierarchy. I don't see
> what is confusing here?

In Martin's second sentence, he's talking about /home, where it's not
especially useful for users other than root to have write access since
they can't chown the home directories to the new user anyway.

> This is even documented, see
> /usr/share/doc/base-passwd/users-and-groups.txt.gz:
>
> staff
>
> Allows users to add local modifications to the system (/usr/local, /home)
> without needing root privileges. Compare with group 'adm', which is more
> related to monitoring/security.

base-passwd documents the situation at the moment and the rationale as
retroactively understood at the time when the documentation was written
(that understanding may have been imperfect); I'd obviously be happy to
update it to take account of changes.

Cheers,

--
Colin Watson [<email address hidden>]

Message-ID: <email address hidden>
Date: Wed, 16 Mar 2005 23:50:17 +1100
From: Brendan O'Dea <email address hidden>
To: Santiago Vila <email address hidden>, <email address hidden>
Cc: Paul Szabo <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote:
>In this report, the submitter complains about /usr/local/bin being in
>the PATH by default at the same time directories under /usr/local are
>root:staff and world-writable. His complain is based on the existence
>of become-any-group-but-root bugs.

Not world-writable. Writable by group staff.

>If this is a bug at all, I think we should probably drop the root:staff
>thing instead of changing the default PATH. So: Would anyone here
>second the following patch, if it were a policy proposal?

Having /usr/local staff writable is *very* useful when using CPAN to
install local packages w/- having to do the "make install" as root.

This is a benefit I'd prefer not to see removed, since the alternative
generally involves giving sudo access to a subset of users... which is
in my experience tantamount to simply adding more entry points to
gaining uid=0*, worse IMHO than having a subset of the filesystem
writable to that same set of users.

I would see setting root's PATH set to /bin:/sbin:/usr/bin:/usr/sbin as
a much better option than removing staff writability of /usr/local.

Although it's probably worth considering that there's more at stake here
than just PATH, since perl for example has /usr/local/{lib,share}/perl
earlier in @INC than /usr/{lib,share}/perl... Giving an attacker who
has breached a group staff acount another avenue: creating say
/usr/local/share/perl/5.8.4/strict.pm containing malevolent code if
$> == 0 would likely be tripped sooner or later.

I'm not sure what the emacs site-lisp search order is, but that may well
provide a similar vector.

In summary:

 1. The Debian installer does not (AFAIK) add any user to group "staff"
    by default, so this is not an issue for every installed Debian
    system.

 2. We need to assume some competence on behalf of the administrator as
    to who gets added to group "staff", just as we would with respect to
    addition to /etc/sudoers or who was given the root password.

 3. To mitigate the effects of compromises of group "staff" users, the
    default root PATH should not include /usr/local; the administrator
    may choose to type the full path if required (just as they must for
    the case of ".").

 4. Perl (and other packages which preferentially load executable code
    from /usr/local) may need to be modified to invert the module search
    path order for uid=0.

--bod

* sudo is fine for specific tasks, like "sudo mount /media/cdrom", but
  woeful for things like "sudo make install". Worse, I've seen "sudo
  bash" more times than I care to recount.

Message-ID: <email address hidden>
Date: Wed, 16 Mar 2005 18:00:14 +0100 (CET)
From: Santiago Vila <email address hidden>
To: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

On Wed, 16 Mar 2005, Brendan O'Dea wrote:

> On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote:
> >In this report, the submitter complains about /usr/local/bin being in
> >the PATH by default at the same time directories under /usr/local are
> >root:staff and world-writable. His complain is based on the existence
> >of become-any-group-but-root bugs.
>
> Not world-writable. Writable by group staff.
>
> >If this is a bug at all, I think we should probably drop the root:staff
> >thing instead of changing the default PATH. So: Would anyone here
> >second the following patch, if it were a policy proposal?
>
> Having /usr/local staff writable is *very* useful when using CPAN to
> install local packages w/- having to do the "make install" as root.
>
> This is a benefit I'd prefer not to see removed, since the alternative
> generally involves giving sudo access to a subset of users... which is
> in my experience tantamount to simply adding more entry points to
> gaining uid=0*, worse IMHO than having a subset of the filesystem
> writable to that same set of users.

That's not really the alternative. The alternative is doing it yourself
(i.e. chgrp -R staff /usr/local and so on) instead of it being the default.

This proposal is not to prevent people from having /usr/local group-writable
by staff, it's just a proposal to have "neutral permissions" in /usr/local.

If you are a perl hacker and like /usr/local to be group writable, you
will always be able to change the permissions yourself. The same is
true, of course, about putting /usr/local/bin in the PATH. The difference
is that you don't need to be a perl hacker to consider /usr/local/bin
in the PATH a useful thing (not to mention we already have a lot of perl
modules available via "apt-get install"). I bet that most people would add
/usr/local/bin to the PATH if it weren't the default, for private
shell scripts, perl scripts, python scripts, or whatever.

Should we count your mail as a formal objection? You know, it only
takes a negative vote to reject a policy proposal, even if it's
supported by a lot of people. I think this is going to be a real pity.

Message-Id: <email address hidden>
Date: Thu, 17 Mar 2005 05:43:19 +1100
From: <email address hidden>
To: <email address hidden>, <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

"Brendan O'Dea" <email address hidden> wrote:

> ... there's more at stake here than just PATH, since perl for example has
> /usr/local/{lib,share}/perl earlier in @INC than /usr/{lib,share}/perl...
>
> I'm not sure what the emacs site-lisp search order is, but that may well
> provide a similar vector.

Thanks for pointing out those avenues of attack.

In your summary you seem to have missed that any machines that share user
files via writable NFS mounts are vulnerable. (Are vulnerable if you mount
an NFS filesystem that is writable to others.)

To keep the current group staff access and have a reasonably useful machine
(with users in group staff to make use of that access, or NFS mounts even
when there are no users in group staff), you would need to modify PATH in
base-files, @INC in perl, something in emacs, and possibly other things in
other packages. You would need to modify policy:
http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2
says
  ... /usr/local take precedence over the equivalents in /usr.

Could the settings
  Severity: critical
  Justification: root security hole
please be re-instated on this bug? In some common scenarios, current
arrangements allow root access. (The worst kind of "bug": mandated by
policy...)

Cheers,

Paul Szabo <email address hidden> http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia

re-resolving as NOTWARTY to avoid further mail

Message-ID: <20050316191925.GA22698@seventeen>
Date: Wed, 16 Mar 2005 20:19:25 +0100
From: Bill Allombert <email address hidden>
To: <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

On Thu, Mar 17, 2005 at 05:43:19AM +1100, <email address hidden> wrote:
> "Brendan O'Dea" <email address hidden> wrote:
>
> > ... there's more at stake here than just PATH, since perl for example has
> > /usr/local/{lib,share}/perl earlier in @INC than /usr/{lib,share}/perl...
> >
> > I'm not sure what the emacs site-lisp search order is, but that may well
> > provide a similar vector.
>
> Thanks for pointing out those avenues of attack.
>
> In your summary you seem to have missed that any machines that share user
> files via writable NFS mounts are vulnerable. (Are vulnerable if you mount
> an NFS filesystem that is writable to others.)

No that is not true. You need to use root_squash for any semblance of
security anyway. In that case you can also use squash_gids to prevent
the attack.

It is a security flaw with NFS rather than with Debian. I can design a
system so that random users can override any files not in group bin.
Will that make it a Debian bug?

Cheers,
--
Bill. <email address hidden>

Imagine a large red swirl here.

Message-Id: <email address hidden>
Date: Thu, 17 Mar 2005 07:25:56 +1100
From: <email address hidden>
To: <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

Bill Allombert <email address hidden> wrote:

>> ... any machines that share user files via writable NFS mounts are
>> vulnerable. (Are vulnerable if you mount an NFS filesystem that is
>> writable to others.)
>
> No that is not true. You need to use root_squash for any semblance of
> security anyway. In that case you can also use squash_gids to prevent
> the attack.

Note that root_squash is default, squash_gids is not; there is no
recommendation to squash_gids staff. My machines do not know about
squash_gids (in "man exports", package nfs-kernel-server, versions
1.0-2woody3 or 1.0.6-3.1); I wonder if non-Debian OSs know.

(The issue of "real" users in group staff also remains.)

> ... I can design a [insecure] system ... Will that make it a Debian bug?

It is your bug if you make it insecure in the default, or in a common,
configuration. It is your bug if you do not warn against the insecure
settings.

Cheers,

Paul Szabo <email address hidden> http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia

Message-ID: <20050317110136.GF22698@seventeen>
Date: Thu, 17 Mar 2005 12:01:36 +0100
From: Bill Allombert <email address hidden>
To: <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

On Thu, Mar 17, 2005 at 07:25:56AM +1100, <email address hidden> wrote:
> Bill Allombert <email address hidden> wrote:
>
> >> ... any machines that share user files via writable NFS mounts are
> >> vulnerable. (Are vulnerable if you mount an NFS filesystem that is
> >> writable to others.)
> >
> > No that is not true. You need to use root_squash for any semblance of
> > security anyway. In that case you can also use squash_gids to prevent
> > the attack.
>
> Note that root_squash is default, squash_gids is not; there is no

Then the solution is to make squash_gids staff the default.

> recommendation to squash_gids staff. My machines do not know about
> squash_gids (in "man exports", package nfs-kernel-server, versions
> 1.0-2woody3 or 1.0.6-3.1);

At least woody nfs-user-server has it.

> I wonder if non-Debian OSs know.

How is it relevant ? this is a server-side setting.

> (The issue of "real" users in group staff also remains.)

There is no users in staff by default. Member of the group staff
normally has root access as well. The goal of group staff is to protect
against errors, not mischief.

Ho, and if you did not blacklist me I would be in a better mood to
discuss with you, thanks. Please read the bug log for other answers you
might have missed.

Cheers,
--
Bill. <email address hidden>

Imagine a large red swirl here.

Message-Id: <email address hidden>
Date: Wed, 23 Mar 2005 09:38:33 +1100
From: <email address hidden>
To: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

severity 299007 critical
justification root security hole

Message-Id: <email address hidden>
Date: Wed, 23 Mar 2005 10:22:55 +1100
From: <email address hidden>
To: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

I have now sent the following to the BugTraq and FullDisclosure mailing
lists, see e.g.

http://www.securityfocus.com/archive/1/393997
http://lists.grok.org.uk/pipermail/full-disclosure/2005-March/032804.html

Cheers,

Paul Szabo <email address hidden> http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia

---

> From psz Wed Mar 23 09:11:45 2005
> To: <email address hidden>, <email address hidden>
> Subject: root-equivalent groups
>
> Most UNIX/Linux installations have some groups (or users) whose members may
> be able to become root, for example:
>
> Group What Do
> bin /usr/bin create trojan
> disk /dev/hda raw write and create setuid root
> kmem /dev/kmem read root password
> shadow /etc/shadow crack root password
> staff /usr/local/bin create trojan
> tape /dev/st0 read confidential backup tape
> tty /dev/tty add keystrokes, run any code
>
> Often there are no users in these groups nor setgid binaries, so this may
> not matter; and in fact be useless, could be owned by root instead. Group
> staff is probably special in that administrators may add users to that
> group, thinking that this is a lesser privilege than root.
>
> Even in the absence of users in the group, it may be possible for attackers
> to "get" that group, via become-any-group-but-root bugs. Such bugs are
> quite common: when a group of machines share writable (e.g. user home)
> directories via NFS exported from somewhere with default root-squash,
> getting root on any one machine gives precisely that on all others of the
> group. There have been "genuine" such bugs also e.g. in sendmail.
>
> Please ensure that you are safe: review your use of root-equivalent groups,
> file ownerships, and NFS configurations.
>
> For some more discussion please see http://bugs.debian.org/299007 .
>
> Cheers,
>
> Paul Szabo <email address hidden> http://www.maths.usyd.edu.au/u/psz/
> School of Mathematics and Statistics University of Sydney Australia

Message-Id: <email address hidden>
Date: Tue, 22 Mar 2005 17:13:22 -0600
From: Manoj Srivastava <email address hidden>
To: <email address hidden>
Subject: severity inflation

severity 299007 wishlist
thanks

Message-ID: <email address hidden>
Date: Wed, 23 Mar 2005 10:07:07 +0000
From: <email address hidden>
To: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

If I may be permitted to toss 2p in here.

These groups were created for a good reason, which is that it's good
security practice to reduce the amount that has to be done by root.

The fact that certain things can only be done by root is widely
acknowledged to be a major failing of the traditional unix security
model, which is why we have things like Capabilities stuck on top to
try to mitigate it. Judicious use of groups is another way of reducing
the necessity for root, and one that Debian has pursued well in my opinion.

Paul Szabo's suggestion that if we just audit code then everything can
run as root and be safe is just not realistic. Even audited code has bugs.
Using sgid rather than suid binaries is an important harm-reduction principle
for when holes appear, as they always will appear.

For all the talk about groups being "root equivalent", the fact is that
they are only root equivalent under a very narrow set of circumstances
or series of events. They are therefore nowhere near equivalent to
actually getting root. I for one do not want to see these groups being
abandoned in favour of a return to the bad old days of needing to su root
to do anything. The more that is done as root, the more likely that
there will be big, root-now-on-every-system security holes, rather than
small, just about possible in some setups, root-later-if-you're-lucky holes.
You need to consider the balance of risks over the whole system.

Having group staff on /usr/local allows local software to be installed
without being root, which significantly reduces the potential harm that
may be caused by software from untrusted sources (you should always
audit all software before installation... reality check anyone?), as
well as the harm from errors that has already been mentioned by others.
alias rm="rm -i" is totally insufficient (and considered harmful because
people come to rely on it.) There are myriad other ways in which errors
or malice can strike, so we should *use* the unix groups and permissions
system (imperfect as it is), rather than abandoning it and using root
for anything that requires a modicum of privilege.

I'm in favour of the original proposal to alter root's PATHs and library
search order -- these make sense for the same reason as not having dot
on the PATH. Dropping groups as per what Paul seems to be suggesting
would make security worse, not better.

Ben

Message-Id: <email address hidden>
Date: Thu, 24 Mar 2005 07:30:14 +1100
From: <email address hidden>
To: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH in /root/.profile

Some Googling turned up the following:

http://www.tldp.org/HOWTO/Path-12.html
  Any of the important daemon processes should never execute anything that
  some other user can write into. In some systems, /usr/local/bin is
  allowed to contain programs with less strict security screening - it is
  just removed from the path of the root user.

http://www.tldp.org/HOWTO/Security-HOWTO/local-security.html
  The command path for the root user is very important. The command path
  (that is, the PATH environment variable) specifies the directories in
  which the shell searches for programs. Try to limit the command path for
  the root user as much as possible, and never include . (which means "the
  current directory") in your PATH. Additionally, never have writable
  directories in your search path ...

http://www.tldp.org/HOWTO/Tips-HOWTO-3.html
  Root's path should consist of 'PATH= /bin'
  That's it. Nothing else on root's path.

http://osmirrors.cerias.purdue.edu/pub/OpenBSD/src/etc/security
   { print "Root path directory " $10 " is group writable." }

http://security.sdsc.edu/advisories/outback_sec_guidelines
  Most current day operating systems have this but, audit root's path, make
  sure dirs are owned and only writable by root. minimize as much as
  possible, e.g. /sbin:/usr/sbin:/bin:/usr/bin

http://www.start-linux.com/articles/article_165.php
  One important thing to keep in mind are the different $PATH settings for
  users and root:
    * user: /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/user/bin:
    * root: /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin

http://www.unet.univie.ac.at/aix/aixbman/admnconc/system_security.htm
  The PATH value in the /etc/profile file is used by the root user. Only
  specify directories that are secure, that is, that only root can write
  to.

http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWaadm/SYSADV4/p98.html
  The paths that lead to the home directory must be owned and writable by
  root only. For example, if a .forward file is in /export/home/terry,
  /export and /export/home must be owned and writable by root only.

Cheers,

Paul Szabo <email address hidden> http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia

Message-Id: <email address hidden>
Date: Thu, 24 Mar 2005 19:11:18 +1100
From: <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH in /root/.profile

Dear Debian BTS gurus,

A day or so ago, in connection with another bug (#295435), I discovered
the existence and use of <email address hidden>. Out of curiosity, I
tried to set the severity of this bug to critical; to my amazement, this
worked; but then Manoj Srivastava set the severity back to wishlist.

My question: are the public in general and bug submitters in particular,
expected or permitted to use <email address hidden>?

(I apologize as I feel this is not the right forum to ask this question.
Feel free to direct me to the right forum.)

Thanks,

Paul Szabo <email address hidden> http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia

Message-ID: <20050324091901.GO30645@seventeen>
Date: Thu, 24 Mar 2005 10:19:01 +0100
From: Bill Allombert <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH in /root/.profile

On Thu, Mar 24, 2005 at 07:11:18PM +1100, <email address hidden> wrote:
> Dear Debian BTS gurus,
>
> A day or so ago, in connection with another bug (#295435), I discovered
> the existence and use of <email address hidden>. Out of curiosity, I
> tried to set the severity of this bug to critical; to my amazement, this
> worked; but then Manoj Srivastava set the severity back to wishlist.
>
> My question: are the public in general and bug submitters in particular,
> expected or permitted to use <email address hidden>?

Yes, they are. However we expect them to follow the rules.

This bug is now assigned to the debian-policy package.

One of the rules is that policy proposal are wishlist by definition.
See the policy-process document:
/usr/share/doc/debian-policy/policy-process.txt.gz

3.1. Initiating discussions
     ...
     Once the proposer is satisfied that the proposal has merit (with or
     without trying the waters on the list), the proposer should file a
     _wishlist_ bug against the debian-policy package. This stage can be
     initiated by any member of the list.

Definition of severity can be found here:
/usr/share/doc/debian/bug-maint-info.txt

   critical
          makes unrelated software on the system (or the whole system)
          break, or causes serious data loss, or introduces a security
          hole on systems where you install the package.

In no way installing the debian-policy package introduce a security
hole, causes serious data loss or makes unrelated software on the system
break.

Cheers,
--
Bill. <email address hidden>

Imagine a large red swirl here.

Message-Id: <email address hidden>
Date: Fri, 25 Mar 2005 06:37:14 +1100
From: <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH in /root/.profile

Bill,

Thank you for the explanations.

> One of the rules is that policy proposal are wishlist by definition.

Quite sensible: protect the policy-makers from blame and "litigation".
I guess that the couple of "normal" bugs listed under
  http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=debian-policy
never followed instructions and never set severity.

> In no way installing the debian-policy package introduce a security
> hole, causes serious data loss or makes unrelated software on the
> system break.

Not the installation of the policy package, but the following of the
policy, prevents base-files from being secure. Is not the policy at
fault if it mandates insecure settings or actions?

Cheers,

Paul Szabo <email address hidden> http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia

Message-ID: <20050324205151.GP30645@seventeen>
Date: Thu, 24 Mar 2005 21:51:51 +0100
From: Bill Allombert <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH in /root/.profile

On Fri, Mar 25, 2005 at 06:37:14AM +1100, <email address hidden> wrote:
> > In no way installing the debian-policy package introduce a security
> > hole, causes serious data loss or makes unrelated software on the
> > system break.
>
> Not the installation of the policy package, but the following of the
> policy, prevents base-files from being secure. Is not the policy at
> fault if it mandates insecure settings or actions?

I won't argue one way or another, but instead I will note that the only
practical effect (outside statistics) of bug severity is that in
principle packages with bugs of severity 'serious' 'grave' or 'critical'
are not shipped in the next stable release, sarge in the case at hand.

Removing the debian-policy package from sarge is unlikely to make
base-files (or Debian as a whole) any more secure.

Cheers,
--
Bill. <email address hidden>

Imagine a large red swirl here.

Message-ID: <email address hidden>
Date: Sun, 27 Mar 2005 14:24:37 +0200
From: Jakob Bohm <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

On Tue, Mar 22, 2005 at 09:20:41PM +1100, <email address hidden> wrote:
> Manoj Srivastava <email address hidden> wrote:
>
> >> The fact, though, is that this is a privilege escalation from the
> >> (documented, but essentially unused) 'staff' group to root.
> > ...
> > ... you can use [group staff] to allow people who already have the
> > root password to perform some tasks while they are not root.
>
> Is this feature seldom used, so we do not care much about it; or is it
> often used, and so possibly worth retaining?

Well, I certainly use it. I also create multiple non-root
accounts for people trusted to do 'root' things: A 'mortal'
account for reading mail and other normal work and one or more
'almost root' accounts for doing things like manipulating
/usr/local, installing software etc. Such an 'almost root'
account may or may not be a member of group 'staff' (some are,
some are not, depending on needs).

>
> In the default, unused state, it may be somewhat safe: it is not safe if
> you use NFS (in some common configurations). In the used state it is
> less safe: with or without NFS it may be possible to trojan the non-root
> staff user. Either way, the feature decreases security; this risk is not
> documented. I assert that in some common configurations the exposure is
> unacceptably high.
>

All secure operating systems that I work with include various
groups or similar that are subsets of root privileges with an
acknowledged potential of abusive escalation to full root. Some
go all the way and eliminate direct access to the root account
entirely, for instance 'adduser' on such systems might by
rwsr-x--- root admins or similar mechanisms.

It is thus fundamental to the security of any modern system that
the core OS infrastructure prevents 'become-trusted-group-bugs'
as strongly as they prevent 'become root directly' as these are
equivalent in the face of a competent, malicious attacker.

For instance most Unix/POSIX filesystems prevent creation of
sgid binaries (one of the example attack vectors mentioned) to
people already in that group. All but the most lousy security
systems prevent manipulation of other users files (another
example attack vector) by anyone not authenticated to do so.

The real, fundamental, security issue is that most
implementations of the NFS protocol blindly assume that none of
the client machines have had their local authentication systems
compromised in any way.

These broken-by-design NFS implementations are completely open
to full attacks against any accounts or groups allowed access
from the network. If just one machine on the network (with a
trusted or spoofed IP address) makes it possible to send
incorrect uids or gids to the NFS server, then that machine can
be used to trojanize any and all user writable files, for any
user. If home directories are NFS mounted by *other* machines,
all users of those accounts can then be trojanized by changing
the personal login scripts ...

Message-Id: <email address hidden>
Date: Mon, 28 Mar 2005 17:19:30 +1000
From: <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

Jakob Bohm <email address hidden> wrote:

>> Is this feature seldom used, so we do not care much about it; or is
>> it often used, and so possibly worth retaining?
>
> I certainly use it. I also create multiple ... 'almost root' accounts ...

You are smart enough to set up features similar to group staff, and do
not need group staff to be available *by default*.

> The real, fundamental, security issue is that most
> implementations of the NFS protocol ...

Group staff and NFS should not co-exist. Which one should Debian policy
warn against? Debian policy does not force you to use NFS, it must not
force you to have group staff either.

> These broken-by-design NFS implementations ... trojanize all user
> writable files ... all systems should be given the 'root compromise'
> cleanup.

Not quite as bad as that: root-squash should protect you somewhat.

>> Is it documented anywhere that you should only give group staff
>> privileges to those that also have the root password?
>
> I think it is probably documented somewhere (and certainly basic
> os-independent sysadmin knowledge) ...

Specific reference, please. Is it documented by Debian, in the policy
that forces group staff upon you?

>> At no time was I arguing for banning whatever ownership of /usr/local
>> by policy; I only wanted to also allow it being owned by root. ...
>> ... However, you must also grant me the right to run my machine
>> securely, and should not try to prevent me from doing so by policy.
>
> NOT agreed. ...

Do you really mean that? Which one do you mean: should policy
specifically disallow root ownership of /usr/local, or should it prevent
me from running my machine in a way that I (foolishly) think is safe?

> The problem is that most NFS-servers and most versions of the
> NFS protocol do not perform sufficient validation ...

NFS may be ugly and insecure. Should we banish it from Debian?

Cheers,

Paul Szabo <email address hidden> http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia

Message-ID: <email address hidden>
Date: Tue, 29 Mar 2005 00:37:04 +0200
From: Jakob Bohm <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

On Mon, Mar 28, 2005 at 05:19:30PM +1000, <email address hidden> wrote:
> Jakob Bohm <email address hidden> wrote:
>
> >> Is this feature seldom used, so we do not care much about it; or is
> >> it often used, and so possibly worth retaining?
> >
> > I certainly use it. I also create multiple ... 'almost root' accounts ...
>
> You are smart enough to set up features similar to group staff, and do
> not need group staff to be available *by default*.
>

Well I am smart enough that in theory I don't need anything at
all to be available by default (not even the operating system),
but each thing not there by default is more work to do, more
room for mistakes and less time to actually use the computer.

> > The real, fundamental, security issue is that most
> > implementations of the NFS protocol ...
>
> Group staff and NFS should not co-exist. Which one should Debian policy
> warn against? Debian policy does not force you to use NFS, it must not
> force you to have group staff either.
>

As I explain later in the mail, killing off group staff will not
save you, you are demanding that we randomly lynch a security
feature for absolutely no gain.

> > These broken-by-design NFS implementations ... trojanize all user
> > writable files ... all systems should be given the 'root compromise'
> > cleanup.
>
> Not quite as bad as that: root-squash should protect you somewhat.

No it will not! If an attacker can trojanize any user or group
account used to do trusted work (such as recompiling kernels or
performing backups or managing disks or mirroring debian or
accessing raw I/O or ...) then that can be used to escalate
further to root. Group staff is just a random example of such a
group or account.

And even if that does not happen, compromising each and every
ordinary user account including those belonging to the sysadmins
is bad enough that all user accessible data of any kind should
be considered suspect and restored / recreated from a point
before the compromise. At that point it is mostly moot if the
root data should be restored too, and one should not bet on root
not being uncompromised but proceed as if it was.

>
> >> Is it documented anywhere that you should only give group staff
> >> privileges to those that also have the root password?
> >
> > I think it is probably documented somewhere (and certainly basic
> > os-independent sysadmin knowledge) ...
>
> Specific reference, please. Is it documented by Debian, in the policy
> that forces group staff upon you?

I wrote "probably somewhere" because I have not wasted time
looking for any Debian specific tutorial stating this. The text
you snipped explains why and how I consider this to be something
that belongs in basic training. Its like "don't lend people
keys to anything if they cannot be trusted or cannot keep the
key safe".

Some simple *examples* to illustrate my point:

Debian GNU/Linux woody predefines several groups, of those

   These can probably be abus...

Message-Id: <email address hidden>
Date: Thu, 31 Mar 2005 06:16:46 +1000
From: <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

Jakob Bohm <email address hidden> wrote:

>>>> Is it documented anywhere that you should only give group staff
>>>> privileges to those that also have the root password?
>
> I wrote "probably somewhere" because I have not wasted time ...
> Its like "don't lend people keys to anything if they cannot be
> trusted or cannot keep the key safe".

Keys to anything? I gave you a key to your hotel room, not to my house.

> Debian GNU/Linux woody predefines several groups ...

Thank you for expanding my list.

> Only two groups are mostly impossible to abuse:
> users, nogroup

You may be wrong on nogroup. Define "mostly impossible".

> Microsoft Windows/NT ...

Irrelevant.

>>>> At no time was I arguing for banning whatever ownership of /usr/local
>>>> by policy; I only wanted to also allow it being owned by root. ...
>
> I do not agree that anything you have posted so far justifies
> disallowing /usr/local to be owned by group staff by default.
> If you think that chown -R :root /usr /bin /sbin /etc will make
> you safer you are free to make that mistake on your own system,
> just don't force it on the world.

The directories you mention are in fact owned by root:root.

>>> The problem is that most NFS-servers and most versions of the
>>> NFS protocol do not perform sufficient validation ...
>>
>> NFS may be ugly and insecure. Should we banish it from Debian?
>
> No, but maybe we should make sure all the Debian-shipped NFS
> implementations include all necessary security extensions and
> enable those extensions by default.

Should the "currently shipping" NFS implementations be banned? Getting them
secured: is that being worked on?

> ... fickle grounds that some software is not enforcing group
> authentication properly.

Security does not work without enforcement.

Leaving petty arguments and cheap character assassinations aside.

Group staff is an anachronism: its ownership of /home is "wrong". Its use
and usefulness should be reviewed.

Group staff is said to be useful "for helpdesk types or junior sysadmins",
without warnings that it is in fact root-equivalent.

Use of root-equivalent users and groups may enlarge the attack surface.

If commonly used software allows breaching some security features, then
the features need to be changed.

Cheers,

Paul Szabo <email address hidden> http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia

Message-ID: <20050330232605.GV30645@seventeen>
Date: Thu, 31 Mar 2005 01:26:05 +0200
From: Bill Allombert <email address hidden>
To: <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

On Thu, Mar 31, 2005 at 06:16:46AM +1000, <email address hidden> wrote:
> Group staff is an anachronism: its ownership of /home is "wrong". Its use
> and usefulness should be reviewed.

An anachromism ? What paradigm shift made it "wrong" ?

> Group staff is said to be useful "for helpdesk types or junior sysadmins",
> without warnings that it is in fact root-equivalent.

Who said that ?

sg staff -c make install
and
su root -c make install

are very different security-wise. For once, the first will fail if we
mistakenly try to install in /usr instead of /usr/local.

> Use of root-equivalent users and groups may enlarge the attack surface.

There are a lot of them, though.

> If commonly used software allows breaching some security features, then
> the features need to be changed.

No security conscious person use NFS in a security sensitive context
anyway.

Cheers,
--
Bill. <email address hidden>

Imagine a large red swirl here.

Message-Id: <email address hidden>
Date: Thu, 31 Mar 2005 10:40:36 +1000
From: <email address hidden>
To: <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

Bill Allombert <email address hidden> wrote:

>> Group staff is an anachronism: its ownership of /home is "wrong". Its use
>> and usefulness should be reviewed.
>
> An anachromism ? What paradigm shift made it "wrong" ?
>
>> Group staff is said to be useful "for helpdesk types or junior sysadmins",
>> without warnings that it is in fact root-equivalent.
>
> Who said that ?

Quoting from the original bug report:

  The Debian Reference [3] and Securing Debian Manual [4], [5] say

    [group] staff is ... for helpdesk types or junior sysadmins ... to do
    things in /usr/local and to create directories in /home.

    [group] staff: Allows users to add local modifications to the system
    (/usr/local, /home) without needing root privileges.

    The 'staff' group are usually help-desk/junior sysadmins, allowing them
    to work in /usr/local and create directories in /home.

  (This is surely wrong, seems a SysV left-over: you need root privileges to
  chown user directories in /home or in fact to create users in /etc/passwd.)
  ...
  [3] http://www.debian.org/doc/manuals/reference/ch-tune.en.html#s9.2.3
  [4] http://www.debian.org/doc/manuals/securing-debian-howto/ch11.en.html#s11.1.12.1
  [5] http://www.debian.org/doc/manuals/securing-debian-howto/ch11.en.html#s11.1.12.2

Re-wording. Group staff ownership of /home does not seem very useful, as it
only allows directories to be created but not chowned to the user. I guess
that this is a left-over from SysV times when anyone could chown.

The above quoted authoritative Debian references advertise the use of group
staff for semi-trusted users.

>> Use of root-equivalent users and groups may enlarge the attack surface.
>
> There are a lot of them, though.

Noted. All the more enlargement.

>> If commonly used software allows breaching some security features, then
>> the features need to be changed.
>
> No security conscious person use NFS in a security sensitive context
> anyway.

Is this hearsay, common knowledge, or documented somewhere?

Please note that NFS was only an example how root-equivalent things become
an acute issue. (Admittedly my only current example: you rightfully would
not accept past sendmail bugs.)

Cheers,

Paul Szabo <email address hidden> http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia

Message-Id: <email address hidden>
Date: Thu, 14 Apr 2005 10:29:21 +1000
From: <email address hidden>
To: <email address hidden>, <email address hidden>, <email address hidden>
Cc: <email address hidden>, <email address hidden>, <email address hidden>
Subject: Re: gzip TOCTOU file-permissions vulnerability

Joey Hess <email address hidden> wrote:

>> ... really dumb idea to have a group/world-writeable directory
>> without the sticky bit.
>
> It may be really dumb, but it's pretty common practice too. ...
> Just a few examples within the Debian project ...

Kindly add the Debian example:

psz@pisa:/usr/local$ ls -ld .
drwxrwsr-x 10 root staff 4096 Nov 13 2002 .

For Debian this is "mandated by policy":

> The Debian Policy Manual [1] says:
>
> ... /usr/local take precedence over the equivalents in /usr.
> ... should have permissions 2775 and be owned by root.staff.
>
> but it [2] also says:
>
> ... make sure that [it] is secure ...
> Files should be owned by root.root ... mode 644 or 755.
> Directories should be mode 755 or 2775 ... owned by the group that needs
> write access to it.
>
> ...
> References:
>
> [1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2
> [2] http://www.debian.org/doc/debian-policy/ch-files.html#s10.9

(please see http://bugs.debian.org/299007 for more details).

> (gzip is not typically ran in any of these directories AFAIK, FWIW).

Typically? Suppose I (as simple user psz) do

  cd $HOME; touch xyz; chmod 666 xyz; gzip xyz

and tell my system manager that I have problems with that gzipped file.
While root is running "gunzip ~psz/xyz" I do

  rm xyz; ln /etc/passwd xyz

then we end up with /etc/passwd world-writable. (Bzip uses chown also, so
using bzip2/bunzip would get /etc/passwd owned by psz; am not sure about
gzip or cpio.)

Cheers,

Paul Szabo <email address hidden> http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia