November 2006 - Darwin-kernel

Re: Administrator password
by Jeffrey Ellis 12 Nov '06

12 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AccGn/hgNrwi4nKTEduLIQANk0QgEg== Thread-topic: Administrator password User-agent: Microsoft-Entourage/11.2.5.060620 on 11/10/06 9:51 PM, Terry Lambert at tlambert(a)apple.com wrote: > You probably don't want chkpasswd, since it's not runnable from a > script, since it gets its input from the controlling tty, and sets raw > mode, etc. on it to control character echo, and so on. > > > In general, you do not check passwords, you let PAM check them for you. > > The only valid reason for checking a password is for the purpose of > establishing a session on a machine - i.e. if you are loginWindow, > sshd, ftpd, telnetd, /bin/login, or some other program that > establishes a session, or if you are utilizing security frameworks as > a trusted application that's permitted to launch subprocesses as > "root" (which is generally why the Finder ever asks for the admin > passwd; it subsequently effectively runs "sudo"). > > If you think you need the admin passwd for any other reason, your are > probably mistaken. > > > Your best bet is to look at the source code to /bin/login, sshd, or > one of the other applications that wires itself into the Mac OS X > infrastructure for starting a session. Realize that to answer your > question, your process will need to be privileged. > > -- Terry > Thanks for the heads up, Terry. I'll keep this all in mind. All My Best, Jeffrey _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

fpathconf kernel panic
by Joseph Oreste Bruni 12 Nov '06

12 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi All, Has this bug been filed in radar yet? If not, I'll file it. http://projects.info-pull.com/mokb/MOKB-09-11-2006.html -Joe _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com smime.p7s

1 0

Re: DNS from a Kernel Extension
by Michael Tuexen 11 Nov '06

11 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Just a note inside... On Nov 11, 2006, at 3:45 AM, Josh Graessley wrote: -josh On Nov 10, 2006, at 6:23 PM, William Kucharski wrote: WHY? This is just wrong on so many levels... William Kucharski kucharsk(a)mac.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Actually, there are some arguments for doing DNS resolution in the kernel. One problem we have right now is a number of people write lame networking code. They perform some sort of dns resolution and try to connect to the first address they get back. Most applications want to connect to some name, they don't care what the address is or even whether it's IPv4 or IPv6. An application should get back a list of all addresses the name resolves to and attempt to connect to each of those addresses until it finds one that works. Most applications just try the first one, or they wait for the first one to fail before attempting the second one. The kernel, if it was given a name or a list of addresses could do some intelligent stuff. In user space, you would need to open a new socket for each connection attempt. In the kernel, if there was a connect to name or connect to list, the kernel could start by sending the first syn to the the first address, wait for some time, then send the next syn and so on. The kernel could accept the first syn-ack to come back from any of those initial syns it sent. Once it got a syn-ack back, it would reject packets from any other addresses and finish up the three way handshake. The kernel could apply some smarts to try the best addresses first. An application wouldn't have to worry about the nitty gritty stuff and we wouldn't have to waste time creating lots of sockets or writing complicated code to have multiple sockets attempting simultaneous asynchronous connects. This is implemented in SCTP via the sctp_connectx() or sctp_sendx() calls. But it uses a list of IPv4/IPv6 addresses which must belong to the same host. FQDN are not supported. Doing DNS in the kernel would present a number of challenges. DNS is sort of one level above arp and we do arp in the kernel, so DNS is too much of a stretch. The problem is that people pollute their name resolution with all kinds of other crap from the /etc/hosts file to a variety of directory services plug-ins. Getting access to that stuff in the kernel is not feasible. On Friday, November 10, 2006, at 06:42PM, Curtis Jones <curtis.jones(a)gmail.com> wrote: I have a need for performing DNS resolution (name to address) for the use by a kernel extension, and it would be incredibly convenient if it could be performed within the kernel. I've looked around endless header files but haven't found anything helpful. If you ever need to do this type of thing, you need to take a step back and figure out why you're trying to this from the KERNEL. I can't even really think of one. The right way to do this is to have a user space process do the DNS resolution and pass the information to your kernel extension; better yet would be for a user space daemon to do both the DNS resolution AND all network communication. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/jgraessley% 40apple.com This email sent to jgraessley(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/michael.tuexen% 40lurchi.franken.de This email sent to michael.tuexen(a)lurchi.franken.de This email sent to site_archiver(a)lists.apple.com

1 0

Re: DNS from a Kernel Extension
by William Kucharski 11 Nov '06

11 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Nov 10, 2006, at 7:45 PM, Josh Graessley wrote: William Kucharski kucharsk(a)mac.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… The kernel, if it was given a name or a list of addresses could do some intelligent stuff. In user space, you would need to open a new socket for each connection attempt. In the kernel, if there was a connect to name or connect to list, the kernel could start by sending the first syn to the the first address, wait for some time, then send the next syn and so on. The kernel could accept the first syn-ack to come back from any of those initial syns it sent. Once it got a syn-ack back, it would reject packets from any other addresses and finish up the three way handshake. The kernel could apply some smarts to try the best addresses first. An application wouldn't have to worry about the nitty gritty stuff and we wouldn't have to waste time creating lots of sockets or writing complicated code to have multiple sockets attempting simultaneous asynchronous connects. This is really, really the wrong approach. One should never attempt to fix bad application design by making the kernel more complex. I subscribe to the theory that what's in the kernel should ONLY be code implementing things that can absolutely not be done any other way in user space, whether because they access private kernel data not visible to the outside world or because they change some vital system state. The example you describe COULD be implemented that way, but really that's sort of taking a sledgehammer to the situation. This type of thing should be done in the application by either doing intelligent name resolution or by simultaneously attempting connect()s to each IP address resolved in some type of hierarchical order. Since it's Mac OS X, firing off multiple threads seems like the PERFECT way to implement this. Lightweight and able to take advantage of simultaneous execution across multiple cores and processors. If it's really a goal to try and "fix" bad applciations, there should be a LIBRARY interface to do this. To give an example, Microsoft started out implementing their GUI window management routines for Windows NT in user land, the way they should be. To speed up execution (and avoid context switching), they moved the windowing code into the NT kernel. On the surface this makes sense, but it also makes the entire system more fragile - now bugs in the windowing code can crash the machine. Not good. Somewhat ironically, the whole reason the Mach kernel, upon which Mac OS X is based, was written was as a microkernel, with the idea that the BSD and System V kernels had become bloated with far too much extraneous code, most of which could really be handled by userland daemons. The fact that the Mach pager is an external daemon is one good example of this. Mach was designed so user utilities could handle any task, rather than just manipulate files as is the case with either BSD or SYSV UNIX. This makes the idea of bloating the Mac OS X kernel with code such as this even more reprehensible to me. Doing DNS in the kernel would present a number of challenges. DNS is sort of one level above arp and we do arp in the kernel, so DNS is too much of a stretch. The problem is that people pollute their name resolution with all kinds of other crap from the /etc/hosts file to a variety of directory services plug-ins. Getting access to that stuff in the kernel is not feasible. Not to mention that BIND has been the subject of any number of security holes, so putting that kind of code in the kernel is an even worse idea. :-) Then again, you know that, so I'm preaching to the choir here, I'm just trying to dissuade anyone else from the idea. :D This email sent to site_archiver(a)lists.apple.com

