Bug#299007: base-files: Insecure PATH
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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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 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 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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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 ... '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 root running a trojanized program): bin, tty, proxy, floppy, src, staff, console These apparently cannot generally be abused to gain root, but still allow violating some other aspect of security: lp, mail, news, uucp, dialout, fax, voice, cdrom, audio, majordom, postgress, www-data, msql, list, irc, gnats, utmp, games, qmail Only two groups are mostly impossible to abuse: users, nogroup Microsoft Windows/NT predefines several groups and assignable privileges and denies direct login is root, of those These can probably be abused to gain root almost immediately: Administrators, Domain Admins, Enterprise Admins, Scheme Admins, Power Users, Server Operators, Backup admins, Print Admins, Trusted Computing Base, Debug, Firmware, Back up Files, Restore Files, Add Workstations, Create Token, Load Driver, Take Ownership These can probably be used as part of more indirect attacks: Replicator, Audit, Security, Shutdown, Remote Shutdown, Change System Time, Create a Pagefile, Create Persistent Object, Quota, Login as Batch, Login as Service, Profile Any Process, Profile System, Set Process Token These are less dangerous: Guests, Users, Domain Users, Domain Guests, Login from Net, Login Locally, Bypass traverse checking, Lock Pages, Priority 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
Bug#299007: base-files: Insecure PATH
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 allow people who already have the root password to perform some tasks while they are not root. Is this feature seldom used, so we do not care much about it; or is it often used, and so possibly worth retaining? Well, I certainly use it. I also create multiple non-root accounts for people trusted to do 'root' things: A 'mortal' account for reading mail and other normal work and one or more 'almost root' accounts for doing things like manipulating /usr/local, installing software etc. Such an 'almost root' account may or may not be a member of group 'staff' (some are, some are not, depending on needs). In the default, unused state, it may be somewhat safe: it is not safe if you use NFS (in some common configurations). In the used state it is less safe: with or without NFS it may be possible to trojan the non-root staff user. Either way, the feature decreases security; this risk is not documented. I assert that in some common configurations the exposure is unacceptably high. All secure operating systems that I work with include various groups or similar that are subsets of root privileges with an acknowledged potential of abusive escalation to full root. Some go all the way and eliminate direct access to the root account entirely, for instance 'adduser' on such systems might by rwsr-x--- root admins or similar mechanisms. It is thus fundamental to the security of any modern system that the core OS infrastructure prevents 'become-trusted-group-bugs' as strongly as they prevent 'become root directly' as these are equivalent in the face of a competent, malicious attacker. For instance most Unix/POSIX filesystems prevent creation of sgid binaries (one of the example attack vectors mentioned) to people already in that group. All but the most lousy security systems prevent manipulation of other users files (another example attack vector) by anyone not authenticated to do so. The real, fundamental, security issue is that most implementations of the NFS protocol blindly assume that none of the client machines have had their local authentication systems compromised in any way. These broken-by-design NFS implementations are completely open to full attacks against any accounts or groups allowed access from the network. If just one machine on the network (with a trusted or spoofed IP address) makes it possible to send incorrect uids or gids to the NFS server, then that machine can be used to trojanize any and all user writable files, for any user. If home directories are NFS mounted by *other* machines, all users of those accounts can then be trojanized by changing the personal login scripts on the NFS server. Thus once any such exploit occurs on an NFS system, the individual group staff/bin/disk/admin/whatever memberships or permissions are the least of your worries: The network has become completely taken over and all systems should be given the 'root compromise' cleanup. 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? I think it is probably documented somewhere (and certainly basic os-independent sysadmin knowledge) that most systems include such groups and that any predefined group with either no members or only special accounts as members should be assumed to have this property, unless documented not to. ... 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. See my example above (creating multiple accounts for admin people, so they can get/drop staff membership with su-to-non-root or multiple login screens (Linux VTs come in very handy here)). Another option, found only on Unix/Linux systems is to assign a password to group staff in /etc/gshadow and then use newgrp(1) or sg(1) commands to get and give up group staff membership as needed. Security is mostly about protecting from malice, not about protecting from shoot-yourself-in-the-foot mistakes. (You cannot make things foolproof, because fools are quite inventive.) Agreed on the purpose of security, but not on not *also* using it to foolproof things or make attacks more difficult. Practical fool-proofing is about reducing accident probabilities not
Bug#299007: base-files: Insecure PATH
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 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 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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 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. My question: are the public in general and bug submitters in particular, expected or permitted to use [EMAIL PROTECTED] (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 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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH in /root/.profile
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 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 PROTECTED] Yes, they are. However we expect them to follow the rules. This bug is now assigned to the debian-policy package. One of the rules is that policy proposal are wishlist by definition. See the policy-process document: /usr/share/doc/debian-policy/policy-process.txt.gz 3.1. Initiating discussions ... Once the proposer is satisfied that the proposal has merit (with or without trying the waters on the list), the proposer should file a _wishlist_ bug against the debian-policy package. This stage can be initiated by any member of the list. Definition of severity can be found here: /usr/share/doc/debian/bug-maint-info.txt critical makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. In no way installing the debian-policy package introduce a security hole, causes serious data loss or makes unrelated software on the system break. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH in /root/.profile
Bill, Thank you for the explanations. One of the rules is that policy proposal are wishlist by definition. Quite sensible: protect the policy-makers from blame and litigation. I guess that the couple of normal bugs listed under http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=debian-policy never followed instructions and never set severity. In no way installing the debian-policy package introduce a security hole, causes serious data loss or makes unrelated software on the system break. Not the installation of the policy package, but the following of the policy, prevents base-files from being secure. Is not the policy at fault if it mandates insecure settings or actions? Cheers, Paul Szabo [EMAIL 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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH in /root/.profile
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 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 PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH in /root/.profile
Some Googling turned up the following:
http://www.tldp.org/HOWTO/Path-12.html
Any of the important daemon processes should never execute anything that
some other user can write into. In some systems, /usr/local/bin is
allowed to contain programs with less strict security screening - it is
just removed from the path of the root user.
http://www.tldp.org/HOWTO/Security-HOWTO/local-security.html
The command path for the root user is very important. The command path
(that is, the PATH environment variable) specifies the directories in
which the shell searches for programs. Try to limit the command path for
the root user as much as possible, and never include . (which means the
current directory) in your PATH. Additionally, never have writable
directories in your search path ...
http://www.tldp.org/HOWTO/Tips-HOWTO-3.html
Root's path should consist of 'PATH= /bin'
That's it. Nothing else on root's path.
http://osmirrors.cerias.purdue.edu/pub/OpenBSD/src/etc/security
{ print Root path directory $10 is group writable. }
http://security.sdsc.edu/advisories/outback_sec_guidelines
Most current day operating systems have this but, audit root's path, make
sure dirs are owned and only writable by root. minimize as much as
possible, e.g. /sbin:/usr/sbin:/bin:/usr/bin
http://www.start-linux.com/articles/article_165.php
One important thing to keep in mind are the different $PATH settings for
users and root:
* user: /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/user/bin:
* root: /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin
http://www.unet.univie.ac.at/aix/aixbman/admnconc/system_security.htm
The PATH value in the /etc/profile file is used by the root user. Only
specify directories that are secure, that is, that only root can write
to.
http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWaadm/SYSADV4/p98.html
The paths that lead to the home directory must be owned and writable by
root only. For example, if a .forward file is in /export/home/terry,
/export and /export/home must be owned and writable by root only.
Cheers,
Paul Szabo [EMAIL 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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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 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-in-the-foot mistakes. (You cannot make things 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-make-a-mistake misconfigurations. 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 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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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, 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 PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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, most of your problems can be solved with use of ugidd, and this is not Debian specific. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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 PATH. The kmem group also leads trivially to root. 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 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 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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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) '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 PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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 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 NetworkAttachedStorage device without any 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-writable 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-writable is ugly and 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-writability of /home is irrelevant in the security sense. Your suggestions do not protect against the attack. == 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. Finer control of privileges is useful when they are not root-equivalent. Group staff becomes a security issue once there are users in that group (and is useless otherwise). Users in group staff are root-equivalent, defeating the purpose of finer control. The crux of the matter is that group staff cannot be used. If it cannot be used then it should be ditched, regardless of whether it is a security risk while there are no users in that group. 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
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-any-user-but-root and become-any-group-but-root remains possible. In the presence of NFS, we (the local machine) cannot fully protect users; but must still protect root. 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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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 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 PROTECTED] 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 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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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 *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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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 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 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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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: ... 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 PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 PROTECTED] 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-groups.txt . Having /home writable by group staff OTOH doesn't seem particularly useful. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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 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 PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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. 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://www.dnsbl.sorbs.net/cgi-bin/db?IP=82.65.23.158 or mail [EMAIL PROTECTED] if genuine I will now ask my postmaster to whitelist your email address. 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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote:
In this report, the submitter complains about /usr/local/bin being in
the PATH by default at the same time directories under /usr/local are
root:staff and world-writable. His complain is based on the existence
of become-any-group-but-root bugs.
Not world-writable. Writable by group staff.
If this is a bug at all, I think we should probably drop the root:staff
thing instead of changing the default PATH. So: Would anyone here
second the following patch, if it were a policy proposal?
Having /usr/local staff writable is *very* useful when using CPAN to
install local packages w/- having to do the make install as root.
This is a benefit I'd prefer not to see removed, since the alternative
generally involves giving sudo access to a subset of users... which is
in my experience tantamount to simply adding more entry points to
gaining uid=0*, worse IMHO than having a subset of the filesystem
writable to that same set of users.
I would see setting root's PATH set to /bin:/sbin:/usr/bin:/usr/sbin as
a much better option than removing staff writability of /usr/local.
Although it's probably worth considering that there's more at stake here
than just PATH, since perl for example has /usr/local/{lib,share}/perl
earlier in @INC than /usr/{lib,share}/perl... Giving an attacker who
has breached a group staff acount another avenue: creating say
/usr/local/share/perl/5.8.4/strict.pm containing malevolent code if
$ == 0 would likely be tripped sooner or later.
I'm not sure what the emacs site-lisp search order is, but that may well
provide a similar vector.
In summary:
1. The Debian installer does not (AFAIK) add any user to group staff
by default, so this is not an issue for every installed Debian
system.
2. We need to assume some competence on behalf of the administrator as
to who gets added to group staff, just as we would with respect to
addition to /etc/sudoers or who was given the root password.
3. To mitigate the effects of compromises of group staff users, the
default root PATH should not include /usr/local; the administrator
may choose to type the full path if required (just as they must for
the case of .).
4. Perl (and other packages which preferentially load executable code
from /usr/local) may need to be modified to invert the module search
path order for uid=0.
--bod
* sudo is fine for specific tasks, like sudo mount /media/cdrom, but
woeful for things like sudo make install. Worse, I've seen sudo
bash more times than I care to recount.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
On Wed, 16 Mar 2005, Brendan O'Dea wrote: On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote: In this report, the submitter complains about /usr/local/bin being in the PATH by default at the same time directories under /usr/local are root:staff and world-writable. His complain is based on the existence of become-any-group-but-root bugs. Not world-writable. Writable by group staff. If this is a bug at all, I think we should probably drop the root:staff thing instead of changing the default PATH. So: Would anyone here second the following patch, if it were a policy proposal? Having /usr/local staff writable is *very* useful when using CPAN to install local packages w/- having to do the make install as root. This is a benefit I'd prefer not to see removed, since the alternative generally involves giving sudo access to a subset of users... which is in my experience tantamount to simply adding more entry points to gaining uid=0*, worse IMHO than having a subset of the filesystem writable to that same set of users. That's not really the alternative. The alternative is doing it yourself (i.e. chgrp -R staff /usr/local and so on) instead of it being the default. This proposal is not to prevent people from having /usr/local group-writable by staff, it's just a proposal to have neutral permissions in /usr/local. If you are a perl hacker and like /usr/local to be group writable, you will always be able to change the permissions yourself. The same is true, of course, about putting /usr/local/bin in the PATH. The difference is that you don't need to be a perl hacker to consider /usr/local/bin in the PATH a useful thing (not to mention we already have a lot of perl modules available via apt-get install). I bet that most people would add /usr/local/bin to the PATH if it weren't the default, for private shell scripts, perl scripts, python scripts, or whatever. Should we count your mail as a formal objection? You know, it only takes a negative vote to reject a policy proposal, even if it's supported by a lot of people. I think this is going to be a real pity. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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 vector.
Thanks for pointing out those avenues of attack.
In your summary you seem to have missed that any machines that share user
files via writable NFS mounts are vulnerable. (Are vulnerable if you mount
an NFS filesystem that is writable to others.)
To keep the current group staff access and have a reasonably useful machine
(with users in group staff to make use of that access, or NFS mounts even
when there are no users in group staff), you would need to modify PATH in
base-files, @INC in perl, something in emacs, and possibly other things in
other packages. You would need to modify policy:
http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2
says
... /usr/local take precedence over the equivalents in /usr.
Could the settings
Severity: critical
Justification: root security hole
please be re-instated on this bug? In some common scenarios, current
arrangements allow root access. (The worst kind of bug: mandated by
policy...)
Cheers,
Paul Szabo [EMAIL 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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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. 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 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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
On Fri, Mar 11, 2005 at 06:22:57PM +0100, Bill Allombert wrote: On Fri, Mar 11, 2005 at 03:26:16PM +0100, Martin Pitt wrote: I wholeheartedly agree and second this proposal. Also, /home should be root:root 0755 instead of root:staff 2775; it is only confusing and actually does not do anything useful. Obviously it does: it allows an administrator in the staff group to install software in /usr/local without having to use root priviledge, so prevent mistakes that would affect the /usr hierarchy. I don't see what is confusing here? In Martin's second sentence, he's talking about /home, where it's not especially useful for users other than root to have write access since they can't chown the home directories to the new user anyway. This is even documented, see /usr/share/doc/base-passwd/users-and-groups.txt.gz: staff Allows users to add local modifications to the system (/usr/local, /home) without needing root privileges. Compare with group 'adm', which is more related to monitoring/security. base-passwd documents the situation at the moment and the rationale as retroactively understood at the time when the documentation was written (that understanding may have been imperfect); I'd obviously be happy to update it to take account of changes. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH in /root/.profile
severity 299007 wishlist
reassign 299007 debian-policy
thanks
On Fri, 11 Mar 2005, Paul Szabo wrote:
Package: base-files
Version: 3.0.2
Severity: critical
Tags: patch security
Justification: root security hole
I recently noticed that /usr/local and /usr/local/{bin,sbin} are
group-writable and owned by root:staff. This is wrong: those directories
are in the default PATH for root. They (and files within) should be
root-owned: group staff users or become-any-user-but-root bugs should not
be able to trojan and thus get root.
[...]
This is not a bug. base-files follows policy. If you don't like
current policy, amend it. For your benefit, I'm doing a reassign.
Now you have to make a policy proposal. This is explained in the
debian-policy package.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
In this report, the submitter complains about /usr/local/bin being in the PATH by default at the same time directories under /usr/local are root:staff and world-writable. His complain is based on the existence of become-any-group-but-root bugs. If this is a bug at all, I think we should probably drop the root:staff thing instead of changing the default PATH. So: Would anyone here second the following patch, if it were a policy proposal? diff -ru debian-policy-3.6.1.1.orig/policy.sgml debian-policy-3.6.1.1/policy.sgml --- debian-policy-3.6.1.1.orig/policy.sgml 2004-06-25 23:11:36.0 +0200 +++ debian-policy-3.6.1.1/policy.sgml 2005-03-11 13:25:27.0 +0100 @@ -5062,8 +5062,8 @@ then if mkdir /usr/local/share/emacs 2/dev/null then -chown root:staff /usr/local/share/emacs -chmod 2775 /usr/local/share/emacs +chown root:root /usr/local/share/emacs +chmod 755 /usr/local/share/emacs fi fi /example @@ -5095,8 +5095,8 @@ p The file/usr/local/file directory itself and all the subdirectories created by the package should (by default) have - permissions 2775 (group-writable and set-group-id) and be - owned by ttroot.staff/tt. + permissions 755 and be + owned by ttroot:root/tt. /p /sect1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
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. If this is a bug at all, I think we should probably drop the root:staff thing instead of changing the default PATH. So: Would anyone here second the following patch, if it were a policy proposal? diff -ru debian-policy-3.6.1.1.orig/policy.sgml debian-policy-3.6.1.1/policy.sgml --- debian-policy-3.6.1.1.orig/policy.sgml2004-06-25 23:11:36.0 +0200 +++ debian-policy-3.6.1.1/policy.sgml 2005-03-11 13:25:27.0 +0100 @@ -5062,8 +5062,8 @@ then if mkdir /usr/local/share/emacs 2/dev/null then -chown root:staff /usr/local/share/emacs -chmod 2775 /usr/local/share/emacs +chown root:root /usr/local/share/emacs +chmod 755 /usr/local/share/emacs fi fi /example @@ -5095,8 +5095,8 @@ p The file/usr/local/file directory itself and all the subdirectories created by the package should (by default) have - permissions 2775 (group-writable and set-group-id) and be - owned by ttroot.staff/tt. + permissions 755 and be + owned by ttroot: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://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Bug#299007: base-files: Insecure PATH
On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote: In this report, the submitter complains about /usr/local/bin being in the PATH by default at the same time directories under /usr/local are root:staff and world-writable. His complain is based on the existence of become-any-group-but-root bugs. Is there evidence of such bugs ? There is no binaries sgid staff in Debian to start with. If this is a bug at all, I think we should probably drop the root:staff thing instead of changing the default PATH. So: Would anyone here second the following patch, if it were a policy proposal? dpkg never change permissions of directories by itself, so users can easily chown them to theirs liking. The policy snippet below has this property (mkdir will fail if the directory already exist). diff -ru debian-policy-3.6.1.1.orig/policy.sgml debian-policy-3.6.1.1/policy.sgml --- debian-policy-3.6.1.1.orig/policy.sgml2004-06-25 23:11:36.0 +0200 +++ debian-policy-3.6.1.1/policy.sgml 2005-03-11 13:25:27.0 +0100 @@ -5062,8 +5062,8 @@ then if mkdir /usr/local/share/emacs 2/dev/null then -chown root:staff /usr/local/share/emacs -chmod 2775 /usr/local/share/emacs +chown root:root /usr/local/share/emacs +chmod 755 /usr/local/share/emacs fi fi /example However, I disagree with the attitude of reassigning bug to debian-policy. If submitters want to make a policy proposal, they can propose it themselves. Maintainers creating policy proposal they clearly object to without anyone claiming support is a waste of time here. The purpose of this list is not to serve as a shield maintainers can use to deflect submitters. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
On Fri, Mar 11, 2005 at 03:26:16PM +0100, Martin Pitt wrote: Hi! I wholeheartedly agree and second this proposal. Also, /home should be root:root 0755 instead of root:staff 2775; it is only confusing and actually does not do anything useful. Obviously it does: it allows an administrator in the staff group to install software in /usr/local without having to use root priviledge, so prevent mistakes that would affect the /usr hierarchy. I don't see what is confusing here? This is even documented, see /usr/share/doc/base-passwd/users-and-groups.txt.gz: staff Allows users to add local modifications to the system (/usr/local, /home) without needing root privileges. Compare with group 'adm', which is more related to monitoring/security. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
On Fri, 11 Mar 2005, Bill Allombert wrote: On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote: In this report, the submitter complains about /usr/local/bin being in the PATH by default at the same time directories under /usr/local are root:staff and world-writable. His complain is based on the existence of become-any-group-but-root bugs. Is there evidence of such bugs ? There is no binaries sgid staff in Debian to start with. You don't need sgid staff binaries. Quoting the submitter: Become-any-user-but-root and become-any-group-but-root bugs are quite common. When a group of machines share user home directories via NFS exported from somewhere with default root-squash, getting root on one machine gives precisely that on all others of the group. There have been genuine such bugs also e.g. in sendmail [6]. The issue here is that group staff is equivalent to user root, and that we should better eliminate such equivalence from the default system. However, I disagree with the attitude of reassigning bug to debian-policy. If submitters want to make a policy proposal, they can propose it themselves. Well, you have to be an official developer for that, so that's not always possible. In this case, you may consider this as a proposal made by me if you like. This is not a bug in base-files because policy explicitly *mandates* the root:staff thing, but as I see fewer and fewer people who find the root:staff thing useful and more and more people who consider it a potentially dangerous thing, I think that we would better drop the staff thing from policy entirely, hence my reassign. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
On Fri, Mar 11, 2005 at 06:27:24PM +0100, Santiago Vila wrote: On Fri, 11 Mar 2005, Bill Allombert wrote: On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote: In this report, the submitter complains about /usr/local/bin being in the PATH by default at the same time directories under /usr/local are root:staff and world-writable. His complain is based on the existence of become-any-group-but-root bugs. Is there evidence of such bugs ? There is no binaries sgid staff in Debian to start with. You don't need sgid staff binaries. Quoting the submitter: Become-any-user-but-root and become-any-group-but-root bugs are quite common. When a group of machines share user home directories via NFS exported from somewhere with default root-squash, getting root on one machine gives precisely that on all others of the group. There have been genuine such bugs also e.g. in sendmail [6]. man exports, see squash_gids. I would say there are some many holes with NFS that I am not sure it make any difference. The same apply to sendmail. The issue here is that group staff is equivalent to user root, and that we should better eliminate such equivalence from the default system. No, it is not equivalent in the sense that if you are runing sgid staff and you do rm -r /usr/lib instead of rm -r /usr/local/lib by mistake, you do not hose your system. The first goal of the unix permissions is to protect against errors rather than malices. However, I disagree with the attitude of reassigning bug to debian-policy. If submitters want to make a policy proposal, they can propose it themselves. Well, you have to be an official developer for that, so that's not always possible. In this case, you may consider this as a proposal made by me if you like. Oh, sorry then. I did not understand you backed the proposal. In that case, it was completly normal to reassign the bug here, of course. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299007: base-files: Insecure PATH
On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote: In this report, the submitter complains about /usr/local/bin being in the PATH by default at the same time directories under /usr/local are root:staff and world-writable. His complain is based on the existence of become-any-group-but-root bugs. If this is a bug at all, I think we should probably drop the root:staff thing instead of changing the default PATH. So: Would anyone here second the following patch, if it were a policy proposal? Seconded in principle; I don't know if /usr/local/share/emacs is a good example of a directory that needs to not be sgid staff, but certainly I think that /usr/local/bin, /usr/local/sbin, and /usr/local/lib must not be. -- Steve Langasek postmodern programmer diff -ru debian-policy-3.6.1.1.orig/policy.sgml debian-policy-3.6.1.1/policy.sgml --- debian-policy-3.6.1.1.orig/policy.sgml2004-06-25 23:11:36.0 +0200 +++ debian-policy-3.6.1.1/policy.sgml 2005-03-11 13:25:27.0 +0100 @@ -5062,8 +5062,8 @@ then if mkdir /usr/local/share/emacs 2/dev/null then -chown root:staff /usr/local/share/emacs -chmod 2775 /usr/local/share/emacs +chown root:root /usr/local/share/emacs +chmod 755 /usr/local/share/emacs fi fi /example @@ -5095,8 +5095,8 @@ p The file/usr/local/file directory itself and all the subdirectories created by the package should (by default) have - permissions 2775 (group-writable and set-group-id) and be - owned by ttroot.staff/tt. + permissions 755 and be + owned by ttroot:root/tt. /p /sect1 signature.asc Description: Digital signature
Bug#299007: base-files: Insecure PATH in /root/.profile
Package: base-files
Version: 3.0.2
Severity: critical
Tags: patch security
Justification: root security hole
I recently noticed that /usr/local and /usr/local/{bin,sbin} are
group-writable and owned by root:staff. This is wrong: those directories
are in the default PATH for root. They (and files within) should be
root-owned: group staff users or become-any-user-but-root bugs should not
be able to trojan and thus get root.
The Debian Policy Manual [1] says:
... /usr/local take precedence over the equivalents in /usr.
... should have permissions 2775 and be owned by root.staff.
but it [2] also says:
... make sure that [it] is secure ...
Files should be owned by root.root ... mode 644 or 755.
Directories should be mode 755 or 2775 ... owned by the group that needs
write access to it.
The Debian Reference [3] and Securing Debian Manual [4], [5] say
[group] staff is ... for helpdesk types or junior sysadmins ... to do
things in /usr/local and to create directories in /home.
[group] staff: Allows users to add local modifications to the system
(/usr/local, /home) without needing root privileges.
The 'staff' group are usually help-desk/junior sysadmins, allowing them
to work in /usr/local and create directories in /home.
(This is surely wrong, seems a SysV left-over: you need root privileges to
chown user directories in /home or in fact to create users in /etc/passwd.)
Junior sysadmins should not be able or encouraged to trojan root, even if
you trust them with the root password or give them sudo privileges.
Become-any-user-but-root and become-any-group-but-root bugs are quite
common. When a group of machines share user home directories via NFS
exported from somewhere with default root-squash, getting root on one
machine gives precisely that on all others of the group. There have been
genuine such bugs also e.g. in sendmail [6].
This security lapse has been discussed before [7], [8].
The solution is to remove /usr/local things from the default PATH in
/root/.profile (i.e. in /usr/share/base-files/dot.profile), leaving a
warning comment instead.
It would also be good to re-word the confused policy, and to make
/usr/local root-owned. (Maybe /usr/local/sbin could then be used again.)
Discuss on debian-policy@lists.debian.org, or reportbug debian-policy?
References:
[1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2
[2] http://www.debian.org/doc/debian-policy/ch-files.html#s10.9
[3] http://www.debian.org/doc/manuals/reference/ch-tune.en.html#s9.2.3
[4]
http://www.debian.org/doc/manuals/securing-debian-howto/ch11.en.html#s11.1.12.1
[5]
http://www.debian.org/doc/manuals/securing-debian-howto/ch11.en.html#s11.1.12.2
[6] http://hackersplayground.org/papers/sendmailholes.txt
[7] http://lists.debian.org/debian-doc/2001/08/msg00041.html
[8] http://lists.debian.org/debian-user/2003/12/msg02057.html
Cheers,
Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux pisa.maths.usyd.edu.au 2.4.22-smssvr1.5.3 #1 SMP Wed Jun 23
13:01:39 EST 2004 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages base-files depends on:
ii base-passwd 3.4.1 Debian Base System Password/Group
ii gawk [awk]1:3.1.0-3 GNU awk, a pattern scanning and pr
ii mawk [awk]1.3.3-8a pattern scanning and text proces
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
