base-files: Insecure PATH in /root/.profile
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
base-files (Debian) |
Fix Released
|
Unknown
|
|||
base-files (Ubuntu) |
Invalid
|
High
|
Martin Pitt |
Bug Description
Automatically imported from Debian bug report #299007 http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #1 |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #2 |
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/
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-
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-
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/
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://
[2] http://
[3] http://
[4] http://
[5] http://
[6] http://
[7] http://
[8] http://
Cheers,
Paul Szabo <email address hidden> http...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Matt Zimmerman (mdz) wrote : | #3 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Martin Pitt (pitti) wrote : | #4 |
(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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#5 |
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/
> 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-
> 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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #6 |
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/
> 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-
> 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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#7 |
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-
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-
--- debian-
+++ debian-
@@ -5062,8 +5062,8 @@
then
if mkdir /usr/local/
then
- chown root:staff /usr/local/
- chmod 2775 /usr/local/
+ chown root:root /usr/local/
+ chmod 755 /usr/local/
fi
fi
</example>
@@ -5095,8 +5095,8 @@
<p>
The <file>/
subdirect
- permissions 2775 (group-writable and set-group-id) and be
- owned by <tt>root.
+ permissions 755 and be
+ owned by <tt>root:root</tt>.
</p>
</sect1>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #8 |
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-
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-
--- debian-
+++ debian-
@@ -5062,8 +5062,8 @@
then
if mkdir /usr/local/
then
- chown root:staff /usr/local/
- chmod 2775 /usr/local/
+ chown root:root /usr/local/
+ chmod 755 /usr/local/
fi
fi
</example>
@@ -5095,8 +5095,8 @@
<p>
The <file>/
subdirect
- permissions 2775 (group-writable and set-group-id) and be
- owned by <tt>root.
+ permissions 755 and be
+ owned by <tt>root:root</tt>.
</p>
</sect1>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#9 |
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-
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-
> --- debian-
> +++ debian-
> @@ -5062,8 +5062,8 @@
> then
> if mkdir /usr/local/
> then
> - chown root:staff /usr/local/
> - chmod 2775 /usr/local/
> + chown root:root /usr/local/
> + chmod 755 /usr/local/
> 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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#10 |
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-
>
> 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-
> --- debian-
> +++ debian-
> @@ -5062,8 +5062,8 @@
> then
> if mkdir /usr/local/
> then
> - chown root:staff /usr/local/
> - chmod 2775 /usr/local/
> + chown root:root /usr/local/
> + chmod 755 /usr/local/
> fi
> fi
> </example>
> @@ -5095,8 +5095,8 @@
> <p>
> The <file>/
> subdirectories created by the package should (by default) have
> - permissions 2775 (group-writable and set-group-id) and be
> - owned by <tt>root.
> + 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
--
Martin Pitt http://
Ubuntu Developer http://
Debian GNU/Linux Developer http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #11 |
Message-ID: <20050311141732
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-
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-
> --- debian-
> +++ debian-
> @@ -5062,8 +5062,8 @@
> then
> if mkdir /usr/local/
> then
> - chown root:staff /usr/local/
> - chmod 2775 /usr/local/
> + chown root:root /usr/local/
> + chmod 755 /usr/local/
> 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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #12 |
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-
Content-
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-
>=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-
icy.sgml
> --- debian-
+0200
> +++ debian-
> @@ -5062,8 +5062,8 @@
> then
> if mkdir /usr/local/
> then
> - chown root:staff /usr/local/
> - chmod 2775 /usr/local/
> + chown root:root /usr/local/
> + chmod 755 /usr/local/
> fi
> fi
> </example>
> @@ -5095,8 +5095,8 @@
> <p>
> The <file>/
> subdirectories created by the package should (by default) have
> - permissions 2775 (group-writable and set-group-id) and be
> - owned by <tt>root.
> + 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://
Ubuntu Developer http://
Debian GNU/Linux Developer http://
--EVF5PPMfhYS0aIcm
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCMaqHDec
PjLMdvz0Z4l0IPC
=5kCq
-----END PGP SIGNATURE-----
--EVF5PPMfhYS0a
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#13 |
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.
--
ciao,
Marco
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #14 |
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-
Content-
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/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCMbfuFGf
QJseS/ojl5iN1Bb
=zsZL
-----END PGP SIGNATURE-----
--7JfCtLOvnd9MI
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#15 |
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/
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/
Cheers,
--
Bill. <email address hidden>
Imagine a large red swirl here.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#16 |
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-
>
> 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-
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #17 |
Message-ID: <20050311172257
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/
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/
Cheers,
--
Bill. <email address hidden>
Imagine a large red swirl here.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #18 |
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-
>
> 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-
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#19 |
I fully support removing this privilege of group staff; it simply makes
group staff root-equivalent.
--
- mdz
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #20 |
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
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#21 |
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-
> >
> > 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-
> 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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #22 |
Message-ID: <20050311191555
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-
> >
> > 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-
> 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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#23 |
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-
> 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/
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.
--
Steve Langasek
postmodern programmer
> diff -ru debian-
> --- debian-
> +++ debian-
> @@ -5062,8 +5062,8 @@
> then
> if mkdir /usr/local/
> then
> - chown root:staff /usr/local/
> - chmod 2775 /usr/local/
> + chown root:root /usr/local/
> + chmod 755 /usr/local/
> fi
> fi
> </example>
> @@ -5095,8 +5095,8 @@
> <p>
> The <file>/
> subdirectories created by the package should (by default) have
> - permissions 2775 (group-writable and set-group-id) and be
> - owned by <tt>root.
> + permissions 755 and be
> + owned by <tt>root:root</tt>.
> </p>
> </sect1>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #24 |
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-
Content-
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-
> 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/
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-
icy.sgml
> --- debian-
+0200
> +++ debian-
> @@ -5062,8 +5062,8 @@
> then
> if mkdir /usr/local/
> then
> - chown root:staff /usr/local/
> - chmod 2775 /usr/local/
> + chown root:root /usr/local/
> + chmod 755 /usr/local/
> fi
> fi
> </example>
> @@ -5095,8 +5095,8 @@
> <p>
> The <file>/
> subdirectories created by the package should (by default) have
> - permissions 2775 (group-writable and set-group-id) and be
> - owned by <tt>root.
> + permissions 755 and be
> + owned by <tt>root:root</tt>.
> </p>
> </sect1>
--H+4ONPRPur6+Ovig
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCMhFgKN6
RgpCHDpH9Q4FWHZ
=WhHx
-----END PGP SIGNATURE-----
--H+4ONPRPur6+
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#25 |
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/
>
> 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/
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>]
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #26 |
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/
>
> 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/
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>]
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#27 |
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-
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:
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/
earlier in @INC than /usr/{lib,
has breached a group staff acount another avenue: creating say
/usr/local/
$> == 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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #28 |
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-
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:
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/
earlier in @INC than /usr/{lib,
has breached a group staff acount another avenue: creating say
/usr/local/
$> == 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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#29 |
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-
>
> 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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #30 |
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-
>
> 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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#31 |
"Brendan O'Dea" <email address hidden> wrote:
> ... there's more at stake here than just PATH, since perl for example has
> /usr/local/
>
> 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://
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://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #32 |
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/
>
> 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://
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://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#33 |
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/
> >
> > 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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Matt Zimmerman (mdz) wrote : | #34 |
re-resolving as NOTWARTY to avoid further mail
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #35 |
Message-ID: <20050316191925
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/
> >
> > 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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#36 |
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://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #37 |
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://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#38 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #39 |
Message-ID: <20050317110136
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#40 |
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 root-squash and mooted squash_gids options are for the server exporting
the tree, the attack is against the machines mounting it. The exporter may
be a non-Debian server, or it may be Debian using nfs-kernel-server.
Non-Debian servers would not know about group staff == GID 50.
>> (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.
Whatever the goal, it must also protect against mischief, unless it is
clearly and prominently documented that giving group staff access is
equivalent to giving root access.
You said earlier that
The first goal of the unix permissions is to protect against errors
rather than malices.
and used the example of the sysadmin who does rm -r /usr/lib instead of
rm -r /usr/local/lib by mistake. I believe that your statements about
goals are wrong. To protect against mistakes use things like
alias rm='rm -i'
Protections and permissions must be enforceable. Security must not depend
on "normally", "probably" or "unlikely" and similar qualifications.
> 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.
I apologize for blacklisting your ISP. Apparently the bounce message from
maths.usyd.edu.au said:
see http://
I will now ask my postmaster to whitelist your email address.
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #41 |
Message-Id: <email address hidden>
Date: Fri, 18 Mar 2005 06:31:17 +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
>
> 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 root-squash and mooted squash_gids options are for the server exporting
the tree, the attack is against the machines mounting it. The exporter may
be a non-Debian server, or it may be Debian using nfs-kernel-server.
Non-Debian servers would not know about group staff == GID 50.
>> (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.
Whatever the goal, it must also protect against mischief, unless it is
clearly and prominently documented that giving group staff access is
equivalent to giving root access.
You said earlier that
The first goal of the unix permissions is to protect against errors
rather than malices.
and used the example of the sysadmin who does rm -r /usr/lib instead of
rm -r /usr/local/lib by mistake. I believe that your statements about
goals are wrong. To protect against mistakes use things like
alias rm='rm -i'
Protections and permissions must be enforceable. Security must not depend
on "normally", "probably" or "unlikely" and similar qualifications.
> 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.
I apologize for blacklisting your ISP. Apparently the bounce message from
maths.usyd.edu.au said:
see http://
I will now ask my postmaster to whitelist your email address.
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#42 |
On Wed, Mar 16, 2005 at 06:00:14PM +0100, Santiago Vila wrote:
>On Wed, 16 Mar 2005, Brendan O'Dea wrote:
>> 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.
Fair point, although while /usr/local is staff-writable by default, no
users are in group staff by default. So out of the box, this situation
is no different to having the group as root.
The only difference is to users who *do* wish to take advantage of this
facility, saving the need for:
# chgrp -R staff /usr/local /var/local
# chmod -R +t,g+w /usr/local /var/local
and requiring only the final step of:
# adduser fred staff
>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.
A formal objection? I was of the belief that this was still being
discussed.
While there has been some support, there is not consensus: both myself
and Bill Allombert have raised issues with the proposal as given in
message <email address hidden> of changing
the group of /usr/local to root.
I believe that the facility of having a group which may write to
/usr/local is very useful and should be retained. Furthermore, I would
assert that the current situation poses no security risks without the
administrator choosing to add users to the staff group.
The group need not be called "staff" specifically, since due to the
generic nature of the name it is possible that an administrator may
choose to add staff users to that group (either for documentary
purposes, or to provide write permission to some other, site-specific
part of the hierarchy) without being aware that this would allow them to
write to elements of root's PATH.
Using "local" for /usr/local (in line with the current "src" for
/usr/src) may be an option if the above was deemed to be a sufficient
risk.
Clearly documenting the possible risks of adding a user to the group
should probably be added to users-and-
Having /home writable by group staff OTOH doesn't seem particularly
useful.
--bod
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #43 |
Message-ID: <email address hidden>
Date: Sat, 19 Mar 2005 18:56:37 +1100
From: Brendan O'Dea <email address hidden>
To: Santiago Vila <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
On Wed, Mar 16, 2005 at 06:00:14PM +0100, Santiago Vila wrote:
>On Wed, 16 Mar 2005, Brendan O'Dea wrote:
>> 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.
Fair point, although while /usr/local is staff-writable by default, no
users are in group staff by default. So out of the box, this situation
is no different to having the group as root.
The only difference is to users who *do* wish to take advantage of this
facility, saving the need for:
# chgrp -R staff /usr/local /var/local
# chmod -R +t,g+w /usr/local /var/local
and requiring only the final step of:
# adduser fred staff
>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.
A formal objection? I was of the belief that this was still being
discussed.
While there has been some support, there is not consensus: both myself
and Bill Allombert have raised issues with the proposal as given in
message <email address hidden> of changing
the group of /usr/local to root.
I believe that the facility of having a group which may write to
/usr/local is very useful and should be retained. Furthermore, I would
assert that the current situation poses no security risks without the
administrator choosing to add users to the staff group.
The group need not be called "staff" specifically, since due to the
generic nature of the name it is possible that an administrator may
choose to add staff users to that group (either for documentary
purposes, or to provide write permission to some other, site-specific
part of the hierarchy) without being aware that this would allow them to
write to elements of root's PATH.
Using "local" for /usr/local (in line with the current "src" for
/usr/src) may be an option if the above was deemed to be a sufficient
risk.
Clearly documenting the possible risks of adding a user to the group
should probably be added to users-and-
Having /home writable by group staff OTOH doesn't seem particularly
useful.
--bod
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#44 |
On Sat, Mar 19, 2005 at 06:56:37PM +1100, Brendan O'Dea wrote:
> I believe that the facility of having a group which may write to
> /usr/local is very useful and should be retained. Furthermore, I would
> assert that the current situation poses no security risks without the
> administrator choosing to add users to the staff group.
I would like to add there is at least an other group in Debian that is
equivalent to root access, namely disk, and there are others that
present a security risk (e.g. shadow). Why special casing staff ?
> Having /home writable by group staff OTOH doesn't seem particularly
> useful.
This is useful when you want to store data in the /home partition that
do not need to belong to any user.
You can do e.g.
mkdir /home/debs; mv *.deb /home/debs
And so far no one has stated how it was a security risk.
Cheers,
--
Bill. <email address hidden>
Imagine a large red swirl here.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #45 |
Message-ID: <20050319093830
Date: Sat, 19 Mar 2005 10:38:30 +0100
From: Bill Allombert <email address hidden>
To: Brendan O'Dea <email address hidden>, <email address hidden>
Cc: Santiago Vila <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
On Sat, Mar 19, 2005 at 06:56:37PM +1100, Brendan O'Dea wrote:
> I believe that the facility of having a group which may write to
> /usr/local is very useful and should be retained. Furthermore, I would
> assert that the current situation poses no security risks without the
> administrator choosing to add users to the staff group.
I would like to add there is at least an other group in Debian that is
equivalent to root access, namely disk, and there are others that
present a security risk (e.g. shadow). Why special casing staff ?
> Having /home writable by group staff OTOH doesn't seem particularly
> useful.
This is useful when you want to store data in the /home partition that
do not need to belong to any user.
You can do e.g.
mkdir /home/debs; mv *.deb /home/debs
And so far no one has stated how it was a security risk.
Cheers,
--
Bill. <email address hidden>
Imagine a large red swirl here.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#46 |
Brendan O'Dea <email address hidden> wrote:
> ... the current situation poses no security risks without the
> administrator choosing to add users to the staff group.
Sorry, that is wrong. Quoting from the original bug report:
> Become-
> 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].
Bill Allombert <email address hidden> wrote:
> ... there is at least an other group in Debian that is equivalent
> to root access, namely disk, and there are others that present a
> security risk (e.g. shadow). Why special casing staff ?
Thanks for pointing those out! Add group tty also? All should be
"squashed" (and the objects owned by root:root instead).
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #47 |
Message-Id: <email address hidden>
Date: Sat, 19 Mar 2005 21:35:42 +1100
From: <email address hidden>
To: <email address hidden>, <email address hidden>, <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
Brendan O'Dea <email address hidden> wrote:
> ... the current situation poses no security risks without the
> administrator choosing to add users to the staff group.
Sorry, that is wrong. Quoting from the original bug report:
> Become-
> 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].
Bill Allombert <email address hidden> wrote:
> ... there is at least an other group in Debian that is equivalent
> to root access, namely disk, and there are others that present a
> security risk (e.g. shadow). Why special casing staff ?
Thanks for pointing those out! Add group tty also? All should be
"squashed" (and the objects owned by root:root instead).
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#48 |
On Sat, Mar 19, 2005 at 09:35:42PM +1100, <email address hidden> wrote:
>Thanks for pointing those out! Add group tty also? All should be
>"squashed" (and the objects owned by root:root instead).
Hey, good idea! Why don't we ditch *all* the groups and have everything
groupt root!
That "src" group is *obviously* a security risk, it makes any user in
that group root-equiv since they can dick with /usr/src/linux...
Sheesh. Get a grip.
The various role groups are useful, and typically *increase* security
since they provide limited access to certain files/subtrees. Moreover
by default no user is placed into those groups.
Your argument is that exporting a writable / or /usr via NFS exposes you
to possible exploits? Then DON'T DO THAT.
Can you give a realistic example where one would *want* such an export?
Moreover one without all_squash?
NFS exports of /usr for diskless workstations are typically read-only,
and in such cases / is either also read-only or specific to the client.
--bod
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #49 |
Message-ID: <email address hidden>
Date: Sat, 19 Mar 2005 23:19:09 +1100
From: Brendan O'Dea <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
On Sat, Mar 19, 2005 at 09:35:42PM +1100, <email address hidden> wrote:
>Thanks for pointing those out! Add group tty also? All should be
>"squashed" (and the objects owned by root:root instead).
Hey, good idea! Why don't we ditch *all* the groups and have everything
groupt root!
That "src" group is *obviously* a security risk, it makes any user in
that group root-equiv since they can dick with /usr/src/linux...
Sheesh. Get a grip.
The various role groups are useful, and typically *increase* security
since they provide limited access to certain files/subtrees. Moreover
by default no user is placed into those groups.
Your argument is that exporting a writable / or /usr via NFS exposes you
to possible exploits? Then DON'T DO THAT.
Can you give a realistic example where one would *want* such an export?
Moreover one without all_squash?
NFS exports of /usr for diskless workstations are typically read-only,
and in such cases / is either also read-only or specific to the client.
--bod
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#50 |
Synopsis:
Make squash_gids be a default for the NFS server, make /home
not be writable by group staff, leave /usr/local alone.
=======
By default, in Debian, /usr/local is integrated into the OS,
it is in the default path for root, it is in the library path for
systems like Emacs, Perl, Python,, etc.
/usr/local, by default, is created group writable by group
staff. This is not a security issue on the local machine, since by
default group staff is empty, and there are no sgif staff binaries in
Debian It is present to allow a finer distinction of privileges on
the machine, by adding people to group staff one may allow people to
update bits of /usr/local (like, for instance, installing CPAN
modules, elisp packages, CTAN bundles, etc). Having finer grained
privileges is a nice feature; anything to prevent the blunt use of
super-user in Linux is something we should encourage. There fore it
is better to do this by default than making every local admin do it
on their own.
The problem comes with NFS. If the system is not exported
read-only in NFS, then any exploit on the remote machine may
compromise the local machine. There are mechanisms in place to
prevent this from happening:
a) export the file system read only.
b) export the file system with root_squash on squash_gids
c) use SELinux on both ends and label the network and use the
patched SELinux aware NFS code :P
The issue is that by default only root_squash is enabled, but
not squash_gids, which seems to be the crux of the problem
reported. Fixing that is a better solution than forcing the local
administrator to add more entry points to gaining uid=0* (using sudo,
for instance), instead of giving these local roles the ability to
write to a subset of the file system.
Also, the vast majority of installs do not NFS export
/usr/local, so while they can benefit from the finer grained control
of who can write to /usr/local, they won't benefit from the "don't
need to add squash_gids". Even in the subset of machines that NFS
export file systems, not all of them export /usr/local; so we are
talking about far different constituencies here.
The common case by far benefits from /usr/local not requiring
uid=0 to modify; and we should be making things easier for the common
case, and not too much harder for the uncommon.
Making /home not writable by group staff is more reasonable,
and this should be done.
manoj
--
Feminists just want the human race to be a tie.
Manoj Srivastava <email address hidden> <http://
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #51 |
Message-ID: <email address hidden>
Date: Sat, 19 Mar 2005 10:45:20 -0600
From: Manoj Srivastava <<email address hidden> (va, manoj)>
To: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
Synopsis:
Make squash_gids be a default for the NFS server, make /home
not be writable by group staff, leave /usr/local alone.
=======
By default, in Debian, /usr/local is integrated into the OS,
it is in the default path for root, it is in the library path for
systems like Emacs, Perl, Python,, etc.
/usr/local, by default, is created group writable by group
staff. This is not a security issue on the local machine, since by
default group staff is empty, and there are no sgif staff binaries in
Debian It is present to allow a finer distinction of privileges on
the machine, by adding people to group staff one may allow people to
update bits of /usr/local (like, for instance, installing CPAN
modules, elisp packages, CTAN bundles, etc). Having finer grained
privileges is a nice feature; anything to prevent the blunt use of
super-user in Linux is something we should encourage. There fore it
is better to do this by default than making every local admin do it
on their own.
The problem comes with NFS. If the system is not exported
read-only in NFS, then any exploit on the remote machine may
compromise the local machine. There are mechanisms in place to
prevent this from happening:
a) export the file system read only.
b) export the file system with root_squash on squash_gids
c) use SELinux on both ends and label the network and use the
patched SELinux aware NFS code :P
The issue is that by default only root_squash is enabled, but
not squash_gids, which seems to be the crux of the problem
reported. Fixing that is a better solution than forcing the local
administrator to add more entry points to gaining uid=0* (using sudo,
for instance), instead of giving these local roles the ability to
write to a subset of the file system.
Also, the vast majority of installs do not NFS export
/usr/local, so while they can benefit from the finer grained control
of who can write to /usr/local, they won't benefit from the "don't
need to add squash_gids". Even in the subset of machines that NFS
export file systems, not all of them export /usr/local; so we are
talking about far different constituencies here.
The common case by far benefits from /usr/local not requiring
uid=0 to modify; and we should be making things easier for the common
case, and not too much harder for the uncommon.
Making /home not writable by group staff is more reasonable,
and this should be done.
manoj
--
Feminists just want the human race to be a tie.
Manoj Srivastava <email address hidden> <http://
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#52 |
Brendan O'Dea <email address hidden> wrote:
> Your argument is that exporting a writable / or /usr via NFS exposes
> you to possible exploits? Then DON'T DO THAT.
and Manoj Srivastava <email address hidden> wrote:
> ... majority do not NFS export /usr/local ...
Sorry, but that is not the issue. The attacked machine would not be an
exporter, but a mounter of user files.
Suppose I have a bunch of machines, that "share" user files: all
NFS-mount /users (containing user home directories /users/*). Getting
root on any one of this bunch of machines would allow me to create a
setgid-staff file; or maybe I could mess around with the .bashrc of a
user in group staff.
Arguments about exports with squash_gids are moot: many NFS exporters do
not have that option; and non-Debian exporters would not know or care
about group staff.
Other points raised:
> That "src" group is *obviously* a security risk, it makes any user in
> that group root-equiv since they can dick with /usr/src/linux...
No risk: /usr/src is not used on a regular basis. Root should verify his
sources before building and installing a new kernel.
> The various role groups are useful [to] provide limited access to
> certain files/subtrees.
Yes, e.g. group mail is useful (only because we do not trust sendmail?).
Group disk is not useful: there is no-one in that group, nor are there
setgid-disk binaries. I wonder about group tty.
> ... a finer distinction of privileges ... we should encourage.
Yes, definitely; but we need to do so securely.
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #53 |
Message-Id: <email address hidden>
Date: Sun, 20 Mar 2005 11:21:07 +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:
> Your argument is that exporting a writable / or /usr via NFS exposes
> you to possible exploits? Then DON'T DO THAT.
and Manoj Srivastava <email address hidden> wrote:
> ... majority do not NFS export /usr/local ...
Sorry, but that is not the issue. The attacked machine would not be an
exporter, but a mounter of user files.
Suppose I have a bunch of machines, that "share" user files: all
NFS-mount /users (containing user home directories /users/*). Getting
root on any one of this bunch of machines would allow me to create a
setgid-staff file; or maybe I could mess around with the .bashrc of a
user in group staff.
Arguments about exports with squash_gids are moot: many NFS exporters do
not have that option; and non-Debian exporters would not know or care
about group staff.
Other points raised:
> That "src" group is *obviously* a security risk, it makes any user in
> that group root-equiv since they can dick with /usr/src/linux...
No risk: /usr/src is not used on a regular basis. Root should verify his
sources before building and installing a new kernel.
> The various role groups are useful [to] provide limited access to
> certain files/subtrees.
Yes, e.g. group mail is useful (only because we do not trust sendmail?).
Group disk is not useful: there is no-one in that group, nor are there
setgid-disk binaries. I wonder about group tty.
> ... a finer distinction of privileges ... we should encourage.
Yes, definitely; but we need to do so securely.
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#54 |
On Sun, 20 Mar 2005 11:21:07 +1100, psz <email address hidden> said:
> Brendan O'Dea <email address hidden> wrote:
>> Your argument is that exporting a writable / or /usr via NFS
>> exposes you to possible exploits? Then DON'T DO THAT.
> and Manoj Srivastava <email address hidden> wrote:
>> ... majority do not NFS export /usr/local ...
> Sorry, but that is not the issue. The attacked machine would not be
> an exporter, but a mounter of user files.
Umm. The exporter is the one that got attacked, since it has
the data. every other user that mounts the file system is collateral
damage.
> Suppose I have a bunch of machines, that "share" user files: all
> NFS-mount /users (containing user home directories
> /users/*). Getting root on any one of this bunch of machines would
> allow me to create a setgid-staff file; or maybe I could mess around
> with the .bashrc of a user in group staff.
I think you did not bother to read my response, since I
explicitly stated that there is no reason to have /home writable by
user staff.
> Arguments about exports with squash_gids are moot: many NFS
> exporters do not have that option; and non-Debian exporters would
> not know or care about group staff.
Umm, non-debian exporters are not covered by policy, and thus
we do not care about them. And since this is not a client side thing
at all, this line of argument is just noise.
I do not see this email in any way pointing to a valid flaw in
my summary.
manoj
--
"The most formidable weapon against errors of every kind is reason."
Thomas Paine, _The Age of Reason_
Manoj Srivastava <email address hidden> <http://
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #55 |
Message-ID: <email address hidden>
Date: Sat, 19 Mar 2005 19:03:29 -0600
From: Manoj Srivastava <<email address hidden> (va, manoj)>
To: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
On Sun, 20 Mar 2005 11:21:07 +1100, psz <email address hidden> said:
> Brendan O'Dea <email address hidden> wrote:
>> Your argument is that exporting a writable / or /usr via NFS
>> exposes you to possible exploits? Then DON'T DO THAT.
> and Manoj Srivastava <email address hidden> wrote:
>> ... majority do not NFS export /usr/local ...
> Sorry, but that is not the issue. The attacked machine would not be
> an exporter, but a mounter of user files.
Umm. The exporter is the one that got attacked, since it has
the data. every other user that mounts the file system is collateral
damage.
> Suppose I have a bunch of machines, that "share" user files: all
> NFS-mount /users (containing user home directories
> /users/*). Getting root on any one of this bunch of machines would
> allow me to create a setgid-staff file; or maybe I could mess around
> with the .bashrc of a user in group staff.
I think you did not bother to read my response, since I
explicitly stated that there is no reason to have /home writable by
user staff.
> Arguments about exports with squash_gids are moot: many NFS
> exporters do not have that option; and non-Debian exporters would
> not know or care about group staff.
Umm, non-debian exporters are not covered by policy, and thus
we do not care about them. And since this is not a client side thing
at all, this line of argument is just noise.
I do not see this email in any way pointing to a valid flaw in
my summary.
manoj
--
"The most formidable weapon against errors of every kind is reason."
Thomas Paine, _The Age of Reason_
Manoj Srivastava <email address hidden> <http://
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#56 |
On Sun, Mar 20, 2005 at 11:21:07AM +1100, <email address hidden> wrote:
>[...] I wonder about group tty.
Group tty exists to support write(1), wall(1) and similar. Terminals
are writable by group tty when mesg is "y" (default for non-root users).
--bod
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #57 |
Message-ID: <email address hidden>
Date: Mon, 21 Mar 2005 04:25:19 +1100
From: Brendan O'Dea <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
On Sun, Mar 20, 2005 at 11:21:07AM +1100, <email address hidden> wrote:
>[...] I wonder about group tty.
Group tty exists to support write(1), wall(1) and similar. Terminals
are writable by group tty when mesg is "y" (default for non-root users).
--bod
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#58 |
Manoj Srivastava <email address hidden> wrote:
>> Sorry, but that is not the issue. The attacked machine would not be
>> an exporter, but a mounter of user files.
>
> Umm. The exporter is the one that got attacked, since it has
> the data. every other user that mounts the file system is collateral
> damage.
As far as the exporter is concerned, the creation of a setgid-staff object
may be perfectly legitimate: it may have group staff == GID 50 as a
"normal" user group; it may not have any "local" users or user access; it
may have the exported tree contained within a filesystem mounted nosuid.
(The exporter may be a NetworkAttached
understanding of users or groups, and without an attackable operating
system.) The exporter is protected against root attacks by its use of
root_squash. It is the "collateral damage" on the mounters, through the
root-equivalence of group staff, that is a root attack.
It is the responsibility of (the manager of) the mounter machine to protect
its (own) security, regardless of any attacks on other mounters on on the
exporter.
>> Suppose I have a bunch of machines, that "share" user files: all
>> NFS-mount /users (containing user home directories
>> /users/*). Getting root on any one of this bunch of machines would
>> allow me to create a setgid-staff file; or maybe I could mess around
>> with the .bashrc of a user in group staff.
>
> I think you did not bother to read my response, since I
> explicitly stated that there is no reason to have /home writable by
> user staff.
I used the name /users, not /home; whether either is group-staff-
is irrelevant.
In my example, I properly and legitimately own /users/psz. If I can "get"
group staff on one machine (e.g. because I "got root" there) then I can
create a setgid-staff file /users/psz/attack and "get root" on any other
Debian mounters.
(In my humble opinion having /home group-staff-
useless, Bill's /home/debs example notwithstanding; but I agree that it is
not a security risk. I only ever mentioned /home because it features in the
justification for the existence of group staff. As far as I see, /home is
not mentioned in the policy.)
>> Arguments about exports with squash_gids are moot: many NFS
>> exporters do not have that option; and non-Debian exporters would
>> not know or care about group staff.
>
> Umm, non-debian exporters are not covered by policy, and thus
> we do not care about them. And since this is not a client side thing
> at all, this line of argument is just noise.
We only care about Debian machines, and want to protect those that mount
user-writable files.
> I do not see this email in any way pointing to a valid flaw in
> my summary.
OK, let us analyze it in detail. You wrote:
>>> Synopsis:
>>>
>>> Make squash_gids be a default for the NFS server, make /home
>>> not be writable by group staff, leave /usr/local alone.
Though nfs-user-server may "know" about the squash_gids option,
nfs-kernel-server does not.
Group-staff-
Your suggestions do not protect against the attack.
>>> =======
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#59 |
>>[...] I wonder about group tty.
>
> Group tty exists to support write(1), wall(1) and similar. Terminals
> are writable by group tty when mesg is "y" (default for non-root users).
We have write(1) and wall(1) setgid tty (and not setuid root) because we do
not trust them. Should audit the sources, then could have them setuid root
and do away with group tty.
What mischief can be done by getting group tty? Could we do only what
write(1) does, or could we insert keystrokes into someone's terminal and so
execute arbitrary code?
Much of UNIX is designed on the idea that it is difficult to "get" another
user or group. The use of NFS (for any files, for user files, and in
particular for user home directories) blows away some of that difficulty,
relying on the exporter to keep things safe. That is why most (all??)
exporters use the root_squash option; but become-
become-
local machine) cannot fully protect users; but must still protect root.
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #60 |
Message-Id: <email address hidden>
Date: Mon, 21 Mar 2005 06:55:58 +1100
From: <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
Manoj Srivastava <email address hidden> wrote:
>> Sorry, but that is not the issue. The attacked machine would not be
>> an exporter, but a mounter of user files.
>
> Umm. The exporter is the one that got attacked, since it has
> the data. every other user that mounts the file system is collateral
> damage.
As far as the exporter is concerned, the creation of a setgid-staff object
may be perfectly legitimate: it may have group staff == GID 50 as a
"normal" user group; it may not have any "local" users or user access; it
may have the exported tree contained within a filesystem mounted nosuid.
(The exporter may be a NetworkAttached
understanding of users or groups, and without an attackable operating
system.) The exporter is protected against root attacks by its use of
root_squash. It is the "collateral damage" on the mounters, through the
root-equivalence of group staff, that is a root attack.
It is the responsibility of (the manager of) the mounter machine to protect
its (own) security, regardless of any attacks on other mounters on on the
exporter.
>> Suppose I have a bunch of machines, that "share" user files: all
>> NFS-mount /users (containing user home directories
>> /users/*). Getting root on any one of this bunch of machines would
>> allow me to create a setgid-staff file; or maybe I could mess around
>> with the .bashrc of a user in group staff.
>
> I think you did not bother to read my response, since I
> explicitly stated that there is no reason to have /home writable by
> user staff.
I used the name /users, not /home; whether either is group-staff-
is irrelevant.
In my example, I properly and legitimately own /users/psz. If I can "get"
group staff on one machine (e.g. because I "got root" there) then I can
create a setgid-staff file /users/psz/attack and "get root" on any other
Debian mounters.
(In my humble opinion having /home group-staff-
useless, Bill's /home/debs example notwithstanding; but I agree that it is
not a security risk. I only ever mentioned /home because it features in the
justification for the existence of group staff. As far as I see, /home is
not mentioned in the policy.)
>> Arguments about exports with squash_gids are moot: many NFS
>> exporters do not have that option; and non-Debian exporters would
>> not know or care about group staff.
>
> Umm, non-debian exporters are not covered by policy, and thus
> we do not care about them. And since this is not a client side thing
> at all, this line of argument is just noise.
We only care about Debian machines, and want to protect those that mount
user-writable files.
> I do not see this email in any way pointing to a valid flaw in
> my summary.
OK, let us analyze it in detail. You wrote:
>>> Synopsis:
>>>
>>> Make squash_gids be a default for the NFS server, make /home
>>> not be writable by group staff, leave /usr/local alone.
Though nfs-user-server may "kn...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #61 |
Message-Id: <email address hidden>
Date: Mon, 21 Mar 2005 07:11:52 +1100
From: <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
>>[...] I wonder about group tty.
>
> Group tty exists to support write(1), wall(1) and similar. Terminals
> are writable by group tty when mesg is "y" (default for non-root users).
We have write(1) and wall(1) setgid tty (and not setuid root) because we do
not trust them. Should audit the sources, then could have them setuid root
and do away with group tty.
What mischief can be done by getting group tty? Could we do only what
write(1) does, or could we insert keystrokes into someone's terminal and so
execute arbitrary code?
Much of UNIX is designed on the idea that it is difficult to "get" another
user or group. The use of NFS (for any files, for user files, and in
particular for user home directories) blows away some of that difficulty,
relying on the exporter to keep things safe. That is why most (all??)
exporters use the root_squash option; but become-
become-
local machine) cannot fully protect users; but must still protect root.
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#62 |
A little while ago I wrote:
> (A partial solution would be to mount nosuid. Another part would require a
> squash-gid-on-mount option: mount has no such options for NFS, though has
> similar options for some other filesystems; there are also uid/gid mapping
> options for NFS exports.)
Re-reading, I see it makes no sense (I do not know what I was thinking at
the time). Mounting nosuid may be sensible (but suid is often wanted);
there is no protection against users (including those in group staff) being
trojaned e.g. via their .bashrc files.
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #63 |
Message-Id: <email address hidden>
Date: Mon, 21 Mar 2005 09:12:14 +1100
From: <email address hidden>
To: <email address hidden>, <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
A little while ago I wrote:
> (A partial solution would be to mount nosuid. Another part would require a
> squash-gid-on-mount option: mount has no such options for NFS, though has
> similar options for some other filesystems; there are also uid/gid mapping
> options for NFS exports.)
Re-reading, I see it makes no sense (I do not know what I was thinking at
the time). Mounting nosuid may be sensible (but suid is often wanted);
there is no protection against users (including those in group staff) being
trojaned e.g. via their .bashrc files.
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#64 |
A while ago I wrote:
> 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.
Could this be done, please, while we discuss (argue?) resolution?
Thanks,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #65 |
Message-Id: <email address hidden>
Date: Tue, 22 Mar 2005 08:32:36 +1100
From: <email address hidden>
To: <email address hidden>, <email address hidden>, <email address hidden>,
<email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
A while ago I wrote:
> 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.
Could this be done, please, while we discuss (argue?) resolution?
Thanks,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#66 |
On Tue, 22 Mar 2005 08:32:36 +1100, psz <email address hidden> said:
> A while ago I wrote:
>> 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.
> Could this be done, please, while we discuss (argue?) resolution?
No, I think that would be far overstating the facts.
manoj
--
"Come on over here, baby, I want to do a thing with you." A cop,
arresting a non-groovy person after the revolution, Firesign Theater
Manoj Srivastava <email address hidden> <http://
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#67 |
On Mon, Mar 21, 2005 at 06:55:58AM +1100, <email address hidden> wrote:
> Manoj Srivastava <email address hidden> wrote:
> Though nfs-user-server may "know" about the squash_gids option,
> nfs-kernel-server does not.
You can emulate squash_gids using the ugidd daemon. Just map staff to
nogroup.
In fact, most of your problems can be solved with use of ugidd, and this
is not Debian specific.
Cheers,
--
Bill. <email address hidden>
Imagine a large red swirl here.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #68 |
Message-ID: <email address hidden>
Date: Mon, 21 Mar 2005 16:41:05 -0600
From: Manoj Srivastava <<email address hidden> (va, manoj)>
To: <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
On Tue, 22 Mar 2005 08:32:36 +1100, psz <email address hidden> said:
> A while ago I wrote:
>> 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.
> Could this be done, please, while we discuss (argue?) resolution?
No, I think that would be far overstating the facts.
manoj
--
"Come on over here, baby, I want to do a thing with you." A cop,
arresting a non-groovy person after the revolution, Firesign Theater
Manoj Srivastava <email address hidden> <http://
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #69 |
Message-ID: <20050321225555
Date: Mon, 21 Mar 2005 23:55:55 +0100
From: Bill Allombert <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
On Mon, Mar 21, 2005 at 06:55:58AM +1100, <email address hidden> wrote:
> Manoj Srivastava <email address hidden> wrote:
> Though nfs-user-server may "know" about the squash_gids option,
> nfs-kernel-server does not.
You can emulate squash_gids using the ugidd daemon. Just map staff to
nogroup.
In fact, most of your problems can be solved with use of ugidd, and this
is not Debian specific.
Cheers,
--
Bill. <email address hidden>
Imagine a large red swirl here.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#70 |
Bill,
>> Though nfs-user-server may "know" about the squash_gids option,
>> nfs-kernel-server does not.
>
> You can emulate squash_gids using the ugidd daemon. Just map staff to
> nogroup.
>
> In fact, most of your problems can be solved with use of ugidd, and this
> is not Debian specific.
Using squash_gids or ugidd would prevent an attacker from creating a
setgid-staff object, thus keeping things safe while there are no users in
group staff. Neither squash_gids nor ugidd would prevent scribbling over
the .bashrc file of, or otherwise trojan, a user in group staff.
I beleive that group staff is pretty useless until you put some users into
that group. Using squash_gids or ugidd we can keep it safe in that default
but useless state; we can not make it safe in the useful state.
Would you agree with the above? (Then we should think about groups disk and
tty also.)
(The problem is not Debian-specific. Only the policy is; am not sure if
other distibutions even have a policy.)
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #71 |
Message-Id: <email address hidden>
Date: Tue, 22 Mar 2005 12:56:28 +1100
From: <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
Bill,
>> Though nfs-user-server may "know" about the squash_gids option,
>> nfs-kernel-server does not.
>
> You can emulate squash_gids using the ugidd daemon. Just map staff to
> nogroup.
>
> In fact, most of your problems can be solved with use of ugidd, and this
> is not Debian specific.
Using squash_gids or ugidd would prevent an attacker from creating a
setgid-staff object, thus keeping things safe while there are no users in
group staff. Neither squash_gids nor ugidd would prevent scribbling over
the .bashrc file of, or otherwise trojan, a user in group staff.
I beleive that group staff is pretty useless until you put some users into
that group. Using squash_gids or ugidd we can keep it safe in that default
but useless state; we can not make it safe in the useful state.
Would you agree with the above? (Then we should think about groups disk and
tty also.)
(The problem is not Debian-specific. Only the policy is; am not sure if
other distibutions even have a policy.)
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#72 |
> 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.
>>
>> Could this be done, please, while we discuss (argue?) resolution?
>
> No, I think that would be far overstating the facts.
Are you sure there are no security issues, and absolutely sure there are no
root security holes, lurking in there?
I am tempted to publicize the issue on the BugTraq and FullDisclosure
mailing lists. Maybe I am wrong, and will suffer the humiliation of being
laughed at; or maybe I am right ...
(I know Matt thinks bugs.debian is public already, but it is quite obscure;
so the general public, Debian users, and other Linux/UNIX maintainers may
still be in the dark.)
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#73 |
On Tue, Mar 22, 2005 at 02:37:14PM +1100, <email address hidden> wrote:
> > 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.
> >>
> >> Could this be done, please, while we discuss (argue?) resolution?
> >
> > No, I think that would be far overstating the facts.
>
> Are you sure there are no security issues, and absolutely sure there are no
> root security holes, lurking in there?
>
> I am tempted to publicize the issue on the BugTraq and FullDisclosure
> mailing lists. Maybe I am wrong, and will suffer the humiliation of being
> laughed at; or maybe I am right ...
>
> (I know Matt thinks bugs.debian is public already, but it is quite obscure;
> so the general public, Debian users, and other Linux/UNIX maintainers may
> still be in the dark.)
I've already stated my position on the bug, and I think that this use of the
staff group should be avoided.
The fact, though, is that this is a privilege escalation from the
(documented, but essentially unused) 'staff' group to root. Similar
escalations exist commonly in other systems via, e.g., the 'bin' user/group
which owns binaries in the default PATH. The "kmem" group also leads
trivially to root. But unless the system administrator takes it upon
themselves to give these privileges away, there is no realistic attack
vector, and no justification for alarm.
--
- mdz
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #74 |
Message-Id: <email address hidden>
Date: Tue, 22 Mar 2005 14:37:14 +1100
From: <email address hidden>
To: <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
> 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.
>>
>> Could this be done, please, while we discuss (argue?) resolution?
>
> No, I think that would be far overstating the facts.
Are you sure there are no security issues, and absolutely sure there are no
root security holes, lurking in there?
I am tempted to publicize the issue on the BugTraq and FullDisclosure
mailing lists. Maybe I am wrong, and will suffer the humiliation of being
laughed at; or maybe I am right ...
(I know Matt thinks bugs.debian is public already, but it is quite obscure;
so the general public, Debian users, and other Linux/UNIX maintainers may
still be in the dark.)
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#75 |
Matt Zimmerman <email address hidden> wrote:
> The fact, though, is that this is a privilege escalation from the
> (documented, but essentially unused) 'staff' group to root. Similar
> escalations exist commonly in other systems via, e.g., the 'bin' user/group
> which owns binaries in the default PATH. The "kmem" group also leads
> trivially to root.
On my Debian systems, I see:
psz@pisa:~$ ls -l /dev | grep mem
crw-r----- 1 root kmem 1, 2 Nov 13 2002 kmem
crw-r----- 1 root kmem 1, 1 Nov 13 2002 mem
crw-r----- 1 root kmem 1, 4 Nov 13 2002 port
with read access only. Does that still give you root, or did you (also)
mean that for other systems, where kmem has write access?
Debian policy says that files should be owned by root:root (as distinct
from bin:bin). Was not that designed to avoid such escalation?
> But unless the system administrator takes it upon themselves to give
> these privileges away, there is no realistic attack vector, and no
> justification for alarm.
NFS-mounted (user) files, mounted writable on several machines; attacker
gets root on one machine, creates setgid-staff binary, gets root on all.
Is not that realistic?
Should not administrators be warned that giving staff privilege is
equivalent to root? Are not they being misled into thinking that staff is
somehow less dangerous?
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #76 |
Message-ID: <email address hidden>
Date: Mon, 21 Mar 2005 19:57:00 -0800
From: Matt Zimmerman <email address hidden>
To: <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
On Tue, Mar 22, 2005 at 02:37:14PM +1100, <email address hidden> wrote:
> > 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.
> >>
> >> Could this be done, please, while we discuss (argue?) resolution?
> >
> > No, I think that would be far overstating the facts.
>
> Are you sure there are no security issues, and absolutely sure there are no
> root security holes, lurking in there?
>
> I am tempted to publicize the issue on the BugTraq and FullDisclosure
> mailing lists. Maybe I am wrong, and will suffer the humiliation of being
> laughed at; or maybe I am right ...
>
> (I know Matt thinks bugs.debian is public already, but it is quite obscure;
> so the general public, Debian users, and other Linux/UNIX maintainers may
> still be in the dark.)
I've already stated my position on the bug, and I think that this use of the
staff group should be avoided.
The fact, though, is that this is a privilege escalation from the
(documented, but essentially unused) 'staff' group to root. Similar
escalations exist commonly in other systems via, e.g., the 'bin' user/group
which owns binaries in the default PATH. The "kmem" group also leads
trivially to root. But unless the system administrator takes it upon
themselves to give these privileges away, there is no realistic attack
vector, and no justification for alarm.
--
- mdz
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#77 |
On Tue, Mar 22, 2005 at 03:29:10PM +1100, <email address hidden> wrote:
> On my Debian systems, I see:
>
> psz@pisa:~$ ls -l /dev | grep mem
> crw-r----- 1 root kmem 1, 2 Nov 13 2002 kmem
> crw-r----- 1 root kmem 1, 1 Nov 13 2002 mem
> crw-r----- 1 root kmem 1, 4 Nov 13 2002 port
>
> with read access only. Does that still give you root, or did you (also)
> mean that for other systems, where kmem has write access?
Read-only access to kernel memory should be sufficient to obtain passwords,
including the root password or the password of a root-equivalent user.
> NFS-mounted (user) files, mounted writable on several machines; attacker
> gets root on one machine, creates setgid-staff binary, gets root on all.
> Is not that realistic?
Attacker gets root on one machine, creates setuid root binary, gets root on
all.
> Should not administrators be warned that giving staff privilege is
> equivalent to root? Are not they being misled into thinking that staff is
> somehow less dangerous?
I have already said that I support the removal of these privileges from the
staff group; we do not disagree on this point.
--
- mdz
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#78 |
On Mon, 21 Mar 2005 19:57:00 -0800, Matt Zimmerman <email address hidden> said:
> I've already stated my position on the bug, and I think that this
> use of the staff group should be avoided.
> The fact, though, is that this is a privilege escalation from the
> (documented, but essentially unused) 'staff' group to root.
This is true. But while there is no hard separation, the
privileges granted to group staff are not coincident to the
privileges granted to the super user; though there is an overlap that
can lead to escalation.
While you can't use group staff to create a second teir group
of humans with some, but not all, rights of the group who has root
privileges, you can use to allow people who already have the root
password to perform some tasks while they are not root.
While in a role as group staff, some of the consequences of
actions taken in error (rm -rf $workdir, when -z $workdir, for
example) do not have the consequences that they would ahve were they
forced to work as the super suer. This overlapping, but not
coincident, set of privileges are what makes the group staff useful.
There are all kinds of tools in the admins arsenal, each with
varying degrees of risk; forcing the admin to run as root all the
time reduces, rather than enhances, system security.
> Similar escalations exist commonly in other systems via, e.g., the
> 'bin' user/group which owns binaries in the default PATH. The
> "kmem" group also leads trivially to root. But unless the system
> administrator takes it upon themselves to give these privileges
> away, there is no realistic attack vector, and no justification for
> alarm.
Even more directly, sudo and super can be set up to allow
trivial privilege escalations (I mean, that is their _job_). There
are all kinds of tools and mechanisms that can be set up badly; but
that does not mean that we should ban them out of hand.
manoj
--
Marxist Law of Distribution of Wealth: Shortages will be divided
equally among the peasants.
Manoj Srivastava <email address hidden> <http://
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#79 |
Matt,
>> On my Debian systems, I see:
>> crw-r----- 1 root kmem 1, 2 Nov 13 2002 kmem
>> with read access only. Does that still give you root ...
>
> Read-only access to kernel memory should be sufficient to obtain passwords,
> including the root password or the password of a root-equivalent user.
Thanks. (Somewhat cumbersome; but you are right.)
>> NFS-mounted (user) files, mounted writable on several machines; attacker
>> gets root on one machine, creates setgid-staff binary, gets root on all.
>> Is not that realistic?
>
> Attacker gets root on one machine, creates setuid root binary, gets root on
> all.
Cannot create setuid-root: the filesystem is exported with default
root_squash. Would need to get root on the exporter for that. In my
scenario getting root on any mounter is sufficient.
(I started to think of this, because my boss suggested that we set a
different root password on the exporter, as needing more security than the
various mounters. Most admins would recognize the need to secure the
exporter, but may not realize that root on the mounter also gives it away.)
>> Should not administrators be warned that giving staff privilege is
>> equivalent to root? Are not they being misled into thinking that staff is
>> somehow less dangerous?
>
> I have already said that I support the removal of these privileges from the
> staff group; we do not disagree on this point.
Yes I noticed your agreement, thanks, and thanks for re-stating it. We seem
to disagree on the urgency only: are there any machines that are currently
affected?
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #80 |
Message-Id: <email address hidden>
Date: Tue, 22 Mar 2005 15:29:10 +1100
From: <email address hidden>
To: <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
Matt Zimmerman <email address hidden> wrote:
> The fact, though, is that this is a privilege escalation from the
> (documented, but essentially unused) 'staff' group to root. Similar
> escalations exist commonly in other systems via, e.g., the 'bin' user/group
> which owns binaries in the default PATH. The "kmem" group also leads
> trivially to root.
On my Debian systems, I see:
psz@pisa:~$ ls -l /dev | grep mem
crw-r----- 1 root kmem 1, 2 Nov 13 2002 kmem
crw-r----- 1 root kmem 1, 1 Nov 13 2002 mem
crw-r----- 1 root kmem 1, 4 Nov 13 2002 port
with read access only. Does that still give you root, or did you (also)
mean that for other systems, where kmem has write access?
Debian policy says that files should be owned by root:root (as distinct
from bin:bin). Was not that designed to avoid such escalation?
> But unless the system administrator takes it upon themselves to give
> these privileges away, there is no realistic attack vector, and no
> justification for alarm.
NFS-mounted (user) files, mounted writable on several machines; attacker
gets root on one machine, creates setgid-staff binary, gets root on all.
Is not that realistic?
Should not administrators be warned that giving staff privilege is
equivalent to root? Are not they being misled into thinking that staff is
somehow less dangerous?
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #81 |
Message-ID: <email address hidden>
Date: Mon, 21 Mar 2005 20:36:15 -0800
From: Matt Zimmerman <email address hidden>
To: <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
On Tue, Mar 22, 2005 at 03:29:10PM +1100, <email address hidden> wrote:
> On my Debian systems, I see:
>
> psz@pisa:~$ ls -l /dev | grep mem
> crw-r----- 1 root kmem 1, 2 Nov 13 2002 kmem
> crw-r----- 1 root kmem 1, 1 Nov 13 2002 mem
> crw-r----- 1 root kmem 1, 4 Nov 13 2002 port
>
> with read access only. Does that still give you root, or did you (also)
> mean that for other systems, where kmem has write access?
Read-only access to kernel memory should be sufficient to obtain passwords,
including the root password or the password of a root-equivalent user.
> NFS-mounted (user) files, mounted writable on several machines; attacker
> gets root on one machine, creates setgid-staff binary, gets root on all.
> Is not that realistic?
Attacker gets root on one machine, creates setuid root binary, gets root on
all.
> Should not administrators be warned that giving staff privilege is
> equivalent to root? Are not they being misled into thinking that staff is
> somehow less dangerous?
I have already said that I support the removal of these privileges from the
staff group; we do not disagree on this point.
--
- mdz
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #82 |
Message-ID: <email address hidden>
Date: Mon, 21 Mar 2005 22:46:27 -0600
From: Manoj Srivastava <<email address hidden> (va, manoj)>
To: <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
On Mon, 21 Mar 2005 19:57:00 -0800, Matt Zimmerman <email address hidden> said:
> I've already stated my position on the bug, and I think that this
> use of the staff group should be avoided.
> The fact, though, is that this is a privilege escalation from the
> (documented, but essentially unused) 'staff' group to root.
This is true. But while there is no hard separation, the
privileges granted to group staff are not coincident to the
privileges granted to the super user; though there is an overlap that
can lead to escalation.
While you can't use group staff to create a second teir group
of humans with some, but not all, rights of the group who has root
privileges, you can use to allow people who already have the root
password to perform some tasks while they are not root.
While in a role as group staff, some of the consequences of
actions taken in error (rm -rf $workdir, when -z $workdir, for
example) do not have the consequences that they would ahve were they
forced to work as the super suer. This overlapping, but not
coincident, set of privileges are what makes the group staff useful.
There are all kinds of tools in the admins arsenal, each with
varying degrees of risk; forcing the admin to run as root all the
time reduces, rather than enhances, system security.
> Similar escalations exist commonly in other systems via, e.g., the
> 'bin' user/group which owns binaries in the default PATH. The
> "kmem" group also leads trivially to root. But unless the system
> administrator takes it upon themselves to give these privileges
> away, there is no realistic attack vector, and no justification for
> alarm.
Even more directly, sudo and super can be set up to allow
trivial privilege escalations (I mean, that is their _job_). There
are all kinds of tools and mechanisms that can be set up badly; but
that does not mean that we should ban them out of hand.
manoj
--
Marxist Law of Distribution of Wealth: Shortages will be divided
equally among the peasants.
Manoj Srivastava <email address hidden> <http://
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #83 |
Message-Id: <email address hidden>
Date: Tue, 22 Mar 2005 15:57:35 +1100
From: <email address hidden>
To: <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
Matt,
>> On my Debian systems, I see:
>> crw-r----- 1 root kmem 1, 2 Nov 13 2002 kmem
>> with read access only. Does that still give you root ...
>
> Read-only access to kernel memory should be sufficient to obtain passwords,
> including the root password or the password of a root-equivalent user.
Thanks. (Somewhat cumbersome; but you are right.)
>> NFS-mounted (user) files, mounted writable on several machines; attacker
>> gets root on one machine, creates setgid-staff binary, gets root on all.
>> Is not that realistic?
>
> Attacker gets root on one machine, creates setuid root binary, gets root on
> all.
Cannot create setuid-root: the filesystem is exported with default
root_squash. Would need to get root on the exporter for that. In my
scenario getting root on any mounter is sufficient.
(I started to think of this, because my boss suggested that we set a
different root password on the exporter, as needing more security than the
various mounters. Most admins would recognize the need to secure the
exporter, but may not realize that root on the mounter also gives it away.)
>> Should not administrators be warned that giving staff privilege is
>> equivalent to root? Are not they being misled into thinking that staff is
>> somehow less dangerous?
>
> I have already said that I support the removal of these privileges from the
> staff group; we do not disagree on this point.
Yes I noticed your agreement, thanks, and thanks for re-stating it. We seem
to disagree on the urgency only: are there any machines that are currently
affected?
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#84 |
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?
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.
Should you wish to retain the feature, you must document the risk
associated with it.
Is it documented anywhere that you should only give group staff
privileges to those that also have the root password?
> While in a role as group staff, some of the consequences of
> actions taken in error ...
You need to train admins to be careful. You should train them to use
"rm -i" e.g. via aliases. With power comes responsibility. How is it
acceptable to not be protected against "rm -rf /home/userdir"? (Is rm
the only dangerous command?)
> ... forcing the admin to run as root all the
> time reduces, rather than enhances, system security.
Accepting that statement, is not "forcing" your admin to run as group
staff all the time, also bad? Good admins do most things as their mortal
selves, and only do the "rootly" things as root: su or login when really
needed. Then at least they get a distinction between their powerless
and powerful states; being in group staff you have the power all the
time, and cannot give it up.
Security is mostly about protecting from malice, not about protecting
from shoot-yourself-
foolproof, because fools are quite inventive.)
> ... sudo and super can be set up to allow trivial privilege
> escalations ... all kinds of tools and mechanisms that can be set up
> badly; but that does not mean that we should ban them out of hand.
Should make a distinction between what *can* be set up badly, and what
*is by default* bad. We ban bad-by-default things; we warn against
common or easy-to-
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 understand
that you may wish to retain your group staff feature and privileges:
your machine, your right to run it any way you like; its (in)security is
your responsibility alone. 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.
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #85 |
Message-Id: <email address hidden>
Date: Tue, 22 Mar 2005 21:20:41 +1100
From: <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH
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?
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.
Should you wish to retain the feature, you must document the risk
associated with it.
Is it documented anywhere that you should only give group staff
privileges to those that also have the root password?
> While in a role as group staff, some of the consequences of
> actions taken in error ...
You need to train admins to be careful. You should train them to use
"rm -i" e.g. via aliases. With power comes responsibility. How is it
acceptable to not be protected against "rm -rf /home/userdir"? (Is rm
the only dangerous command?)
> ... forcing the admin to run as root all the
> time reduces, rather than enhances, system security.
Accepting that statement, is not "forcing" your admin to run as group
staff all the time, also bad? Good admins do most things as their mortal
selves, and only do the "rootly" things as root: su or login when really
needed. Then at least they get a distinction between their powerless
and powerful states; being in group staff you have the power all the
time, and cannot give it up.
Security is mostly about protecting from malice, not about protecting
from shoot-yourself-
foolproof, because fools are quite inventive.)
> ... sudo and super can be set up to allow trivial privilege
> escalations ... all kinds of tools and mechanisms that can be set up
> badly; but that does not mean that we should ban them out of hand.
Should make a distinction between what *can* be set up badly, and what
*is by default* bad. We ban bad-by-default things; we warn against
common or easy-to-
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 understand
that you may wish to retain your group staff feature and privileges:
your machine, your right to run it any way you like; its (in)security is
your responsibility alone. 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.
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and S...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#86 |
severity 299007 critical
justification root security hole
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#87 |
severity 299007 wishlist
thanks
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #88 |
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
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#89 |
I have now sent the following to the BugTraq and FullDisclosure mailing
lists, see e.g.
http://
http://
Cheers,
Paul Szabo <email address hidden> http://
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-
> 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://
>
> Cheers,
>
> Paul Szabo <email address hidden> http://
> School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #90 |
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://
http://
Cheers,
Paul Szabo <email address hidden> http://
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-
> 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://
>
> Cheers,
>
> Paul Szabo <email address hidden> http://
> School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #91 |
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
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#92 |
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-
small, just about possible in some setups, root-later-
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
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #93 |
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-
small, just about possible in some setups, root-later-
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
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#94 |
Some Googling turned up the following:
http://
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://
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://
Root's path should consist of 'PATH= /bin'
That's it. Nothing else on root's path.
http://
{ print "Root path directory " $10 " is group writable." }
http://
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:/
http://
One important thing to keep in mind are the different $PATH settings for
users and root:
* user: /usr/local/
* root: /sbin:/
http://
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://
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://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #95 |
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://
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://
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://
Root's path should consist of 'PATH= /bin'
That's it. Nothing else on root's path.
http://
{ print "Root path directory " $10 " is group writable." }
http://
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:/
http://
One important thing to keep in mind are the different $PATH settings for
users and root:
* user: /usr/local/
* root: /sbin:/
http://
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://
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://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#96 |
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://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #97 |
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://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#98 |
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/
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/
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #99 |
Message-ID: <20050324091901
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/
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/
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#100 |
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://
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://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #101 |
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://
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://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#102 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #103 |
Message-ID: <20050324205151
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#104 |
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-
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 on the NFS server.
Thus once any such exploit occurs on an NFS system, the
individual group staff/bin/
permissions are the least of your worries: The network has
become completely taken over and al...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#105 |
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://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #106 |
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-
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 ...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #107 |
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://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#108 |
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 abused to gain root almost immediately:
root, daemon, sys, adm, disk, kmem, tape, sudo,
dip, backup, operator, shadow, video
These can probably be abused to gain root only by waiting for
something to happen (like roo...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #109 |
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...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#110 |
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://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #111 |
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://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#112 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#113 |
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://
[4] http://
[5] http://
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://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #114 |
Message-ID: <20050330232605
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #115 |
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://
[4] http://
[5] http://
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://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#116 |
Joey Hess <email address hidden> wrote:
>> ... really dumb idea to have a group/world-
>> 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:
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://
> [2] http://
(please see http://
> (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://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #117 |
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-
>> 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:
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://
> [2] http://
(please see http://
> (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://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#118 |
severity 267142 wishlist
retitle 267142 [DISCUSS] Sections 10.4 and 6.1 are inconsistent
severity 314808 wishlist
retitle 314808 [DISCUSS] Incorrect directory for web applications.
severity 331532 wishlist
retitle 331532[DISCUSS] change §10.4 "set -e OR check return status" to AND or be rewritten
tags 99933 -patch
tags 122817 -patch
tags 143941 -patch
tags 164474 -patch
tags 181123 -patch
tags 208010 -patch
tags 208011 -patch
tags 291148 -patch
tags 299007 -patch
tags 348336 -patch
--
"It's like deja vu all over again." -- Yogi Berra
Manoj Srivastava <email address hidden> <http://
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#119 |
Please see also
http://
http://
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#120 |
I note that Ubuntu has fixed this:
https:/
Cheers,
Paul Szabo <email address hidden> http://
School of Mathematics and Statistics University of Sydney Australia
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#121 |
# Setting up user categories for Policy bug triage and to help in the
# process. This uses the same classification scheme as mine adjusted by
# Manoj and previously discussed on the mailing list, with a few
# modifications so that the existing bug system tags can be used where
# possible:
#
# * Use patch for the wording tag so that a traditional view shows those.
# * Use pending for accepted, since they mean the same thing.
# * Use wontfix for rejected, likewise.
# * Sort by severity before issue-status instead of afterwards.
# * Don't sort by classification; issue-status supersedes it.
#
# We still sort by status first, which means that accepted and rejected
# bugs fall out of the main section into the bottom section.
user <email address hidden>
usercategory issue-type [hidden]
* Issue Type [tag=]
+ Normative [normative]
+ Informative [informative]
+ Packaging [packaging]
+ Unclassified []
usercategory issue-status [hidden]
* Issue Status [tag=]
+ Issue Raised [issue]
+ Under Discussion [discussion]
+ Opinion Solicited [opinion]
+ Change Proposed [proposal]
+ Wording Proposed [patch]
+ Wording Seconded [seconded]
+ Wording Accepted [pending]
+ Rejected [wontfix]
+ Unknown []
usercategory normal
* status
* issue-type
* severity
* issue-status
usercategory old
* status
* severity
* classification
package debian-policy
usertag 452393 informative issue
retitle 452393 Clarify difference between required and important priorities
tag 452393 -patch
usertag 163666 informative discussion
retitle 163666 Interpretation of [arch] is unclear with alternatives (|)
usertag 186102 informative discussion
retitle 186102 Suggest better date-based version numbers
usertag 175202 informative proposal
retitle 175202 Clarify Perl package naming convention with more examples
usertag 218897 informative proposal
retitle 218897 Explicitly say dpkg-divert --local is a bad idea in packages
usertag 328951 informative proposal
retitle 328951 Clarify relationship between targets and Build-Depends{
severity 328951 wishlist
usertag 442134 informative proposal
retitle 442134 Inconsistency: half-configured vs. failed-config
usertag 455602 informative
usertag 422552 informative
usertag 89038 normative issue
retitle 89038 [mime-policy] Include update-mime behavior
usertag 181123 normative issue
retitle 181123 Regulate init script behavior in unusual cases
usertag 120418 normative issue
retitle 120418 Policy for code using CPU extensions
usertag 122038 normative issue
retitle 122038 Use of /var/backups is apparently undocumented
usertag 161912 normative issue
retitle 161912 Drop 30000-59999 uid/gid reservation
usertag 186700 normative issue
retitle 186700 Sorting and meaning of an empty Debian revision is unclear
severity 186700 minor
usertag 192571 normative issue
retitle 192571 Size limit for doc packages
usertag 215549 normative issue
retitle 215549 reconfigure argument to postinst
usertag 263448 normative issue
retitle 263448 Separate font directory for non-free fonts
usertag 276160 normative issue
usertag 400322 normative issue
retitle 400322 Specify which dependency fields may be restricted by arch
usertag 40...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
# Automatically generated email from bts, devscripts version 2.10.18.1
user <email address hidden>
package debian-policy
usertags 452393 = informative issue
usertags 186102 = informative discussion
usertags 218897 = informative proposal
usertags 442134 = informative proposal
usertags 455602 = informative
usertags 181123 = normative issue
usertags 228692 = normative discussion
usertags 267142 = normative discussion
usertags 291177 = normative discussion
usertags 345619 = normative discussion
usertags 375502 = normative discussion
usertags 403649 = normative discussion
usertags 412668 = normative discussion
package debian-
retitle 447231 Python sub-policy
usertags 447231 = normative discussion
package debian-policy
usertags 457364 = normative discussion
usertags 99933 = normative proposal
usertags 184064 = normative proposal
usertags 224509 = normative proposal
usertags 392479 = normative proposal
usertags 411510 = normative proposal
usertags 425523 = normative proposal
usertags 172436 = normative
usertags 367984 = normative
usertags 442070 = normative
usertags 452105 = normative
usertags 403391 = normative
usertags 440420 = normative
usertags 430649 = normative
usertags 291460 = normative
usertags 431813 = normative
usertags 65577 = normative
usertags 209008 = normative
usertags 250202 = normative
usertags 379150 = normative
usertags 392362 = normative
usertags 99324 = normative
usertags 102213 = normative
usertags 122817 = normative
usertags 169600 = normative
usertags 203650 = normative
usertags 253511 = normative
usertags 284340 = normative
usertags 295006 = normative
usertags 299007 = normative
tags 299007 - security
usertags 331532 = normative
usertags 367650 = normative
usertags 381729 = normative
usertags 434651 = normative
usertags 435476 = normative
usertags 438492 = normative
Changed in base-files: | |
status: | New → Won't Fix |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#123 |
package debian-policy
user <email address hidden>
usertag 299007 ctte
thanks
This proposal asks that directories in /usr/local no longer be writable by
group staff.
There clearly was not consensus in this bug discussion for making this
change, but neither am I comfortable as a Policy delegate with simply
closing it, in part because those in favor of this change felt very
strongly about it and in part because Ubuntu has made a different decision
and implemented this change. Debian need not follow Ubuntu, but where
Ubuntu has decided to diverge, we should look at their rationale and
consider it seriously.
I'm therefore going to delegate this decision to the tech-ctte under
points 1 and 3 of section 6.1 of the Debian Constitution. I'm filing the
bug against tech-ctte now.
--
Russ Allbery (<email address hidden>) <http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#124 |
user <email address hidden>
package debian-policy
usertags 538392 normative discussion
forcemerge 538392 299007
usertags 299007 discussion
usertags 299007 - ctte
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#125 |
user <email address hidden>
package debian-policy
tags 299007 - wontfix
Changed in base-files (Debian): | |
status: | Won't Fix → New |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#126 |
package debian-policy
user <email address hidden>
usertag 541872 = normative issue
severity 541872 wishlist
severity 299007 wishlist
--
Praise the sea; on shore remain. John Florio
Manoj Srivastava <email address hidden> <http://
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Changed in base-files (Debian): | |
status: | New → Fix Committed |
Changed in base-files (Debian): | |
status: | Fix Committed → Fix Released |
Automatically imported from Debian bug report #299007 http:// bugs.debian. org/299007