1 0

Re: DNS from a Kernel Extension
by Michael Smith 11 Nov '06

11 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Thunderbird 1.5.0.8 (Macintosh/20061025) Prior to a socket connection being permitted, a set of rules is analyzed. A matching rule can specify what will happen to that connection. One criterion upon which a rule can match is that of a host name. Thus the need to have access to the address(es) associated with a given host name (and expeditiously, if possible). = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Curtis Jones wrote: As Josh points out, you need to be able to deal with a hostname expanding to an arbitrary list of addresses. However, there's no reason for you to re-lookup these addresses for every packet. Process the list at load time (in your userland tool). Use this as an opportunity to convert the datastructure you keep in userland (which will be optimised for handling by your rule editing tool) into one that is more suitable for use by your kernel code (optimised for lookup operations). You can do all sorts of smart stuff if you like; compute a TTL for your in-kernel data based on the TTL information that comes back with your DNS queries. Fold entries together that have the same rules but different addresses, or different names but the same address. Divide your work so that things that you have to do on the socket path are in the kernel, and everything else is in userland. If you're not expecting to handle traffic in a performance-sensitive fashion, consider using a divert socket as previously suggested and handle things entirely in userspace; this will make your development/debugging process much easier. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Administrator password
by Michael Smith 11 Nov '06

11 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Thunderbird 1.5.0.8 (Macintosh/20061025) = Mike Try it? Andrei Evgenievich Warkentin andrey.warkentin(a)gmail.com <mailto:andrey.warkentin@gmail.com> Cell: (+1) (847) 321-15-55 On 10.11.2006, at 14:08, Jeffrey Ellis wrote: Thanks :) All My Best, Jeffrey ------------------------------------------------------------------------ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/drivers%40mu.org _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Andrei is right; in general it's a bad idea to try to know whether a credential of any sort is sufficient for an operation. There are typically many external variables that can change between when you ask and when you go to use it, and so whenever possible you should ensure that you are prepared to deal with the answer being wrong. Andrei E. Warkentin wrote: Is there a way to check if the user has given us the correct administrator password? _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com <mailto:Darwin-kernel@lists.apple.com>) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/andrey.warkentin%40gma… This email sent to andrey.warkentin(a)gmail.com <mailto:andrey.warkentin@gmail.com> This email sent to drivers(a)mu.org This email sent to site_archiver(a)lists.apple.com

