On Thu, Aug 31, 2006 at 12:01:12PM +1000, Paul Szabo wrote:
>I note that Ubuntu has fixed this:
>
> https://launchpad.net/bugs/13795
I'm not familar with Launchpad, but I'm guessing that a status of
"Rejected" doesn't mean that the bug was fixed.
--bod
--
To UNSUBSCRIBE, email to [EMAIL PROTE
I note that Ubuntu has fixed this:
https://launchpad.net/bugs/13795
Cheers,
Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscr
Bill Allombert <[EMAIL PROTECTED]> 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",
On Thu, Mar 31, 2005 at 06:16:46AM +1000, [EMAIL PROTECTED] 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 juni
Jakob Bohm <[EMAIL PROTECTED]> 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 b
On Mon, Mar 28, 2005 at 05:19:30PM +1000, [EMAIL PROTECTED] wrote:
> Jakob Bohm <[EMAIL PROTECTED]> 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 ... 'almos
Jakob Bohm <[EMAIL PROTECTED]> 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
On Tue, Mar 22, 2005 at 09:20:41PM +1100, [EMAIL PROTECTED] wrote:
> Manoj Srivastava <[EMAIL PROTECTED]> 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 al
On Fri, Mar 25, 2005 at 06:37:14AM +1100, [EMAIL PROTECTED] 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 th
Bill,
Thank you for the explanations.
> One of the rules is that policy proposal are wishlist by definition.
Quite sensible: protect the policy-makers from blame and "litigation".
I guess that the couple of "normal" bugs listed under
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=debian-poli
[Sent to -policy just so people will know it's been responded to,
please respond privately, or if this is a general question, on
-mentors or -devel as appropriate.]
On Thu, 24 Mar 2005, [EMAIL PROTECTED] wrote:
> My question: are the public in general and bug submitters in
> particular, expected o
On Thu, Mar 24, 2005 at 07:11:18PM +1100, [EMAIL PROTECTED] wrote:
> Dear Debian BTS gurus,
>
> A day or so ago, in connection with another bug (#295435), I discovered
> the existence and use of [EMAIL PROTECTED] Out of curiosity, I
> tried to set the severity of this bug to critical; to my amazem
Dear Debian BTS gurus,
A day or so ago, in connection with another bug (#295435), I discovered
the existence and use of [EMAIL PROTECTED] 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
Some Googling turned up the following:
http://www.tldp.org/HOWTO/Path-12.html
Any of the important daemon processes should never execute anything that
some other user can write into. In some systems, /usr/local/bin is
allowed to contain programs with less strict security screening - it is
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
I have now sent the following to the BugTraq and FullDisclosure mailing
lists, see e.g.
http://www.securityfocus.com/archive/1/393997
http://lists.grok.org.uk/pipermail/full-disclosure/2005-March/032804.html
Cheers,
Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/
School of M
Processing commands for [EMAIL PROTECTED]:
> severity 299007 critical
Bug#299007: base-files: Insecure PATH in /root/.profile
Severity set to `critical'.
> justification root security hole
Unknown command or malformed arguments to command.
>
End of message, stopping processing
Manoj Srivastava <[EMAIL PROTECTED]> 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 the
On Mon, 21 Mar 2005 19:57:00 -0800, Matt Zimmerman <[EMAIL PROTECTED]> 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)
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
On Tue, Mar 22, 2005 at 03:29:10PM +1100, [EMAIL PROTECTED] wrote:
> On my Debian systems, I see:
>
> [EMAIL PROTECTED]:~$ 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
Matt Zimmerman <[EMAIL PROTECTED]> 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 PA
On Tue, Mar 22, 2005 at 02:37:14PM +1100, [EMAIL PROTECTED] 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 d
> 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
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.
Usi
On Mon, Mar 21, 2005 at 06:55:58AM +1100, [EMAIL PROTECTED] wrote:
> Manoj Srivastava <[EMAIL PROTECTED]> 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,
On Tue, 22 Mar 2005 08:32:36 +1100, psz <[EMAIL PROTECTED]> 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, pl
On Mon, 21 Mar 2005 06:55:58 +1100, psz <[EMAIL PROTECTED]> said:
> Manoj Srivastava <[EMAIL PROTECTED]> 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 ha
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
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 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 sourc
Manoj Srivastava <[EMAIL PROTECTED]> 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 colla
On Sun, Mar 20, 2005 at 11:21:07AM +1100, [EMAIL PROTECTED] 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
On Sun, 20 Mar 2005 11:21:07 +1100, psz <[EMAIL PROTECTED]> said:
> Brendan O'Dea <[EMAIL PROTECTED]> 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 PROTECTED]> wrote:
>> ... majori
Brendan O'Dea <[EMAIL PROTECTED]> 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 PROTECTED]> wrote:
> ... majority do not NFS export /usr/local ...
Sorry, but that is not the issue. The
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 defaul
On Sat, Mar 19, 2005 at 09:35:42PM +1100, [EMAIL PROTECTED] 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
Brendan O'Dea <[EMAIL PROTECTED]> 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-any-user-but-root and become-any-group-but-root bugs are quite
>
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 choosin
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 rem
Bill Allombert <[EMAIL PROTECTED]> 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
>>> sec
On Thu, Mar 17, 2005 at 07:25:56AM +1100, [EMAIL PROTECTED] wrote:
> Bill Allombert <[EMAIL PROTECTED]> 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 tha
Bill Allombert <[EMAIL PROTECTED]> 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
On Thu, Mar 17, 2005 at 05:43:19AM +1100, [EMAIL PROTECTED] wrote:
> "Brendan O'Dea" <[EMAIL PROTECTED]> wrote:
>
> > ... there's more at stake here than just PATH, since perl for example has
> > /usr/local/{lib,share}/perl earlier in @INC than /usr/{lib,share}/perl...
> >
> > I'm not sure what
"Brendan O'Dea" <[EMAIL PROTECTED]> wrote:
> ... there's more at stake here than just PATH, since perl for example has
> /usr/local/{lib,share}/perl earlier in @INC than /usr/{lib,share}/perl...
>
> I'm not sure what the emacs site-lisp search order is, but that may well
> provide a similar vect
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 complai
On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote:
>In this report, the submitter complains about /usr/local/bin being in
>the PATH by default at the same time directories under /usr/local are
>root:staff and world-writable. His complain is based on the existence
>of become-any-group-bu
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
On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote:
> In this report, the submitter complains about /usr/local/bin being in
> the PATH by default at the same time directories under /usr/local are
> root:staff and world-writable. His complain is based on the existence
> of become-any-grou
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 di
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 com
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
On Mar 11, Martin Pitt <[EMAIL PROTECTED]> 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
signature.asc
Description: Digital sig
On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote:
> In this report, the submitter complains about /usr/local/bin being in
> the PATH by default at the same time directories under /usr/local are
> root:staff and world-writable. His complain is based on the existence
> of become-any-grou
Hi!
Santiago Vila [2005-03-11 13:39 +0100]:
> In this report, the submitter complains about /usr/local/bin being in
> the PATH by default at the same time directories under /usr/local are
> root:staff and world-writable. His complain is based on the existence
> of become-any-group-but-root bugs.
>
In this report, the submitter complains about /usr/local/bin being in
the PATH by default at the same time directories under /usr/local are
root:staff and world-writable. His complain is based on the existence
of become-any-group-but-root bugs.
If this is a bug at all, I think we should probably d
Processing commands for [EMAIL PROTECTED]:
> severity 299007 wishlist
Bug#299007: base-files: Insecure PATH in /root/.profile
Severity set to `wishlist'.
> reassign 299007 debian-policy
Bug#299007: base-files: Insecure PATH in /root/.profile
Bug reassigned from package `base-files&
57 matches
Mail list logo
