Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Hurd Traffic #95 For 21 Jun 2001

Editor: Zack Brown

By Paul Emsley

Mach 4 | Hurd Servers | Debian Hurd Home | Debian Hurd FAQ | debian-hurd List Archives | bug-hurd List Archives | help-hurd List Archive | Hurd Reference Manual | Hurd Installation Guide | Cross-Compiling GNUMach | Hurd Hardware Compatibility Guide

Table Of Contents

1. Unowned Processes: nouser (uid -1)

2 Jun 2001 - 10 Jun 2001 (40 posts) Archive Link: "passwd entry for uid -1"

Summary By Paul Emsley

Topics: FS: NFS

People: Jeff BaileyMarcus BrinkmannRobert BihlmeyerOystein ViggenNeal WalfieldNeil WalfieldRoland McGrathNiels Möller

Jeff Bailey kicked off this extensive thread with:

I was just looking at what it would take to make screen load before login.

getpwuid(-1) correctly returns 0, since there is no passwd entry. This causes screen to fail. What's the Right Way to fix this? Should the Hurd add a passwd entry for uid -1 so that these programs run correctly?

Roland McGrath thought it was reasonable to have such a uid. But Marcus Brinkmann was not clear where the -1 was coming from. "Will screen run under the anonymous user? The getuid() returns -1 for such processes." Marcus added that there was already a "login" user with uid 100.

Marcus thought that the difference between Unix's "nobody" and the Hurd's "nouser" is that nobody is just another user (with special semantic) however, "nouser" is just that: no user at all. " Ids in the Hurd are sets, and nouser is the one with the empty id set." . Robert Bihlmeyer argued that according to security experts, ""nobody" was only meant as a no-rights-at-all target to map root to in NFS. I'd actually wager that "nobody" was in fact an attempt to emulate the concept of an empty id set (or empty capability set) in Unix semantics."

This gave Marcus cause for thought. He came up with this suggestion:

Will the following scenario work?

glibc is changed, so that "setuid(-1)" means: Drop all (effective?) user ids. Change the nobody entry in the passwd file so that it lists -1 as uid.

This will make Unix programs which conventionally switch to user nobody very safe (because they will run without any privileges).

Oystein Viggen joined in and asked if such a system would allow "nobody" to run apache threads and "bind". Then would an attacker who cracks "bind" still be unable to fiddle with apache? Oystein went on to say:

In Unix/linux, running stuff as nobody is not of much use, as if you run two or more services as the user nobody, the cracker that gets in through one of them will have control over all the others. (and can for example debug/ptrace() your sshd, dumping all the passwords.) As Robert said, "nobody" actually owning stuff is even worse.

If we could get some kind of compartmentalizing for setuid(-1), so that the apache threads would have access to each other, but not to bind or the ftpd, and soforth, it could work, but this would again be totally incompatible with all other systems.

I'm not sure how you would combine "no privileges" with "actually being able to do something useful". I'm quite Unixified in my knowledge, so perhaps it is only a question of unlearning a bit more.

Marcus was not sure about the security from crackers issue, suggesting that the code in proc/ allows you to frob processes if the owner of the processs is amongst your login collection. " It's not clear to me how this stuff works from just reading a couple of minutes. We should probably ask Thomas" . With regard to compartmentalizing setuid(-1), Marcus described some tests: "Create a few users (we need them just for the login group). Login, use rmauth to drop all uids, and then run some programs. You should not be able to kill programs in one login group from another one. Also try this at the login shell as another "login group", and with programs run at boot time. You can use getlogin to query the login group. "

Marcus added: "The programs can access the filesystems through the fourth set of access bits. By default, they are the same as the bits for "other". This way, you can actually do something useful. However, the point of who controls who for unowned processes is an important one."

Oystein did the tests and posted the results and his thoughts, on which Marcus commented. With regard to keeping some privileges for servers, Marcus said "I thought about first opening a socket and bind to it, then drop uids. That's not so good as running without any ids in the first place, but better than keeping those uids around, isn't it? "

However, Oystein didn't like this idea:

If you're talking about sockets as in TCP/IP networking, this is good enough for a webserver and other simple protocols, but for an ftp-server wanting to support active ftp, this won't work.

Also, without some proper filesystem support for this, there will be problems for all services actually wanting to store something on disk. I thought for a moment about how you could run BIND uid-less, until I came to think of the problems you would have the second time you wanted to do a zone xfer.

Normal users can run rmauthed processes which can create files in /tmp which are then owned by root. "What else could it do, without further support in the filesystem server for this?" asked Marcus. Niels Möller offered the alternative of "cannot create files", with some exception mechanism. Oystein said "I can't see any secure way you could let a no-user process store data to be retrieved on restarting the process, except opening the files before going no-user." But Marcus "Master of the Translators" Brinkmann was not ready to give up so easily. He suggested using a special translator to provide a filesystem that gives a separate namespace for different login groups. This proxy server could use /tmp directories to store the data (with files owned by root). The "nouser" user could only access these data by using this server. Marcus even suggested a incorporating a quota system.

Explaining the systems somewhat, Marcus said "All processes in the same login group should get access to the same files." . Oystein furrowed his brow and asked: "If I log in as root on the console, through telnet, and through ssh and noauth all three, would these be in the same login group? " (his tests seemed to indicate otherwise).

Marcus replied "You have to decide if you want isolation or control [...] If you want to gain control, then it should be straightforward to add an interface to proc that sets the logingroup of one process to that of another. This can be used by root to get access to another login group. However, for obvious reasons, this is root-only. After someone drops the uids, you have no idea anymore who owns this task, so you can not perform any authentication to let others (except root) in the same login group. "