1 0

Re: Administrator password
by Terry Lambert 11 Nov '06

11 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Nov 10, 2006, at 8:46 PM, Jeffrey Ellis wrote: There isn't necessarily a singular administrator account, and of course then there's also root. First you might check to verify that they gave you a admin user by checking to see if it's a member of the admin group. Next you can check that the password they gave you is correct with `chkpasswd`; see it's man page. Hi, Dan-- In general, you do not check passwords, you let PAM check them for you. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… on 11/10/06 5:05 PM, Dan Shoop at shoop(a)iwiring.net wrote: At 12:08 PM -0800 11/10/06, Jeffrey Ellis wrote: Is there a way to check if the user has given us the correct administrator password? That's sounds great, thank you :) You probably don't want chkpasswd, since it's not runnable from a script, since it gets its input from the controlling tty, and sets raw mode, etc. on it to control character echo, and so on. The only valid reason for checking a password is for the purpose of establishing a session on a machine - i.e. if you are loginWindow, sshd, ftpd, telnetd, /bin/login, or some other program that establishes a session, or if you are utilizing security frameworks as a trusted application that's permitted to launch subprocesses as "root" (which is generally why the Finder ever asks for the admin passwd; it subsequently effectively runs "sudo"). If you think you need the admin passwd for any other reason, your are probably mistaken. Your best bet is to look at the source code to /bin/login, sshd, or one of the other applications that wires itself into the Mac OS X infrastructure for starting a session. Realize that to answer your question, your process will need to be privileged. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Administrator password
by Jeffrey Ellis 11 Nov '06

11 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AccFTGX7pIFSnnE/EdudeAANk0QgEg== Thread-topic: Administrator password User-agent: Microsoft-Entourage/11.2.5.060620 on 11/10/06 5:05 PM, Dan Shoop at shoop(a)iwiring.net wrote: > At 12:08 PM -0800 11/10/06, Jeffrey Ellis wrote: >> Is there a way to check if the user has given us the correct administrator >> password? > > There isn't necessarily a singular administrator account, and of > course then there's also root. > > First you might check to verify that they gave you a admin user by > checking to see if it's a member of the admin group. > > Next you can check that the password they gave you is correct with > `chkpasswd`; see it's man page. Hi, Dan-- That's sounds great, thank you :) All My Best, Jeffrey _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: DNS from a Kernel Extension
by Joseph Oreste Bruni 11 Nov '06

11 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Nov 10, 2006, at 7:55 PM, Curtis Jones wrote: Unless you are implementing some sort of "proxy" and/or analyzing actual data sent via sockets, "... remote endpoint address ..." is going to be address (not a host name) or I'll provide more details. You tell me. Prior to a socket connection being permitted, a set of rules is analyzed. A matching rule can specify what will happen to that connection. One criterion upon which a rule can match is that of a host name. Thus the need to have access to the address(es) associated with a given host name (and expeditiously, if possible). Sounds like a darknet router. Joe _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com On 11/10/06, Andrei Tchijov <andrei(a)tchijov.com> wrote: am I missing something? You might have better luck implementing this entirely in userspace coupled with ipfw to divert all traffic into your process for analysis. ipfw is a very nice packet processor where you can hook yourself into various places depending on what you are trying to do. smime.p7s

1 0

Re: Re: DNS from a Kernel Extension
by Curtis Jones 11 Nov '06

11 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WjkNXHD8H3jj17OqbxtC+LbPIwnMVs2hDlsvJSU6m9OuFj4gCe3cYhD8QJyYy3qpRZZ4/kB9kbZz9I+HBie90evFa8BlZeidl1fSZ79TYkA8VaC5bvaHyWv0uWjMz/sPW6O41vg6eZHrha2Nniuq3gasu36ZMplhUjQW46jTimU= Unless you are implementing some sort of "proxy" and/or analyzing actual data sent via sockets, "... remote endpoint address ..." is going to be address (not a host name) or I'll provide more details. You tell me. Prior to a socket connection being permitted, a set of rules is analyzed. A matching rule can specify what will happen to that connection. One criterion upon which a rule can match is that of a host name. Thus the need to have access to the address(es) associated with a given host name (and expeditiously, if possible). -Curtis _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On 11/10/06, Andrei Tchijov <andrei(a)tchijov.com> wrote: am I missing something? This email sent to site_archiver(a)lists.apple.com

1 0