Bug#495529: linux-source: SMP process scheduler leaves CPUs idle
Having updated some machines to lenny and 2.6.26-19lenny2 kernel, I now cannot reproduce the problem: seems to be fixed. I guess this bug may be closed. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#384922: NFS insecure without support for squashing multiple groups
Dear Moritz, Please see comments in http://bugzilla.kernel.org/show_bug.cgi?id=14295 : This looks more like a feature request than a bug report to me. The right address for that kind of discussion would be on the linux-...@vger.kernel.org mailing list, not bugzilla. Right, a good first step would probably be a post to linux-...@vger.kernel.org summarizing the requirements (and maybe proposing a user-interface for) the mechanism that you're asking for. There have been a few requests over the years for various kinds of server-side auth_sys credential mapping. A brief marc.info search isn't finding them. There's nobody that I know of working on this sort of problem currently. Is there anything I should do? I would not know what user interface to propose. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#384922: NFS insecure without support for squashing multiple groups
Dear Moritz, Please file an enhancement bug at bugzilla.kernel.org ... Done: http://bugzilla.kernel.org/show_bug.cgi?id=14295 Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#406902: kernel NFS data loss
Dear Moritz, Can you give us a status update please? Is this fixed upstream in the mean time? If not, did you submit your patches and was there any feedback? I believe this issue has been fixed upstream, as per comment http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406902#29 I guess they did not use my patches to fs/exportfs/expfs.c, but arrived at the same change independently: I have only sent those patches to this Debian bug (not to any other forums). You may close this bug. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495529: linux-source: SMP process scheduler leaves CPUs idle
I have not yet updated any of my 8-core machines to lenny, plan to do that over the Christmas break. I had updated the kernels to 2.6.24 and the problem persists. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#303927: gzip TOCTOU file-permissions vulnerability
Joey Hess [EMAIL PROTECTED] wrote: ... really dumb idea to have a group/world-writeable directory without the sticky bit. It may be really dumb, but it's pretty common practice too. ... Just a few examples within the Debian project ... Kindly add the Debian example: [EMAIL PROTECTED]:/usr/local$ ls -ld . drwxrwsr-x 10 root staff4096 Nov 13 2002 . For Debian this is mandated by policy: The Debian Policy Manual [1] says: ... /usr/local take precedence over the equivalents in /usr. ... should have permissions 2775 and be owned by root.staff. but it [2] also says: ... make sure that [it] is secure ... Files should be owned by root.root ... mode 644 or 755. Directories should be mode 755 or 2775 ... owned by the group that needs write access to it. ... References: [1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2 [2] http://www.debian.org/doc/debian-policy/ch-files.html#s10.9 (please see http://bugs.debian.org/299007 for more details). (gzip is not typically ran in any of these directories AFAIK, FWIW). Typically? Suppose I (as simple user psz) do cd $HOME; touch xyz; chmod 666 xyz; gzip xyz and tell my system manager that I have problems with that gzipped file. While root is running gunzip ~psz/xyz I do rm xyz; ln /etc/passwd xyz then we end up with /etc/passwd world-writable. (Bzip uses chown also, so using bzip2/bunzip would get /etc/passwd owned by psz; am not sure about gzip or cpio.) Cheers, Paul Szabo [EMAIL 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#303927: gzip TOCTOU file-permissions vulnerability
Joey Hess [EMAIL PROTECTED] wrote: ... really dumb idea to have a group/world-writeable directory without the sticky bit. It may be really dumb, but it's pretty common practice too. ... Just a few examples within the Debian project ... Kindly add the Debian example: [EMAIL PROTECTED]:/usr/local$ ls -ld . drwxrwsr-x 10 root staff4096 Nov 13 2002 . For Debian this is mandated by policy: The Debian Policy Manual [1] says: ... /usr/local take precedence over the equivalents in /usr. ... should have permissions 2775 and be owned by root.staff. but it [2] also says: ... make sure that [it] is secure ... Files should be owned by root.root ... mode 644 or 755. Directories should be mode 755 or 2775 ... owned by the group that needs write access to it. ... References: [1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2 [2] http://www.debian.org/doc/debian-policy/ch-files.html#s10.9 (please see http://bugs.debian.org/299007 for more details). (gzip is not typically ran in any of these directories AFAIK, FWIW). Typically? Suppose I (as simple user psz) do cd $HOME; touch xyz; chmod 666 xyz; gzip xyz and tell my system manager that I have problems with that gzipped file. While root is running gunzip ~psz/xyz I do rm xyz; ln /etc/passwd xyz then we end up with /etc/passwd world-writable. (Bzip uses chown also, so using bzip2/bunzip would get /etc/passwd owned by psz; am not sure about gzip or cpio.) Cheers, Paul Szabo [EMAIL 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#303927: gzip TOCTOU file-permissions vulnerability
Joey Hess [EMAIL PROTECTED] wrote: ... really dumb idea to have a group/world-writeable directory without the sticky bit. It may be really dumb, but it's pretty common practice too. ... Just a few examples within the Debian project ... Kindly add the Debian example: [EMAIL PROTECTED]:/usr/local$ ls -ld . drwxrwsr-x 10 root staff4096 Nov 13 2002 . For Debian this is mandated by policy: The Debian Policy Manual [1] says: ... /usr/local take precedence over the equivalents in /usr. ... should have permissions 2775 and be owned by root.staff. but it [2] also says: ... make sure that [it] is secure ... Files should be owned by root.root ... mode 644 or 755. Directories should be mode 755 or 2775 ... owned by the group that needs write access to it. ... References: [1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2 [2] http://www.debian.org/doc/debian-policy/ch-files.html#s10.9 (please see http://bugs.debian.org/299007 for more details). (gzip is not typically ran in any of these directories AFAIK, FWIW). Typically? Suppose I (as simple user psz) do cd $HOME; touch xyz; chmod 666 xyz; gzip xyz and tell my system manager that I have problems with that gzipped file. While root is running gunzip ~psz/xyz I do rm xyz; ln /etc/passwd xyz then we end up with /etc/passwd world-writable. (Bzip uses chown also, so using bzip2/bunzip would get /etc/passwd owned by psz; am not sure about gzip or cpio.) Cheers, Paul Szabo [EMAIL 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: gzip TOCTOU file-permissions vulnerability
Joey Hess [EMAIL PROTECTED] wrote: ... really dumb idea to have a group/world-writeable directory without the sticky bit. It may be really dumb, but it's pretty common practice too. ... Just a few examples within the Debian project ... Kindly add the Debian example: [EMAIL PROTECTED]:/usr/local$ ls -ld . drwxrwsr-x 10 root staff4096 Nov 13 2002 . For Debian this is mandated by policy: The Debian Policy Manual [1] says: ... /usr/local take precedence over the equivalents in /usr. ... should have permissions 2775 and be owned by root.staff. but it [2] also says: ... make sure that [it] is secure ... Files should be owned by root.root ... mode 644 or 755. Directories should be mode 755 or 2775 ... owned by the group that needs write access to it. ... References: [1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2 [2] http://www.debian.org/doc/debian-policy/ch-files.html#s10.9 (please see http://bugs.debian.org/299007 for more details). (gzip is not typically ran in any of these directories AFAIK, FWIW). Typically? Suppose I (as simple user psz) do cd $HOME; touch xyz; chmod 666 xyz; gzip xyz and tell my system manager that I have problems with that gzipped file. While root is running gunzip ~psz/xyz I do rm xyz; ln /etc/passwd xyz then we end up with /etc/passwd world-writable. (Bzip uses chown also, so using bzip2/bunzip would get /etc/passwd owned by psz; am not sure about gzip or cpio.) Cheers, Paul Szabo [EMAIL 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#303927: gzip TOCTOU file-permissions vulnerability
Joey Hess [EMAIL PROTECTED] wrote:
I'm a wimp, so ... instead of writing some real exploit to win the race.
What race? A simple
perl -e 'while (1) { unlink(xyz) and link(/etc/passwd,xyz) and exit }'
should work.
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#295435: mbox parser
[Re-sending: my message yesterday does not seem to have made it to b.d.u]
Ricardo Mones [EMAIL PROTECTED] wrote:
Well, without checking I cannot tell it for true at 100%, but I believe
this bug is already corrected in current unstable/testing version (1.0.3).
Current woody backport [1] is at 1.0.0beta3, and probably fixes this too.
Sorry no, it is not fixed anywhere.
The only thing we can do is patch the current package as Justin proposed
(it was a trivial patch, isn't it?) and upload it to woody proposed-updates.
I propose the following patch. This goes cleanly into versions
1.0.3
1.0.4
1.9.2
1.9.6
and elicits only mild (fuzz/offset) messages for
0.7.4
.
Cheers,
Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
--- src/mbox.c.orig Mon Feb 7 18:48:12 2005
+++ src/mbox.c Thu Mar 31 08:29:29 2005
@@ -101,6 +101,7 @@
FILE *tmp_fp;
GSList *cur;
gchar *startp, *endp, *rpath;
+ gint empty_prev_line;
gint empty_line;
gboolean is_next_msg = FALSE;
FilterInfo *fltinfo;
@@ -131,17 +132,19 @@
FPUTS_TO_TMP_ABORT_IF_FAIL(buf);
from_line[0] = '\0';
+ empty_prev_line = 0;
empty_line = 0;
while (fgets(buf, sizeof(buf), mbox_fp) != NULL) {
if (buf[0] == '\n' || buf[0] == '\r') {
+ empty_prev_line = 1;
empty_line++;
buf[0] = '\0';
continue;
}
/* From separator */
- while (!strncmp(buf, From , 5)) {
+ while (empty_prev_line !strncmp(buf, From , 5)) {
strcpy(from_line, buf);
if (fgets(buf, sizeof(buf), mbox_fp) == NULL) {
buf[0] = '\0';
@@ -163,6 +166,7 @@
break;
}
}
+ empty_prev_line = 0;
if (is_next_msg) break;
if (empty_line 0) {
--
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
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
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
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#295435: mbox parser
Ricardo, Justin Pryzby [EMAIL PROTECTED] wrote: On Wed, Mar 23, 2005 at 09:02:41AM +1100, [EMAIL PROTECTED] wrote: ... bypassing the lazy maintainer? And others happen to have a life with situations where free time drops nearly to zero sometimes. But I guess is easier to think they're lazy. The lazy comment was mine. I did not intend to offend, but rather to succintly describe the situation. I apologize for my choice of word: now I see how it did not convey the meaning I intended. I'd better suggest to upgrade to a newer version. Given upstream is currently focused on developing the 2.0 version and the availability of much newer versions ported to woody, I don't think upstream is gonna take care of this bug. We can only hope that this bug will be corrected in version 2. The response from Hiroyuki Yamamoto [EMAIL PROTECTED] seems to indicate that the bug is taken seriously: his view of correctness seems skewed. I don't mind at all, if the actions are correct and justified :) 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
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#295435: mbox parser
Indeed ... Thank you for verifying my report. It would be easy to patch, except that whole function looks poorly written ... Agreed. ... I will leave it tagged upstream and hope that the maintainer forwards it there and that it is fixed properly. When do you expect it to be forwarded upstream? 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#295435: mbox parser
Justin, I am confused. You wrote: When do you expect it to be forwarded upstream? Donno; that's up to the maintainer. If you like, you can do it yourself. You should Cc: [EMAIL PROTECTED] in your message, which will get your message into the bts and also mark the bug as forwarded to whoever is in the To: field. Looking in http://bugs.debian.org/295435 it says Maintainer for sylpheed is Ricardo Mones [EMAIL PROTECTED] ... which agrees with you saying that you are not the maintainer. You suggest I do something funny to ensure the maintainer gets the message? Or, would that forward the bug upstream (all of it, or just the message I am sending), bypassing the lazy maintainer? If you are not the maintainer, how did you get to tag this bug: could I have done so myself? Sorry for the many questions. 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
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
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
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
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
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
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
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
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]