In a slightly different subthread there was some back-and-forth between Niels and Oystein about various daemons/servers and capabilities. Neil Walfield came in with "Just because you have no uids does not mean you cannot run addauth. And since a user is trying to login in as a specific user, you provide that password to the addauth prompt. Therefore, you can run with no uids and switch to other users without reading /etc/shadow."

Marcus replied to this idea: "It is probably useful to add here that the server responsible for that is the password server, which hands out auth handles with uids in exchange for the password. This server runs as root and sits on /servers/password." Oystein liked this idea and decided to stop this thread for now and go and do some reading.

2. F3 CDs

8 Jun 2001 - 13 Jun 2001 (13 posts) Archive Link: "Hurd F3 CDs"

Summary By Paul Emsley

People: Philip CharlesJames MorrisonRoland McGrath

Philip Charles said "The scripts for the F3 series are ready. So if there are any packages that people want included in this set would they get them into the main archive asap. I intend to produce the images about 20 June. The main disc was over size and this has meant that the some documentation has had to be moved to the extra disc. The Hurd is growing. " James Morrison asked if openssl would be on the F3 CD. Marcus said that openssl (a dependency for openssh) is in non-us and is up-to-date (see http://hurd.sourceforge.net/turtle/group/Debian-non-US/package/openssl/index.html.

But as for openssh itself, he was waiting for Hurd patches "to go in". There was a short discussion about the use of alpha.gnu.org vs. an NMU since the patch application and package distribution was not as speedy as it may have been. Roland McGrath suggested that hurd.sourceforge.net should be used for this sort of thing.

Marcus said that he had compiled and uploaded openldap, so exim should be straightforward.

3. The Hurd Develops External kill

9 Jun 2001 (7 posts) Archive Link: "db3 configure dies at kill?"

Summary By Paul Emsley

People: Roland McGrath

Marcus made a plea to people to use the mailing list to solve their problems, not just IRC. He had in mind the problem of db3 configure script looking for an external "kill". There was some back and forth over the precice details of the shell script. Roland McGrath, (the Obvious Autority) said: "The canonical portable form is: (exec kill) ${1+"$@"} That is wholly portable and is all over the place in GNU shell scripts. "

4. The (Hurd Valid) Empty String Filename Causing Problems In Debhelper

10 Jun 2001 - 11 Jun 2001 (8 posts) Archive Link: "Debhelper: Do not upgrade"

Summary By Paul Emsley

People: Jeff BaileyRoland McGrath

Jeff Bailey found a problem with a recent debhelper "Between debhelper 3.0.26, and 3.0.31 dh_gencontrol changed, and no longer works on the Hurd. I haven't filed a bug yet, because I think this is exposing a perl-on-hurd bug (dh_gencontrol works fine under Linux)." Roland McGrath said "That may be because the empty string is a valid file name on the Hurd (it refers to the current directory), though it isn't on Linux. The perl program that uses the empty file name, when what it really intends is not to refer to any file name, is buggy." There was some incisive postings and Jeff finished off thanking people and saying that he had filed a bug report and that 3.0.33 is fixed and in incoming.

5. Getting Debian Packages

12 Jun 2001 - 14 Jun 2001 (6 posts) Archive Link: "Where to get HURD .debs?"

Summary By Paul Emsley

Topics: Apt

People: Tony MiddletonGlenn Alexander

Glenn Alexander asked where to get Hurd deb packages. He has a PPP connection so he cannot practically use apt-get or get a CD image. He was pointed to /debian/pool/main/h/hurd/ on his favourite mirror, /debian/dists/sid/main/binary-hurd-i386/Packages.gz and Tony Middleton said "The instructions at /usr/share/doc/apt/offline.html show how you can use apt to download hurd packages from the normal mirrors while using ppp under GNU/Linux."

6. FATFS Exposes gnumach store Bug

13 Jun 2001 - 15 Jun 2001 (7 posts) Archive Link: "FAT and Stores"

Summary By Paul Emsley

People: Roland McGrathMarcus Brinkmann

Thomas Langan decided to rework the fatfs of Marcus Brinkmann. However, he had a problem with unexpected values from store->block_size. "This is odd," said Roland McGrath and gave Thomas some experiments to try. Thomas posted his results, Roland examined them and said: "A ha! It's Marcus's fault" and went on to explain the problem and said that he checked in a fix to gnumach.

Marcus apologized saying he "should not have sneaked in such a change together with [another] change. "

However, Roland was not easily mollified: "Boot to the head," he said unsympathetically.

7. Hurd Orientation

3 May 2001 - 10 Jun 2001 (4 posts) Archive Link: "Hurd Orientation"

Summary By Paul Emsley

People: Roland McGrathJeff Bailey

There were a few replies to Jeff Bailey's "Welcome to the Hurd" message, prompting Roland McGrath to say " I think everyone who is interested in making the informational resources more helpful ought to get on the web-hurd@gnu.org mailing list and concentrate on unifying the various efforts into a cohesive presence on the web and the mailing lists. There have been a lot of folks pitching in, but we can certainly use someone to declare themselves web czar and start kicking ass as to organization of all the information that's floating around. If people get active on this, we can give you all the resources you need, i.e. hook you up with admin access for the web sites and the help-hurd mailman admin so you can set up things like the new-subscriber and periodic automatic postings. "

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.