Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tuesday 23 April 2002 05:46, Greg 'groggy' Lehey wrote: On Monday, 22 April 2002 at 19:53:06 -0700, Jordan Hubbard wrote: That fix relies on the extensive PAM updates in -CURRENT however; in -STABLE it can probably be similarly replicated via appropriate tweaking of sshd (?). Why not fix it in stable by the very simple tweaking of the ChallengeResponseAuthentication to no in the sshd config file we ship Trust me, this question is going to come up a _lot_ for us otherwise. :( I've been noticing a continuing trend for more and more safe configurations the default. I spent half a day recently trying to find why I could no longer open windows on my X display, only to discover that somebody had turned off tcp connections by default. *shrug* I was the one who sent in the patch. It was added some time around 2001/10/26 to the XFree86-4 megaport. When the metaport was created, the patch was incorporated too. A simple 'man startx' should have cleared your mind: Except for the '-listen_tcp' option, arguments immediately following the startx command are used to start a client in the same manner as xinit(1). The '-listen_tcp' option of startx enables the TCP/IP transport type which is needed for remote X displays. This is disabled by default for security reasons. I have a problem with this, and as you imply, so will a lot of other people. As a result of this sort of thing, people trying to migrate from other systems will probably just give up. I certainly would have. While it's a laudable aim to have a secure system, you have to be able to use it too. I'd suggest that we do the following: 1. Give the user the choice of these additional features at installation time. Recommend the procedures, but explain that you need to understand the differences. 2. Document these things very well. Both this ssh change and the X without TCP change are confusing. If three core team members were surprised, it's going to surprise the end user a whole lot more. We should at least have had a HEADS UP, and we probably need a security policy document with the distributions. I'd agree with option 2. Except that people trying to use X with tcp connections probably won't look in the security policy document for a solution. In the case of the X patch, i'd add it to the release notes AND the security policy document, since - i think - few people will look in the security policy document for such a problem. I do have to say you're the first one I see who complains about this... Jochem To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tuesday, 23 April 2002 at 10:09:51 +0200, Jochem Kossen wrote: On Tuesday 23 April 2002 05:46, Greg 'groggy' Lehey wrote: On Monday, 22 April 2002 at 19:53:06 -0700, Jordan Hubbard wrote: That fix relies on the extensive PAM updates in -CURRENT however; in -STABLE it can probably be similarly replicated via appropriate tweaking of sshd (?). Why not fix it in stable by the very simple tweaking of the ChallengeResponseAuthentication to no in the sshd config file we ship Trust me, this question is going to come up a _lot_ for us otherwise. :( I've been noticing a continuing trend for more and more safe configurations the default. I spent half a day recently trying to find why I could no longer open windows on my X display, only to discover that somebody had turned off tcp connections by default. *shrug* I was the one who sent in the patch. It was added some time around 2001/10/26 to the XFree86-4 megaport. When the metaport was created, the patch was incorporated too. A simple 'man startx' should have cleared your mind: Well, yes. But I've been using X for 11 years. Why should I have to read the man page to find changes? How do I know which man page to read? If I did that for everything that happened, I wouldn't get any work done. And you can bet your bottom dollar that somebody coming from another UNIX variant and trying out FreeBSD won't do so. They'll just say that it's broken and wander off again. I have a problem with this, and as you imply, so will a lot of other people. As a result of this sort of thing, people trying to migrate from other systems will probably just give up. I certainly would have. While it's a laudable aim to have a secure system, you have to be able to use it too. I'd suggest that we do the following: 1. Give the user the choice of these additional features at installation time. Recommend the procedures, but explain that you need to understand the differences. 2. Document these things very well. Both this ssh change and the X without TCP change are confusing. If three core team members were surprised, it's going to surprise the end user a whole lot more. We should at least have had a HEADS UP, and we probably need a security policy document with the distributions. I'd agree with option 2. Except that people trying to use X with tcp connections probably won't look in the security policy document for a solution. Correct. That's why I think option 1 is preferable. In the case of the X patch, i'd add it to the release notes AND the security policy document, since - i think - few people will look in the security policy document for such a problem. I think it shouldn't happen at all unless people agree to it. I do have to say you're the first one I see who complains about this... Maybe the others have given up. But since we're on the subject, why? What's so insecure about X TCP connections? Until you explicitly allow connections, the only system that can open the server is the local system. -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tue, Apr 23, 2002 at 06:34:52PM +0930, Greg 'groggy' Lehey wrote: Well, yes. But I've been using X for 11 years. Why should I have to read the man page to find changes? How do I know which man page to read? If I did that for everything that happened, I wouldn't get any work done. And you can bet your bottom dollar that somebody coming from another UNIX variant and trying out FreeBSD won't do so. They'll just say that it's broken and wander off again. FWIW, I would be extremly pissed about this myself, I just happen to not having installed 4.5 myself yet, for other reasons. I thought there was a policy of the least surprise, it might have been to kernel code, but should be applied here as well. The system has to work right away, when installed out of the box. Period. No when's and if's. And don't tell me that X11 is an add-on and luxury. We are living in the 21st century. Joerg -- Joerg B. MicheelEmail: [EMAIL PROTECTED] WAND and NLANR MOAT Email: [EMAIL PROTECTED] The University of Waikato, CompScience Phone: +64 7 8384794 Private Bag 3105Fax: +64 7 8585095 Hamilton, New Zealand Plan: PMA, TINE and the DAG's To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tue 2002-04-23 (21:13), Joerg Micheel wrote: On Tue, Apr 23, 2002 at 06:34:52PM +0930, Greg 'groggy' Lehey wrote: Well, yes. But I've been using X for 11 years. Why should I have to read the man page to find changes? How do I know which man page to read? If I did that for everything that happened, I wouldn't get any work done. And you can bet your bottom dollar that somebody coming from another UNIX variant and trying out FreeBSD won't do so. They'll just say that it's broken and wander off again. FWIW, I would be extremly pissed about this myself, I just happen to not having installed 4.5 myself yet, for other reasons. I thought there was a policy of the least surprise, it might have been to kernel code, but should be applied here as well. The system has to work right away, when installed out of the box. Period. No when's and if's. And don't tell me that X11 is an add-on and luxury. We are living in the 21st century. There are people who will tell people that still use X11 tcp sockets to start living in the 21st century. ssh X11 forwarding still works, it's only the (often much lower security) tcp sockets that are disabled by default. (And if the none cipher is available, the overhead would be minimal for even the most underpowered machine.) At least Debian takes this stance, and so many believe it's a sane default. If it were reverted, I'm sure there'll be lots of people re-adding the change to their security regimen. And lots more people scurrying to patch when the next DoS or exploit comes out. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: boot -a in 4.5-STABLE
Hi, On Tue, Apr 23, 2002 at 06:46:18AM +0200, Thierry Herbelot wrote: Marc Heckmann wrote: I've got 4.5-STABLE setup here with vinum as per the Vinum bootstrapping howto (http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vinum/index.html). I have ad0s1a which is / and ad2s1a which is mounted on /rootback, it's an exact copy of the / filesystem. ^ [SNIP] mountroot ufs:/dev/ad2s1a Mounting root from ufs:/dev/ad0s1a NOTE this if the root partitions are identical, the /etc/fstab files are also identical, so you are truing to mount the initial root paartition from the second disk. correct, the value in /etc/fstab, seems to override whatever I manually tell the kernel to use as the root device. But if I am booting with -a and -s, shouldn't the fstab just be ignored? I should have / on ad2s1a mounted RO at that point so I can manually re-mount RW and edit my fstab. The vinum bootstrap howto also seems to describe that way. What is the expected behavious should be when using the -a switch? Thanks in advance -m -- m. heckmann. -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tuesday 23 April 2002 11:04, you wrote: [...] I've been noticing a continuing trend for more and more safe configurations the default. I spent half a day recently trying to find why I could no longer open windows on my X display, only to discover that somebody had turned off tcp connections by default. *shrug* I was the one who sent in the patch. It was added some time around 2001/10/26 to the XFree86-4 megaport. When the metaport was created, the patch was incorporated too. A simple 'man startx' should have cleared your mind: Well, yes. But I've been using X for 11 years. Why should I have to read the man page to find changes? Because things evolve? :) How do I know which man page to read? You start X with startx, seems obvious to me. The disabling of tcp connections only applies to startx If I did that for everything that happened, I wouldn't get any work done. And you can bet your bottom dollar that somebody coming from another UNIX variant and trying out FreeBSD won't do so. OK, then i suggest we mention it in the handbook, the security policy document, the manpage AND the release notes :) They'll just say that it's broken and wander off again. I have a problem with this, and as you imply, so will a lot of other people. As a result of this sort of thing, people trying to migrate from other systems will probably just give up. I certainly would have. While it's a laudable aim to have a secure system, you have to be able to use it too. I'd suggest that we do the following: 1. Give the user the choice of these additional features at installation time. Recommend the procedures, but explain that you need to understand the differences. 2. Document these things very well. Both this ssh change and the X without TCP change are confusing. If three core team members were surprised, it's going to surprise the end user a whole lot more. We should at least have had a HEADS UP, and we probably need a security policy document with the distributions. I'd agree with option 2. Except that people trying to use X with tcp connections probably won't look in the security policy document for a solution. Correct. That's why I think option 1 is preferable. I was trying to say to not just notify it in the security policy alone. In the case of the X patch, i'd add it to the release notes AND the security policy document, since - i think - few people will look in the security policy document for such a problem. I think it shouldn't happen at all unless people agree to it. 3 people did, 0 people did not...read below I do have to say you're the first one I see who complains about this... Maybe the others have given up. LOL But since we're on the subject, why? What's so insecure about X TCP connections? Until you explicitly allow connections, the only system that can open the server is the local system. For the simple reason I don't like useless open ports on my system. I don't use it, _most_ other people don't use it, so i sent in a patch. Peter Pentchev liked the idea, Jean-Marc Zucconi (the maintainer) didn't have any objections, and when I showed the patch to Will Andrews when he was busy with the meta port, he liked it too and integrated it. I haven't seen any other reactions to it. Of course, it was only discussed on the ports@ mailinglist, but it didn't seem like such a big deal to me or apparently the others... Jochem To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tue, Apr 23, 2002 at 11:38:26AM +0200, Neil Blakey-Milner wrote: There are people who will tell people that still use X11 tcp sockets to start living in the 21st century. ssh X11 forwarding still works, it's only the (often much lower security) tcp sockets that are disabled by default. (And if the none cipher is available, the overhead would be minimal for even the most underpowered machine.) I may not understand all the issues here, but can the situation be helped by improving the reporting. I.e. if the firewalling prohibits access to the X11 TCP socket, why would the firewall not report this instantly at the first attempt to connect, to be visible at the console and in /var/log/messages. I am sure Greg would have caught that first time around, and it would have safed him from a few hours of useless debugging time. Joerg -- Joerg B. MicheelEmail: [EMAIL PROTECTED] WAND and NLANR MOAT Email: [EMAIL PROTECTED] The University of Waikato, CompScience Phone: +64 7 8384794 Private Bag 3105Fax: +64 7 8585095 Hamilton, New Zealand Plan: PMA, TINE and the DAG's To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tue, 23 Apr 2002 11:38:26 +0200, Neil Blakey-Milner [EMAIL PROTECTED] wrote: On Tue 2002-04-23 (21:13), Joerg Micheel wrote: [..] The system has to work right away, when installed out of the box. Period. No when's and if's. And don't tell me that X11 is an add-on and luxury. We are living in the 21st century. There are people who will tell people that still use X11 tcp sockets to start living in the 21st century. ssh X11 forwarding still works, it's only the (often much lower security) tcp sockets that are disabled by default. (And if the none cipher is available, the overhead would be minimal for even the most underpowered machine.) [..] I completely agree with Neil. Being scared by X11 access mechanisms, I always disabled the TCP listen of the X server, and I always used ssh with X forwarding. marco To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tuesday 23 April 2002 11:13, you wrote: On Tue, Apr 23, 2002 at 06:34:52PM +0930, Greg 'groggy' Lehey wrote: Well, yes. But I've been using X for 11 years. Why should I have to read the man page to find changes? How do I know which man page to read? If I did that for everything that happened, I wouldn't get any work done. And you can bet your bottom dollar that somebody coming from another UNIX variant and trying out FreeBSD won't do so. They'll just say that it's broken and wander off again. FWIW, I would be extremly pissed about this myself, I just happen to not having installed 4.5 myself yet, for other reasons. I thought there was a policy of the least surprise, it might have been to kernel code, but should be applied here as well. I haven't seen your complaint anywhere... The system has to work right away, when installed out of the box. Period. No when's and if's. It does work. But i think you mean the tcp connections. Does that mean you vote for enabling _all_ services? They don't work out of the box as well... And don't tell me that X11 is an add-on and luxury. I agree, but the tcp connections IS an add-on luxury imho We are living in the 21st century. That's right, the century of virii, DoS attacks, worms, and scriptkiddiots. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
sendfile() in tftpd?
Hello, Would it be possible to use sendfile in tftpd? With an Athlon XP 1600+ I could only get ~40 Mbps out from the machine with 0% idle CPU time (large file transfers from many machines, getting the same file). Thanks, [ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]--- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Greg 'groggy' Lehey wrote: I've been noticing a continuing trend for more and more safe configurations the default. I spent half a day recently trying to find why I could no longer open windows on my X display, only to discover that somebody had turned off tcp connections by default. I have a problem with this, and as you imply, so will a lot of other people. As a result of this sort of thing, people trying to migrate from other systems will probably just give up. I certainly would have. While it's a laudable aim to have a secure system, you have to be able to use it too. I'd suggest that we do the following: I think we need to make an ACPI call in the loader to power off the machine before it becomes dangerously functional. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Thus spake Greg 'groggy' Lehey [EMAIL PROTECTED]: work done. And you can bet your bottom dollar that somebody coming from another UNIX variant and trying out FreeBSD won't do so. They'll just say that it's broken and wander off again. I agree with this point, in general. FreeBSD shouldn't be like OpenBSD, where everything is so secure by default that you can't get anything done. For example, most people who use X don't know---and don't want to know---how it works. If the defaults are too restrictive, they will be frustrated, and maybe they'll figure out how to make things unrestrictive without understanding what's going on. On the other hand, if the defaults are not cautious enough, the same people will need to apply patches when the next remotely exploitable hole in X is found, and many of them won't bother. I'm a bit more wary of third-party applications, particularly big ones like X, so disabling TCP connections by default seems like a reasonable thing to do. But it should have been documented in a place where people actually look when they upgrade. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Neil Blakey-Milner wrote: The system has to work right away, when installed out of the box. Period. No when's and if's. And don't tell me that X11 is an add-on and luxury. We are living in the 21st century. There are people who will tell people that still use X11 tcp sockets to start living in the 21st century. ssh X11 forwarding still works, it's only the (often much lower security) tcp sockets that are disabled by default. (And if the none cipher is available, the overhead would be minimal for even the most underpowered machine.) I agree that X11 isn't very forward looking; it'd be nice if the displays were themselves CORBA objects, so you could embed desktops to use any display technology you wanted, so that you could build a desktop compute server for 1000 users without eating 11G of RAM to do it. Until someone writes that though... It's be nice if the ssh X11 forwarding were not the prefered method of remote access to X11. Particularly since I haven't seen any fixes for the MIT shared memory extension going in to stop the inevitable shared memory leaks by Netscape, etc., or anything else that uses it for bitmaps, and is long running, so the resources get used up and never reclaimed. Disabling the workaround -- which is to use network connections, instead of using the UNIX domain socket, thereby disabling the libraries use of the shared memory extension -- isn't my idea of a good approach. All it does is exacerbate the problem, for questionable security (not listening is not the same thing as having a firewall, so if TCP is vulnerable for X11, then it's vulnerable for every other port that *is* listening). Forget Debian, what does OpenBSD do? It's the gold standard when it comes to anal default settings. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
Attila Nagy wrote: Would it be possible to use sendfile in tftpd? With an Athlon XP 1600+ I could only get ~40 Mbps out from the machine with 0% idle CPU time (large file transfers from many machines, getting the same file). Only if all file transfers were binary, or all ASCII files were stored on the host with CRLF line termination, instead of LF. That's the same reason sendfile() is stupid for POP3, IMAP4, and SMTP servers... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Jochem Kossen wrote: *shrug* I was the one who sent in the patch. It was added some time around 2001/10/26 to the XFree86-4 megaport. When the metaport was created, the patch was incorporated too. A simple 'man startx' should have cleared your mind: Except for the '-listen_tcp' option, arguments immediately following the startx command are used to start a client in the same manner as xinit(1). The '-listen_tcp' option of startx enables the TCP/IP transport type which is needed for remote X displays. This is disabled by default for security reasons. ... I'd agree with option 2. Except that people trying to use X with tcp connections probably won't look in the security policy document for a solution. In the case of the X patch, i'd add it to the release notes AND the security policy document, since - i think - few people will look in the security policy document for such a problem. I do have to say you're the first one I see who complains about this... Well, since I have only complained, however loudly, on the irc channel, let me pipe in. It is inconvenient, to say the least, to have to exit X after over 40 shell sessions are open because you suddenly realize X just stopped opening the TCP port out of nothing after you last upgraded it. Or because you forgot to use the -listen_tcp option, not unusual since I never needed it before. An changing the script is not good enough either, since a portupgrade -a may change it back. Do you use remote X clients at all? Because I cannot conceive of a person who does and cannot understand how against POLA this change is. The -listen_tcp option is ridiculous to me. You must never *HAVE* to resort to a parameter for a thing which is not only the default but the the _only_ way you want it. The port *SHOULD* indicate that the listen port is no longer the default, and the *MUST* be a way of saying you want it always, either a port option so I can put it in make.conf, or an environment variable so I can put it in login.conf. But security is good. As a matter of fact, I'll change loader not to load a kernel by default, since this is a security hole in case the machine reboots. But don't worry, I'll document it in loader(8). -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] They did what they could to help her, using human skills -- and then, when that failed, left it in the hands of the gods. In this case, he bowed slightly, myself. Like it or not, the demon continued, that is my status in this region. Take it up with my priests if it bothers you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Terry Lambert wrote: Greg 'groggy' Lehey wrote: I've been noticing a continuing trend for more and more safe configurations the default. I spent half a day recently trying to find why I could no longer open windows on my X display, only to discover that somebody had turned off tcp connections by default. I have a problem with this, and as you imply, so will a lot of other people. As a result of this sort of thing, people trying to migrate from other systems will probably just give up. I certainly would have. While it's a laudable aim to have a secure system, you have to be able to use it too. I'd suggest that we do the following: I think we need to make an ACPI call in the loader to power off the machine before it becomes dangerously functional. I hear that. I'll put it on my list too. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] They did what they could to help her, using human skills -- and then, when that failed, left it in the hands of the gods. In this case, he bowed slightly, myself. Like it or not, the demon continued, that is my status in this region. Take it up with my priests if it bothers you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
AN Would it be possible to use sendfile in tftpd? AN With an Athlon XP 1600+ I could only get ~40 Mbps out from the machine AN with 0% idle CPU time (large file transfers from many machines, getting AN the same file). No, sendfile() is only for TCP connections, TFTP is using UDP. If you want performance, use something else. -Tomas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
Hello,
Only if all file transfers were binary, or all ASCII files were stored
on the host with CRLF line termination, instead of LF. That's the
same reason sendfile() is stupid for POP3, IMAP4, and SMTP servers...
Hmm. Both FTP and TFTP supports ASCII and binary transfers, am I right?
In libexec/ftpd this case is handled this way:
case TYPE_A:
while ((c = getc(instr)) != EOF) {
[...]
case TYPE_L:
[...]
while (err != -1 filesize 0) {
err = sendfile(filefd, netfd, offset, 0,
(struct sf_hdtr *) NULL, cnt, 0);
[...]
As far as I can determine.
In libexec/tftpd there is also a similar possibility to handle each case,
because there is netascii and octet.
We have a lab here with machines, which have NICs with built-in bootrom
(Intel PRO/100) and run bpbatch (http://www.bpbatch.org/). During the
startup the user gets a nice menu from which he/she can choose the OS
(various Windows versions for the education and Linux). After this the
program checks the image on the harddisk and if it fails it gets from the
network.
And that's what isn't too good. One client can achieve about 15 Mbps but
if more than 10 (usually 20-30) clients want to fetch the images the TFTP
server first slows down (it eats all the CPU of the server, which is a
fast AthlonXP 1600+) then times out.
I think this could be improved if TFTP could use sendfile().
(I have a busy FTP server and I know how much sendfile() can speed up
things)
The main question here seems to be: could sendfile() be used with UDP, or
it is just for TCP?
BTW, the bpbatch stuff uses binary transfer (according to tcpdump
output)...
[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]---
Attila Nagy e-mail: [EMAIL PROTECTED]
Free Software Network (FSN.HU)phone @work: +361 210 1415 (194)
cell.: +3630 306 6758
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
Hello, No, sendfile() is only for TCP connections, TFTP is using UDP. If you want performance, use something else. It's even in the manpage: Sendfile() sends a regular file specified by descriptor fd out a stream socket specified by descriptor s. Silly me. BTW, I can't use anything else. Are there any alternatives to TFTP for booting machines off the network? (using standard, PC components) Thanks! [ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]--- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
i've had this modified tftpd for some time now, o - it's single threaded - runs as daemon and does not fork new children o - it caches files o - uses mmap o - knows about some of the newer tftp stuff - mainly blocksize. it's been running for some years now, and lately i re-vamped it a bit to run under FreeBSD. ftp://ftp.cs.huji.ac.il/users/danny/tftpd enjoy, danny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
On Tue, Apr 23, 2002 at 12:29:03PM +0200, Attila Nagy wrote: Hello, Would it be possible to use sendfile in tftpd? With an Athlon XP 1600+ I could only get ~40 Mbps out from the machine with 0% idle CPU time (large file transfers from many machines, getting the same file). Performance and tftp don't really go together. The server sends a part of a file, waits for an ack, sends the next piece, waits for an ack, etc. -- Ben An art scene of delight I created this to be ... -- Sun Ra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
Kenneth Culver writes:
OK, I found another problem, here it is:
static void
linux_prepsyscall(struct trapframe *tf, int *args, u_int *code, caddr_t
*params)
{
args[0] = tf-tf_ebx;
args[1] = tf-tf_ecx;
args[2] = tf-tf_edx;
args[3] = tf-tf_esi;
args[4] = tf-tf_edi;
*params = NULL; /* no copyin */
}
Basically, linux_mmap2 takes 6 args, and this looks here like only 5 args are
making it in... I checked this because the sixth argument to linux_mmap2() in
truss was showing 0x6, but when I printed out that arg from the kernel, it
was showing 0x0. Am I correct here?
Ken
Yes. According to http://john.fremlin.de/linux/asm/, linux used to
parse only 5 args but now it parses six. Try adding:
args[5] = tf-tf_ebp;
Drew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
Basically, linux_mmap2 takes 6 args, and this looks here like only 5 args are making it in... I checked this because the sixth argument to linux_mmap2() in truss was showing 0x6, but when I printed out that arg from the kernel, it was showing 0x0. Am I correct here? Ken Yes. According to http://john.fremlin.de/linux/asm/, linux used to parse only 5 args but now it parses six. Try adding: args[5] = tf-tf_ebp; I don't think that arg is there: Apr 23 10:36:13 ken /kernel: tf-tf_ebp = -1077938040 Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
Hello, i've had this modified tftpd for some time now, o - it's single threaded - runs as daemon and does not fork new children Basically, I don't have any problems with the inetd startup. It can be rate limited, etc. o - it caches files How? Doesn't leaving this job to the OS a smarter idea? o - knows about some of the newer tftp stuff - mainly blocksize. I think it's implemented in FreeBSD's tftpd too. (I can get 750 MB images with TFTP easily). My impression about this stuff: compiled and started on an up-to-date FreeBSD STABLE BOX (AthlonXP 1600+, 512MB DDR, two Intel PRO/100 with FEC) The lab consists of 733 MHz Celerons with Intel PRO/100 and 128MB RAM. The switch is a HP4000M. With the FreeBSD tftpd I could only get around 40 Mbps out of this box, the CPU usage was 100%. One client could fetch the stuff with an average speed of 14-15 Mbps. I could stay at this speed with 4-5 machines, fetching the images, after this count the bandwidth usage decreased per machine. With Danny's tftpd I could get 16-17 Mbps with one machine (this is what the client says) and around 4 Mbps per client at a concurrency of 24 machines. That's about 90-96 Mbps. I will try do more benchmarks with an accurate method, once I could figure out what should I use to measure the outgoing traffic to specific IP addresses (a /24 subnet)... BTW, FreeBSD's tftpd doesn't drop connections once it built up, while there are some problems with Danny's implementation in this area, but I am sure that this will be solved very soon. [ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]--- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (and /etc/defaults/rc.conf changes)
Jochem Kossen wrote: Because things evolve? :) You say evolve. I say get broken. How do I know which man page to read? You start X with startx, seems obvious to me. The disabling of tcp connections only applies to startx It's not obvious when one has been starting X with the same command for years and it has never before changed. Gee, seems to seriously violate POLA, eh? OK, then i suggest we mention it in the handbook, the security policy document, the manpage AND the release notes :) Just don't do it in the first place. If you must have this, make a _new_ command (secure-startx, perhaps) and point to it in the release notes. For the simple reason I don't like useless open ports on my system. I don't use it, _most_ other people don't use it, so i sent in a patch. Yeah, but unless one is installing a fresh system, one shouldn't care so much. And, by the way, how do you define useless? To me, having X listening for TCP connections is far from useless. Of course, it was only discussed on the ports@ mailinglist, but it didn't seem like such a big deal to me or apparently the others... This is another case of changing the default in such a way as to violate POLA. I've given this some thought, particularly with respect to the rc.conf changes. My opinion is that, while this kind of thing is a good idea for from-scratch installs (the kind a person new to FreeBSD might be doing), making these changes to a running system is a Really Bad Idea. That means that if you _must_ change the defaults, add overrides at the same time to maintain the old default behavior. Then document the hell out of the new defaults. One shouldn't have to read ancient mail archives or pore over cvs logs to figure out what happened and why. Hey, I'm a kernel programmer (I work on BSD/OS as it happens). I know what it's like to be stuck with obsolete defaults. The fact of the matter is, though, that if I change a default and that upsets our customers, we potentially lose revenue and I potentially lose my job. This gives me real incentive to get it right, and that means not pulling the rug out from under the end user. IMHO, this was botched. Sorry, David, I calls 'em as I see 'em. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY supportconsidered harmful?)
Jochem Kossen wrote: It does work. But i think you mean the tcp connections. Does that mean you vote for enabling _all_ services? They don't work out of the box as well... This is ridiculous. You know as well as I do that that's _not_ what Greg means. Just don't change stuff out from under the users. And don't tell me that X11 is an add-on and luxury. I agree, but the tcp connections IS an add-on luxury imho Wrong. It's the way it works. We are living in the 21st century. That's right, the century of virii, DoS attacks, worms, and scriptkiddiots. Then fix the security holes at your end and leave the rest of to fix them the way _we_ want to. Don't impose your fix on the rest of us by fiat. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
Kenneth Culver writes: Basically, linux_mmap2 takes 6 args, and this looks here like only 5 args are making it in... I checked this because the sixth argument to linux_mmap2() in truss was showing 0x6, but when I printed out that arg from the kernel, it was showing 0x0. Am I correct here? Ken Yes. According to http://john.fremlin.de/linux/asm/, linux used to parse only 5 args but now it parses six. Try adding: args[5] = tf-tf_ebp; I don't think that arg is there: Apr 23 10:36:13 ken /kernel: tf-tf_ebp = -1077938040 Ken My guess is that we're not doing something we should be doing in int0x80_syscall in order to get that last arg. But I do not have enough x86 knowledge to understand how the trapframe is constructed, so I cannot tell what needs to be done. Perhaps somebody with more x86 fu can help. Sorry, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY supportconsidered harmful?)
Robert, it's really, really simple. For new installs, install the new, more secure behavior. Be sure to loudly document this behavior so that those of us who expect the _old_ behavior don't get bitten by the change. And don't change the old behavior in upgrades of existing systems. As I said in my other email, if you _must_ change the defaults, add overrides so the behavior doesn't change. And by add overrides I mean something like an /etc/rc.conf.override file that gets pulled in after /etc/defaults/rc.conf but before /etc/rc.conf. (This says nothing about the necessity or desirability of the change itself, by the way. That's an entirely _different_ argument.) When you change defaults on a running system, you piss off a lot of users. Including me. :-) -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tue, Apr 23, 2002 at 01:16:46PM +0930, Greg 'groggy' Lehey wrote: On Monday, 22 April 2002 at 19:53:06 -0700, Jordan Hubbard wrote: That fix relies on the extensive PAM updates in -CURRENT however; in -STABLE it can probably be similarly replicated via appropriate tweaking of sshd (?). Why not fix it in stable by the very simple tweaking of the ChallengeResponseAuthentication to no in the sshd config file we ship Trust me, this question is going to come up a _lot_ for us otherwise. :( I've been noticing a continuing trend for more and more safe configurations the default. I spent half a day recently trying to find why I could no longer open windows on my X display, only to discover that somebody had turned off tcp connections by default. Debian did this, but they put in a message that tells you that when you install the X server. IIRC, it even tells you what to change, and where. Of course, that might have been because enough people complained... As a sysadmin, I do think this is the right default. (I've worked in environments where people habitually used xhost +) But changing without telling anyone is extremely annoying. I have a problem with this, and as you imply, so will a lot of other people. As a result of this sort of thing, people trying to migrate from other systems will probably just give up. I certainly would have. While it's a laudable aim to have a secure system, you have to be able to use it too. I'd suggest that we do the following: 1. Give the user the choice of these additional features at installation time. Recommend the procedures, but explain that you need to understand the differences. 2. Document these things very well. Both this ssh change and the X without TCP change are confusing. If three core team members were surprised, it's going to surprise the end user a whole lot more. We should at least have had a HEADS UP, and we probably need a security policy document with the distributions. There is a difference: the ssh change doesn't appear to be useful, AFAICS. If anything, it misleads the user into thinking ssh is broken. I'm not sure what, if any, improvement in default security happens as a result. The X change makes it look broken, too, but it really does make a difference in security not to expose your X server to the network by default. Probably more of a difference than what was done to ssh. ---Nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity?
: When you change defaults on a running system, you piss off a lot of users. : Including me. :-) When we fail to take reasonable steps to preclude intruders from gaining access to your system, we'd likely piss you off more if you knew about it :-(. I'll also point out that years ago core created the security-officer to make FreeBSD more secure. One of the charges of the office was to make it more secure out of the box. Now that manmy generations of security officers have made FreeBSD more secure out of the box, you can't go shooting them for doing their job for years :-). The decision to go for a more secure system by default was made years ago. I for one think the Security Officers have done a good job at doing this, but even as far as they have come, I suspect that additional things will be locked down over time. That's the nature of the threats to systems on the internet today. What was acceptible years ago now no longer is acceptible. The attackers are getting more and more sophisticated. The countermeasures for these attacks are necessarily becoming more intrusive as the same sorts of bugs raise their ugly head again and again. BTW, none of this has anything to do with STO. STO is keeping the insecure software in place and relying on attackers to be too stupid to know what to do. That strategy has proven to be bad. The ssh default that started this thread, btw, is stupid, but since I've stepped aside from the SO role, I'll let the current SO deal with it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tue, 23 Apr 2002, Frank Mayhar wrote: Robert, it's really, really simple. For new installs, install the new, more secure behavior. Be sure to loudly document this behavior so that those of us who expect the _old_ behavior don't get bitten by the change. And don't change the old behavior in upgrades of existing systems. As I said in my other email, if you _must_ change the defaults, add overrides so the behavior doesn't change. And by add overrides I mean something like an /etc/rc.conf.override file that gets pulled in after /etc/defaults/rc.conf but before /etc/rc.conf. And I'm saying that in general, we do this for the base system, but we don't have a formalized way of handling that for ports. I suggested that this be something the ports side of the camp needs to work on, perhaps in the form of explicit ports release notes for major ports/widely relevant changes. X11 currently falls into that category, although it doesn't for every system (for example, OpenBSD maintains X11 in-tree with a higher support level, as I understand it). However, I think it's not possible to argue for infinite backward compatibility during upgrades. One minor release is probably the limit of feasibility; major releases are probably not worth dealing with other than via documentation. For example, we make no effort to provide backward compatibility with /etc/sysconfig from the 2.x era. The right model is probably: - For rc.conf, provide limited backward compatibility (1 minor release) - For other configuration files (inetd.conf, for example), simply document the changes During binary upgrades, as well as source-based upgrades, we rely on the administrator to merge the majority of /etc configurations anyway: in general, no change gets made to /etc unless you explicitly perform it. Besides which, backwards compatibility isn't always possible, or desirable. When you upgrade to a new version, you assume that known security vulnerabilities in the old version will be remedied; you expect version increments on various libraries and utilities. This is in many ways no different than normal feature change, it just happens to have a specific motivation that we're generalizing about. (This says nothing about the necessity or desirability of the change itself, by the way. That's an entirely _different_ argument.) When you change defaults on a running system, you piss off a lot of users. Including me. :-) When you change defaults on a running system, that's generally a specific administrative choice you've made. By upgrading the system, you accept that system behavior will change: in fact, you're asking for it to change! FreeBSD has some of the best updating/release notes in the open source space--certainly, more work can be done (especially in the area of ports, which is how this discussion started), but I think you don't want to take the nothing changes, ever philosophy too far. Upgrading a system accepts feature change--I don't think you'll find any vendor who will promise you that following an upgrade, things will be identical. Vendors focus system software upgrades on providing new feature sets, and providing a consist release. Most vendors provide a bumpier feature ride than we do, by virtue of not allowing such fine granularity with upgrades: we permit you to slide slowly forwards on -STABLE, rather than only providing major releases. But by taking advantage of finer granularity and greater access to the in-progress development work, you sacrifice some of the release engineering process. We do have branches that focus on minimal change: those are the release branches that pick up only critical security bugfixes. And even then, you may get feature change. So I'm not disagreeing with you -- I agree, backwards compatibility is important, and that includes the area of configuration files, and especially relating to the last relevant release number. Documentation should be our primary responsibility when it comes to changes, rather than an upgrade path that maintains identical behavior (which is probably not only impossible, but also undesirable). The documented behavior of rc.conf is that if you have a configuration line in there, it's probably paid attention to. If you rely on the system defaults, then when the defaults change, your system changes. If you want to know that a change in defaults won't affect your configuration, explicitly set the setting in rc.conf. We do try to provide compatibility here: for example, there are a number of things in 5.0 that will move from being rc.conf entries to just sysctl.conf entries. However, we're providing backwards compatibility for those settings for at least a minor release. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Changing defaults versus increased security.
M. Warner Losh wrote: : When you change defaults on a running system, you piss off a lot of users. : Including me. :-) When we fail to take reasonable steps to preclude intruders from gaining access to your system, we'd likely piss you off more if you knew about it :-(. Hey, I intentionally said nothing about the desirability of such a change. I just don't believe that changing the defaults of a running system is a good idea. Perhaps changing the defaults for newly-installed systems _is_ a good idea, about that I have no opinion, but when I do a mergemaster and something very basic stops working, it's not more secure, it's just broken. I don't object to more secure systems (far from it), I just object to sudden changes in systems I run. These systems have _already_ been secured against intrusion; like any administrator worth his salt, I've taken steps to secure the borders of my network(s). Inside my network, though, things are less secure because I know I can trust myself. It seems easy enough to create an /etc/rc.overrides script with a large Danger Will Robinson message to annoy a sysadmin into looking at it and containing the old defaults. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Changing defaults versus increased security.
In message: [EMAIL PROTECTED] Frank Mayhar [EMAIL PROTECTED] writes: : It seems easy enough to create an /etc/rc.overrides script with a large : Danger Will Robinson message to annoy a sysadmin into looking at it : and containing the old defaults. There may be a good way to deal with this problem along these lines... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
On Tue, 23 Apr 2002, Attila Nagy wrote: Hello, No, sendfile() is only for TCP connections, TFTP is using UDP. If you want performance, use something else. It's even in the manpage: Sendfile() sends a regular file specified by descriptor fd out a stream socket specified by descriptor s. Silly me. BTW, I can't use anything else. Are there any alternatives to TFTP for booting machines off the network? (using standard, PC components) Multicast! BootIX (nee InCom) have support for this in their BootROMS. it might not be hard to hack into Etherboot et al. Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (and /etc/defaults/rc.conf changes)
On Tuesday 23 April 2002 16:54, Frank Mayhar wrote: Jochem Kossen wrote: Because things evolve? :) You say evolve. I say get broken. Don't tell me that in 11 years, defaults never change How do I know which man page to read? You start X with startx, seems obvious to me. The disabling of tcp connections only applies to startx It's not obvious when one has been starting X with the same command for years and it has never before changed. Gee, seems to seriously violate POLA, eh? I agree, but i still wonder why people didn't come up with it sooner OK, then i suggest we mention it in the handbook, the security policy document, the manpage AND the release notes :) Just don't do it in the first place. If you must have this, make a _new_ command (secure-startx, perhaps) and point to it in the release notes. This is a very good idea IMHO, although without the patch 'startx -nolisten_tcp' works too...Then i'd say rip the patch out completely For the simple reason I don't like useless open ports on my system. I don't use it, _most_ other people don't use it, so i sent in a patch. Yeah, but unless one is installing a fresh system, one shouldn't care so much. And, by the way, how do you define useless? To me, having X listening for TCP connections is far from useless. It is useless to _me_ because i don't use it. Like i said in a previous mail, I didn't like the default, so I sent in the patch as a proposal to the ports@ mailinglist, and they all seemed to like it too. Nobody complained, thus the patch was integrated. Simple. I sent in the patch because it seemed obvious to me to send in a patch which people liked. It was just a proposal. The people responsible and a few others liked it too, and integrated it. Of course, it was only discussed on the ports@ mailinglist, but it didn't seem like such a big deal to me or apparently the others... This is another case of changing the default in such a way as to violate POLA. I've given this some thought, particularly with respect to the rc.conf changes. My opinion is that, while this kind of thing is a good idea for from-scratch installs (the kind a person new to FreeBSD might be doing), making these changes to a running system is a Really Bad Idea. That means that if you _must_ change the defaults, add overrides at the same time to maintain the old default behavior. Then document the hell out of the new defaults. One shouldn't have to read ancient mail archives or pore over cvs logs to figure out what happened and why. I agree. Next time i send in a patch (doesn't happen often ;)) i'll consider this. Hey, I'm a kernel programmer (I work on BSD/OS as it happens). I know what it's like to be stuck with obsolete defaults. The fact of the matter is, though, that if I change a default and that upsets our customers, we potentially lose revenue and I potentially lose my job. This gives me real incentive to get it right, and that means not pulling the rug out from under the end user. IMHO, this was botched. Sorry, David, I calls 'em as I see 'em. David? But ehh...If people really want to change this, could someone file a PR? :) (i can't right now, isp problems... i can only use their mailserver. Besides, i'm not the one complaining) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
On Wed, 24 Apr 2002, Richard Sharpe wrote: Multicast! BootIX (nee InCom) have support for this in their BootROMS. it might not be hard to hack into Etherboot et al. bproc now uses multicast for distributing new kernels and init ram disks, if you want to see an example. It's on sourceforge. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tuesday 23 April 2002 16:57, Frank Mayhar wrote: Jochem Kossen wrote: It does work. But i think you mean the tcp connections. Does that mean you vote for enabling _all_ services? They don't work out of the box as well... This is ridiculous. You know as well as I do that that's _not_ what Greg means. Just don't change stuff out from under the users. True, but this mail wasn't a response to Greg. Over the time i've used FreeBSD, i've seen several services been disabled by default, and i don't see a difference between that and this. Care to explain? And don't tell me that X11 is an add-on and luxury. I agree, but the tcp connections IS an add-on luxury imho Wrong. It's the way it works. Yup, and i didn't like the way it works We are living in the 21st century. That's right, the century of virii, DoS attacks, worms, and scriptkiddiots. Then fix the security holes at your end and leave the rest of to fix them the way _we_ want to. Don't impose your fix on the rest of us by fiat. Excuse me? I thought i sent in a patch which was an improvement. The people responsible thought so too. The patch was a proposal, nothing more, nothing less. I don't care at all wether my patch is in the ports or not, i just thought it was a good idea, so i sent it in. I see nothing wrong in that. If people disagree with the patch, send in a PR and/or remove the patch. That's all there is to it. The patch lives at x11/XFree86-4-libraries/files/patch-startx To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
Attila Nagy wrote:
Only if all file transfers were binary, or all ASCII files were stored
on the host with CRLF line termination, instead of LF. That's the
same reason sendfile() is stupid for POP3, IMAP4, and SMTP servers...
Hmm. Both FTP and TFTP supports ASCII and binary transfers, am I right?
TFTP... sendfile() doesn't work with UDP, anyway.
But anyway... by definition, sendfile can't do the requisite end of
line terminator conversion (CR fro Macintosh, LF for UNIX, CRLF
for Windows/MS-DOS) for FTP/TFTP, and it can't do the end of line
conversion for message stores or mail transfer (SMTP, POP3, and IMAP4
all specify that lines *shall* be terminated by CRLF).
In libexec/ftpd this case is handled this way:
case TYPE_A:
while ((c = getc(instr)) != EOF) {
[...]
case TYPE_L:
[...]
while (err != -1 filesize 0) {
err = sendfile(filefd, netfd, offset, 0,
(struct sf_hdtr *) NULL, cnt, 0);
[...]
As far as I can determine.
Yep. Wouldn't it be nice if it always worked, instead of only
working for binary?
In libexec/tftpd there is also a similar possibility to handle each case,
because there is netascii and octet.
Yeah, but the UDP lets it out, anyway.
[ ... TFTP booting ... ]
And that's what isn't too good. One client can achieve about 15 Mbps but
if more than 10 (usually 20-30) clients want to fetch the images the TFTP
server first slows down (it eats all the CPU of the server, which is a
fast AthlonXP 1600+) then times out.
The answer is probably boot a small image, and use NFS for the
real data, so you don't have to use UDP for the bulk of the data
you have to transfer.
I think this could be improved if TFTP could use sendfile().
(I have a busy FTP server and I know how much sendfile() can speed up
things)
FTP is TCP, not UDP. TFTP magically implements session state
(retransmit/retry) on top of UDP. In other words, it basically
implements the stream delivery you would get with TCP, in user space.
The main question here seems to be: could sendfile() be used with UDP, or
it is just for TCP?
It could probably be used. The retransmits, though, really need
to be built into the protocol, so it's pretty useless for UDP, if
ever you drop a signle packet, since you won't be able to recover.
You would have to implement the code for it.
Probably, the best idea, if you insist on it, is to implement the
TFTP retransmit/acknowledge for the reliable data delivery in the
kernel... as a stream protocol layer on top of UDP. And then
implement sendfile on top of that.
BTW, the bpbatch stuff uses binary transfer (according to tcpdump
output)...
All that means is that you won't have to do data conversion in
that particular case.
UDP datagrams don't really have a window acknowledgement (UDP
datagram delivery is, by definition, unreliable), so you can't
really self-clock the buffer size on the receiver to ensure that
you don't have to do retransmits. You *might* be able to get
around this with the TFTP as a protocol layer hack, but the
window size is one packet, so you're not really going to see a
significant speed improvement, after all the hacking is said and
done. Maybe 12%.
The main win of sendfile() at all is in not eating the window fill
latency by going back to user space, when using sendfile() with
TCP; actually, the overhead savings for using sendfile() can be
had without using sendfile(), for the most port, since the window
is generally large enough and the consumption slow enough that you
end up disk-bound on the sender, or ack-paced by the receiver's
inability to drain the buffer quickly, so you only ever see two
round trip latencies over the whole data stream.
For UDP, you're going to see the round trip latency for each packet
for the individual ACK's, so you're pretty much screwed from the
start, if you use a non-wondowed protocol like TFTP over UDP, at all.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
Attila Nagy wrote: With Danny's tftpd I could get 16-17 Mbps with one machine (this is what the client says) and around 4 Mbps per client at a concurrency of 24 machines. That's about 90-96 Mbps. I will try do more benchmarks with an accurate method, once I could figure out what should I use to measure the outgoing traffic to specific IP addresses (a /24 subnet)... The main thing you will see is that the mmap'ed file pages will be LRU'ed out. Unfortunately, there is not one instance per client. You might do well to madvise() the file, as well, based on the expectation of having multiple sequential transfers of the same data. This assumes that you use the same boot image for each machine, which is advisable (IMO). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Robert Watson wrote: A more conservative default configuration results in a material improvement in system security. I really don't think there's any way to fully protect a security-unconscious user, as if they had spent the time to learn what was necessary, and chosen the right settings for their site. Nothing can replace a system administrator who knows which end is up. I think that trying to do this is doomed to failure, in that it will engender a false sense of security which is, in many cases, unwarranted and dangerous. This is particularly true for FreeBSD, where the first thing anyone ever does with the system is install packages/ports which may themselves have undocumented security vulnerabilities (or even documented ones for which the documentation is ignored). This is particularly true when the system is running X11, as the system *never* *only* runs X11, but instead has all sorts of clients installed, as well, and generally a significant set of unaudited software, such as KDE, which you can attack via CORBA much easier than you could ever hope to directly attack an X11 server, whose defaults already do not permit remote connections through intrinsic access controls in the server (xhost, et. al.). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
On Tue, Apr 23, 2002 at 11:46:34AM -0600, Nate Williams wrote: No, sendfile() is only for TCP connections, TFTP is using UDP. If you want performance, use something else. It's even in the manpage: Sendfile() sends a regular file specified by descriptor fd out a stream socket specified by descriptor s. Silly me. BTW, I can't use anything else. Are there any alternatives to TFTP for booting machines off the network? (using standard, PC components) USE TFTP to get a tiny image up, and then go TCP. There are also lightweight TCP stacks that fit in 8K or 16K; you could come up with your own protocol, or decide to use FTP instead of TFTP for the download. In general, the faster you get to something TCP based, the happier you will be, so if you *must* use TFTP, then make the boot image really, really small. Going to TCP soon assumes that you have a lossless medium in order to transmit packets over. If you're using a lossy medium, TFTP (and other UDP based protocols) can kick their butt because of TCP's assumption that packet loss is a function of congestion, which is often not the case in lossy mediums such as wirless. :( tftp in particular probably won't, because it uses the same packet window concept as TCP, but with the window set to 1. It is a protocol that is braindead by design, in order to be simple to implement. It was never pretended that performance was a design goal. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (and /etc/defaults/rc.conf changes)
Jochem Kossen wrote: On Tuesday 23 April 2002 16:54, Frank Mayhar wrote: Jochem Kossen wrote: Because things evolve? :) You say evolve. I say get broken. Don't tell me that in 11 years, defaults never change When the routing code was changed, back in the mid 1990's, X.25 and ISODE were both broken, for lack of maintenance: the changes were not made globally. X.25 and ISODE were then removed due to bit rot. The entire idea of bit rot is really the code did not keep ``up to date'' with my changes, which broke the code, which is really a ridiculous position. It really pissed me off when the AHA-1742 support dropped out when CAM came in, but that, at least, was understandable, since it was a trade: something deisrable for something less desirable to the majority of users. You really *can not* blame breaking something that used to work but which no longer works on evolution. It's not obvious when one has been starting X with the same command for years and it has never before changed. Gee, seems to seriously violate POLA, eh? I agree, but i still wonder why people didn't come up with it sooner Mostly, because most people don't run -current, and because the X11 distribution is not nearly as modular as it should be, if this type of change is to be generally permitted. Just don't do it in the first place. If you must have this, make a _new_ command (secure-startx, perhaps) and point to it in the release notes. This is a very good idea IMHO, although without the patch 'startx -nolisten_tcp' works too...Then i'd say rip the patch out completely That handles this particular case, but dodges the general policy issue ...which I guess is the point: Never put off until tomorrow what you can put off indefinitely ;^). It is useless to _me_ because i don't use it. Like i said in a previous mail, I didn't like the default, so I sent in the patch as a proposal to the ports@ mailinglist, and they all seemed to like it too. Nobody complained, thus the patch was integrated. Simple. Not the most likely place for X11 people to see the issue and become involved in a discussion: X11 is unfortunately not a proper port in the common case, but is rather a set of distfiles: a tar archive split into chunks, and managed by sysinstall. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
[ TFTP performance is poor ] USE TFTP to get a tiny image up, and then go TCP. Going to TCP soon assumes that you have a lossless medium in order to transmit packets over. If you're using a lossy medium, TFTP (and other UDP based protocols) can kick their butt because of TCP's assumption that packet loss is a function of congestion, which is often not the case in lossy mediums such as wirless. :( tftp in particular probably won't, because it uses the same packet window concept as TCP, but with the window set to 1. Actually, it still tends to kick TCP's butt in very lossy networks, because or resends and other vaguaries of TCP. We've done benchmarks, and when packet loss gets bad, TCP backoff algorithm (which causes window size shrinkage *and* increases in resend delays) cause TCP to slow to a crawl. We've found that TFTP's timeouts tend to work better, although it may be more an issue of having the lower overhead vs. TCP. It is a protocol that is braindead by design, in order to be simple to implement. It was never pretended that performance was a design goal. Completely agreed on that point. Another point worth mentioning is that it's rather trivial to add in some extensions to TFTP (that are backwards compatible) to speed it up by increasing the window size to even 2 packets. We were able to do that and it almost halved the transfer times. :) However, it required slight modifications on the part of the sender, and the ability to recognize when the double window size modification had to be disabled because certain (very slow) pieces of hardware couldn't handle even the slight speedup of packets. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
Nate Williams wrote: Going to TCP soon assumes that you have a lossless medium in order to transmit packets over. If you're using a lossy medium, TFTP (and other UDP based protocols) can kick their butt because of TCP's assumption that packet loss is a function of congestion, which is often not the case in lossy mediums such as wirless. :( THat's true. I can't really think of an example of such a medium, though, that you would still trust to netboot something. 8-). Maybe 802.11b. 8-(. The specific problem here is that UDP is ``too slow''; it looks like a classic Doctor, it hurts when I do this 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Erm, since everyone managed to HIJACK my sshd thread! ;)
I'm going to commit the following in 48 hours unless someone can convince me that it's a good idea for FreeBSD to be the odd-OS out with respect to this behavior: Index: sshd_config === RCS file: /home/ncvs/src/crypto/openssh/sshd_config,v retrieving revision 1.4.2.6 diff -u -r1.4.2.6 sshd_config --- sshd_config 28 Sep 2001 01:33:35 - 1.4.2.6 +++ sshd_config 23 Apr 2002 18:38:01 - @@ -48,8 +48,8 @@ PasswordAuthentication yes PermitEmptyPasswords no -# Uncomment to disable s/key passwords -#ChallengeResponseAuthentication no +# Comment out to enable s/key passwords +ChallengeResponseAuthentication no # To change Kerberos options #KerberosAuthentication no To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
Going to TCP soon assumes that you have a lossless medium in order to transmit packets over. If you're using a lossy medium, TFTP (and other UDP based protocols) can kick their butt because of TCP's assumption that packet loss is a function of congestion, which is often not the case in lossy mediums such as wireless. :( THat's true. I can't really think of an example of such a medium, though, that you would still trust to netboot something. 8-). Maybe 802.11b. 8-(. Exactly! Or, something that boots remotely over satellite (for easier maintenance). The specific problem here is that UDP is ``too slow''; it looks like a classic Doctor, it hurts when I do this 8-) 8-). Actually, UDP is actually *faster* than TCP in these sorts of environments, if you know what you are doing. :) :) :) :) Overhead during a demo of my former company was demo'ing a product to a client, while the client was talking to our competitor. 'Hmm, how come your product doesn't do anything, when their product seems to be working fine here.'. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Erm, since everyone managed to HIJACK my sshd thread! ;)
* Jordan Hubbard [EMAIL PROTECTED] [020423 11:39] wrote: I'm going to commit the following in 48 hours unless someone can convince me that it's a good idea for FreeBSD to be the odd-OS out with respect to this behavior: Please do it. Index: sshd_config === RCS file: /home/ncvs/src/crypto/openssh/sshd_config,v retrieving revision 1.4.2.6 diff -u -r1.4.2.6 sshd_config --- sshd_config 28 Sep 2001 01:33:35 - 1.4.2.6 +++ sshd_config 23 Apr 2002 18:38:01 - @@ -48,8 +48,8 @@ PasswordAuthentication yes PermitEmptyPasswords no -# Uncomment to disable s/key passwords -#ChallengeResponseAuthentication no +# Comment out to enable s/key passwords +ChallengeResponseAuthentication no # To change Kerberos options #KerberosAuthentication no To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tue, 23 Apr 2002, Terry Lambert wrote: Robert Watson wrote: A more conservative default configuration results in a material improvement in system security. I really don't think there's any way to fully protect a security-unconscious user, as if they had spent the time to learn what was necessary, and chosen the right settings for their site. Nothing can replace a system administrator who knows which end is up. I'll agree with the assertion that users unaware of a security threat, or unwilling to address a threat, are hard to prevent from shooting themselves in the feet. I think that trying to do this is doomed to failure, in that it will engender a false sense of security which is, in many cases, unwarranted and dangerous. This is particularly true for FreeBSD, where the first thing anyone ever does with the system is install packages/ports which may themselves have undocumented security vulnerabilities (or even documented ones for which the documentation is ignored). System programming is hard, let's go shopping. Here I'll disagree with you: we make a concerted effort to produce a system that is safe to use. This involves a number of things, and it doesn't just mean security fixes. I would argue that we have a moral obligation to do so. Sure, we can't fix every port or package, but we do actually make an effort to take a look through the more important/common ones for obvious problems, and we are trying to move to architectures that permit ports that have previously required privilege to run with less privilege. For example, one of the projects Thomas Moestl worked on on the -CURRENT branch was to reduce the reliance on kmem access for system monitoring tools. The result is that base system tools (such as top) can now often run without any extra privilege. But a positive side effect is that many non-base system tools can also run without privilege they previously required. Someone who's unaware or unwilling to address security issues will *still* be safer if we provide a safer system. If they are going maliciously out of their way, sure, there will be problems, but if they don't need telnet, and we disable telnet by default, we have actually produced a safer system for them. And if they do need telnet, it's easy to turn on. This is particularly true when the system is running X11, as the system *never* *only* runs X11, but instead has all sorts of clients installed, as well, and generally a significant set of unaudited software, such as KDE, which you can attack via CORBA much easier than you could ever hope to directly attack an X11 server, whose defaults already do not permit remote connections through intrinsic access controls in the server (xhost, et. al.). I think you've correctly identified an area where a lot of future security work is needed. However, that doesn't negate the need for security work in the base system, because without a secure base system, you're building everything else on sand. If you have the time and resources to spend helping to kick KDE and its related dependencies into shape, I welcome your doing that. It's something I haven't had time to work with yet, but have definite future plans to do. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Erm, since everyone managed to HIJACK my sshd thread! ;)
PLEASE commit this :-) It's so annoying. Ken On Tue, 23 Apr 2002, Jordan Hubbard wrote: I'm going to commit the following in 48 hours unless someone can convince me that it's a good idea for FreeBSD to be the odd-OS out with respect to this behavior: Index: sshd_config === RCS file: /home/ncvs/src/crypto/openssh/sshd_config,v retrieving revision 1.4.2.6 diff -u -r1.4.2.6 sshd_config --- sshd_config 28 Sep 2001 01:33:35 - 1.4.2.6 +++ sshd_config 23 Apr 2002 18:38:01 - @@ -48,8 +48,8 @@ PasswordAuthentication yes PermitEmptyPasswords no -# Uncomment to disable s/key passwords -#ChallengeResponseAuthentication no +# Comment out to enable s/key passwords +ChallengeResponseAuthentication no # To change Kerberos options #KerberosAuthentication no To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Robert Watson wrote: System programming is hard, let's go shopping. This is exactly the phrase that comes to mind every time someone yanks the plug on a service they are afraid might one day have an exploit found for it. Someone who's unaware or unwilling to address security issues will *still* be safer if we provide a safer system. If they are going maliciously out of their way, sure, there will be problems, but if they don't need telnet, and we disable telnet by default, we have actually produced a safer system for them. And if they do need telnet, it's easy to turn on. Securing telnet is hard; let's turn it off and go shopping. 8-). I think you've correctly identified an area where a lot of future security work is needed. However, that doesn't negate the need for security work in the base system, because without a secure base system, you're building everything else on sand. If you have the time and resources to spend helping to kick KDE and its related dependencies into shape, I welcome your doing that. It's something I haven't had time to work with yet, but have definite future plans to do. No one has *that* much time. Auditing that code base would be on the order of the difficulty of auditing Windows, and we have the source code the KDE. I agree that the base system needs to be secure, but I think you either trust your security model, or you don't: X11 *does* have a security model, even if it doesn't encrypt all the traffic over all its connections by default. If the security model is flawed, then it needs to be fixed, not turned off. I think it's a lot worse to leave a vulnerable telnetd turned off by default but available to be turned on, than to have one that's non-vulnerable turned on by default. The fear that someone is going to find a vulnerability should be balanced by the idea that someone is going to fix it, not balanced by the idea that that you can hide the vulnerability by not running the vulnerable code, mostly. I guess this is a basica philosophical difference: IMO, exposure equals the probability of a fix. Turning things off belongs in the firewall code. FWIW: I wouldn't object to a firewall rule that disallowed remote TCP connections to the X server by default, if the firewall is enabled. I think we already have this... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Erm, since everyone managed to HIJACK my sshd thread! ;)
In [EMAIL PROTECTED], Jordan Hubbard [EMAIL PROTECTED] typed: I'm going to commit the following in 48 hours unless someone can convince me that it's a good idea for FreeBSD to be the odd-OS out with respect to this behavior: If someone objects, let me know and I'll pay them a visit with a baseball bat and explain things to them. mike Index: sshd_config === RCS file: /home/ncvs/src/crypto/openssh/sshd_config,v retrieving revision 1.4.2.6 diff -u -r1.4.2.6 sshd_config --- sshd_config 28 Sep 2001 01:33:35 - 1.4.2.6 +++ sshd_config 23 Apr 2002 18:38:01 - @@ -48,8 +48,8 @@ PasswordAuthentication yes PermitEmptyPasswords no -# Uncomment to disable s/key passwords -#ChallengeResponseAuthentication no +# Comment out to enable s/key passwords +ChallengeResponseAuthentication no # To change Kerberos options #KerberosAuthentication no To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
In [EMAIL PROTECTED], Jochem Kossen [EMAIL PROTECTED] typed: On Tuesday 23 April 2002 11:04, you wrote: OK, then i suggest we mention it in the handbook, the security policy document, the manpage AND the release notes :) None of those are things that are on the Must read list for people tracking -STABLE, instead of -RELEASE. I believe UPDATING is the only such document. FWIW, I ran into this, and asked about it on -questions. Got the solution, then finally got around to making ssh forward X11 properly so I no longer use it. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
Nate Williams wrote: Maybe 802.11b. 8-(. Exactly! Or, something that boots remotely over satellite (for easier maintenance). Or cable modems, booting from the cable plant. Actually, there's a lot of uses, the more you think about it, even though I think you'd have to be pretty insane to let someone dictate what software you run in your network access device. I guess cell phone users put up with it, though... it looks like Verizon and Qualcomm and a couple of others are now writing their contracts so they can download new crap to your phone and rearrrange your menus without your permission, or make you have to scroll through an advertisement before you can dial, etc.. I just keep thinking of some jerk on my cable segment responding to the boot me request, and proxying to the real cable plant. 8-(. The specific problem here is that UDP is ``too slow''; it looks like a classic Doctor, it hurts when I do this 8-) 8-). Actually, UDP is actually *faster* than TCP in these sorts of environments, if you know what you are doing. :) :) :) :) Overhead during a demo of my former company was demo'ing a product to a client, while the client was talking to our competitor. 'Hmm, how come your product doesn't do anything, when their product seems to be working fine here.'. 8-) 8-). I love that when that happens... Um, uh, er -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
More about security, X, rc.conf and changing defaults.
Terry Lambert wrote: FWIW: I wouldn't object to a firewall rule that disallowed remote TCP connections to the X server by default, if the firewall is enabled. I think we already have this... Yep, I agree, and whether or not it's in the distributed rc.firewall, I have the ports blocked in my hand-tuned version. As to Stijn's remarks, he is putting up a strawman at best. If a person runs X, it should be their responsibility to make sure that it's secure. Just like if they ran Windows or any other software with potential security holes. X is plastered with warnings as it is, why do we need to cripple a function it supports? Stijn, if it opens up a hole in your network, that's _your_ problem, not mine. There are many other ways to secure your network than by turning off tcp connections by default in the X server. Hey, I'm not objecting to adding the capability, I'm just objecting to the fact that it was imposed upon everyone else by fiat and (worse) without warning. And before people start saying again that this only affects a port and is irrelevant to the operating system itself, this is one symptom of what I see as a worsening problem. I agree with Warner that the former default should only be supported until the next major release, but that former default _should be supported_. Yeah, it's up to me as a sysadmin to notice this stuff and fix it, but how many people pay that much attention to the stuff in /etc/defaults when they are in the middle of upgrading a bread-and- butter system (to get it closer to the current -stable, so later improvements won't be so difficult to bring in) and are going as fast as they can? Much better, IMNSHO, to create the new /etc/rc.override (or whatever) script and let it bug the admin about the fact that the defaults have changed. And _not_ spring this sort of thing on the FreeBSD world unawares. Not all of us have time to pay attention to the mailing lists (or even _one_ of the mailing lists) to catch this sort of thing before it gets committed. Hey, I'm a software engineer for Wind River (with a fulltime job there), plus sole engineer and sysadmin for my own side business. I barely have time for _sleep_. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
On Tue, Apr 23, 2002 at 12:34:24PM -0600, Nate Williams wrote: [ TFTP performance is poor ] USE TFTP to get a tiny image up, and then go TCP. Going to TCP soon assumes that you have a lossless medium in order to transmit packets over. If you're using a lossy medium, TFTP (and other UDP based protocols) can kick their butt because of TCP's assumption that packet loss is a function of congestion, which is often not the case in lossy mediums such as wirless. :( tftp in particular probably won't, because it uses the same packet window concept as TCP, but with the window set to 1. Actually, it still tends to kick TCP's butt in very lossy networks, because or resends and other vaguaries of TCP. We've done benchmarks, and when packet loss gets bad, TCP backoff algorithm (which causes window size shrinkage *and* increases in resend delays) cause TCP to slow to a crawl. We've found that TFTP's timeouts tend to work better, although it may be more an issue of having the lower overhead vs. TCP. This is an issue with TCP in your situation. You're playing with network equipment TCP wasn't designed for, and noticing that TCP isn't anywhere near perfect. It's relatively simple (see OSI before you disagree...), and optimized for common network technology at the time it was designed. (And sometimes those optimizations work...) There are things it doesn't fit well. A connection-less reliable datagram protocol might have been a better choice for http, for example. It is a protocol that is braindead by design, in order to be simple to implement. It was never pretended that performance was a design goal. Completely agreed on that point. Another point worth mentioning is that it's rather trivial to add in some extensions to TFTP (that are backwards compatible) to speed it up by increasing the window size to even 2 packets. We were able to do that and it almost halved the transfer times. :) Probably true, but the better solution is to find something else (or make something else) that doesn't completely suck like TFTP does. However, it required slight modifications on the part of the sender, and the ability to recognize when the double window size modification had to be disabled because certain (very slow) pieces of hardware couldn't handle even the slight speedup of packets. I suspect that you might be better off solving your lossy network issues with a layer under IP, rather than tinkering with the protocols that sit on top. Maybe a module for netgraph that does some retransmit handshaking optimized for your particular needs. ---Nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
Basically, linux_mmap2 takes 6 args, and this looks here like only 5 args are making it in... I checked this because the sixth argument to linux_mmap2() in truss was showing 0x6, but when I printed out that arg from the kernel, it was showing 0x0. Am I correct here? Ken Yes. According to http://john.fremlin.de/linux/asm/, linux used to parse only 5 args but now it parses six. Try adding: args[5] = tf-tf_ebp; I don't think that arg is there: Apr 23 10:36:13 ken /kernel: tf-tf_ebp = -1077938040 Ken My guess is that we're not doing something we should be doing in int0x80_syscall in order to get that last arg. But I do not have enough x86 knowledge to understand how the trapframe is constructed, so I cannot tell what needs to be done. Perhaps somebody with more x86 fu can help. Sorry, Crap, I don't know what's going on either, I was just looking at the asm in src/sys/i386/i386/exception.s, but I'm not very good with asm either, Can anyone help? I'm cross-posting to -current since nobody on hackers or emulation is able to help. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Problems with nge driver and copper GbE cards
I am evaluating copper GbE cards for our lab. According to previous talk threads, it seems that SMC9462TX has better performance than NetGear cards. I bought two SMC9462TX cards and connect them through a Cat 5e cross-link cable. The machines in use are two dual PIII 733Mhz with 756MB memory. I use 32bit/33Mhz PCI slots. I know PCI bus of 32bit/33Mhz is slow but the major purpose of evaluation is to compare the performance between copper and Fiber GbE cards. There are another two identical dual PIII 733Mhz machines installed NetGear 620 Fiber GbE cards(using ti driver). So it is not an issue. I am using FreeBSD 4.5 and statically link nge driver into the kernel. First, there are a lot of link up messages from nge driver. I guess this has been reported. I use a small program to measure TCP performance. Basically, it sends 1G or 2G data over the network and calculate time and bit rate. The link between two copper GbE cards became unavailable after some TCP runs. There is no response from ping. The kernel didn't report error messages except some new link up messages. There is no abnormal from the output of ifconfig -a. Based on some suggestions(master or slave mode), I issued command ifconfig nge0 link0. The link would be back sometimes but not always. Did anyone suffer the same problem? Second, it seems that the link is more stable with UDP traffic though it became unavailable now and then. I could manage to collect some UPD performance data: UDP performance(sender) w/o jumbo frame w/ jumbo frame copper GbE 510Mb/s 632Mb/s (SMC9462Tx) Fiber GbE750Mb/s 856Mb/s (GA 620) (Note: data are from the results of netperf and shared the same parameters). Did anybody knows why copper GbE cards are so slow? Both copper and Fiber GbE cards are in the same kind of PCI slot and identical machines. The extra memory on GA620 should not cause 40-50% difference in my opinion. Third, I had trouble to set half-duplex mode on nge0. If I issued command ifconfig nge0 media 1000baseTX mediaopt half-duplex, I got the following error message ifconfig: SIOCSIFMEDIA: Device not configured I don't have trouble to issue command ifconfig nge0 media 1000baseTX mediaopt full-duplex. thanks, --Fengrui To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Erm, since everyone managed to HIJACK my sshd thread! ;)
FWIW, I agree with you, but I'm more interested in fixing this right now than I am in chasing the OpenSSH maintainers around with patches (unless we've already forked - have we?). I'll also be happy to change this twice if it turns out that getting the change into OpenSSH is easier than I thought, but I don't want just having this be fixed contingent on that. - Jordan Jordan Hubbard wrote: I'm going to commit the following in 48 hours unless someone can convince me that it's a good idea for FreeBSD to be the odd-OS out with respect to this behavior: [ ... ] -# Uncomment to disable s/key passwords -#ChallengeResponseAuthentication no +# Comment out to enable s/key passwords +ChallengeResponseAuthentication no IMO, the default, in the absence of an option, should be no. So the patch should both set the default in the source code, and change the file, like so: -# Uncomment to disable s/key passwords -#ChallengeResponseAuthentication no +# Uncomment to enable s/key passwords +#ChallengeResponseAuthentication yes -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
[ TFTP performance is poor ] USE TFTP to get a tiny image up, and then go TCP. Going to TCP soon assumes that you have a lossless medium in order to transmit packets over. If you're using a lossy medium, TFTP (and other UDP based protocols) can kick their butt because of TCP's assumption that packet loss is a function of congestion, which is often not the case in lossy mediums such as wirless. :( tftp in particular probably won't, because it uses the same packet window concept as TCP, but with the window set to 1. Actually, it still tends to kick TCP's butt in very lossy networks, because or resends and other vaguaries of TCP. We've done benchmarks, and when packet loss gets bad, TCP backoff algorithm (which causes window size shrinkage *and* increases in resend delays) cause TCP to slow to a crawl. We've found that TFTP's timeouts tend to work better, although it may be more an issue of having the lower overhead vs. TCP. This is an issue with TCP in your situation. You're playing with network equipment TCP wasn't designed for, and noticing that TCP isn't anywhere near perfect. It's relatively simple (see OSI before you disagree...), and optimized for common network technology at the time it was designed. (And sometimes those optimizations work...) Yer' preachin to the choir here. :) There are things it doesn't fit well. A connection-less reliable datagram protocol might have been a better choice for http, for example. You mean like TTCP? Unfortunately, it wasn't available, and because of inertia, it will probably never happen. :( It is a protocol that is braindead by design, in order to be simple to implement. It was never pretended that performance was a design goal. Completely agreed on that point. Another point worth mentioning is that it's rather trivial to add in some extensions to TFTP (that are backwards compatible) to speed it up by increasing the window size to even 2 packets. We were able to do that and it almost halved the transfer times. :) Probably true, but the better solution is to find something else (or make something else) that doesn't completely suck like TFTP does. Because it's used so rarely, having it suck every once in a while isn't so bad. TFTP is well supported natively in lots of hardware platforms, so rather than re-inventing the wheel over and over again, we chose to continue using what other vendors have used, but we 'optimized' it for our situation. That's called 'good engineering' in my book. :) However, it required slight modifications on the part of the sender, and the ability to recognize when the double window size modification had to be disabled because certain (very slow) pieces of hardware couldn't handle even the slight speedup of packets. I suspect that you might be better off solving your lossy network issues with a layer under IP, rather than tinkering with the protocols that sit on top. Actually, I disagree. IP is all about routing, and since we still want packets routed correctly, something on top of IP *is* the best solution. (Check out your OSI model. :) In any case, even writing my own 'RDP' (Reliable Datagram Protocol) on top of IP was massive overkill. It means messing around with the stack on every OS used in the product (which includes Windoze). Most of the stacks are *NOT* written with extensibility in mind, even assuming you can get your hands on the source code. The amount of resources (both in terms of finding people with enough expertise as well as the time to do proper testing) to do such a task is beyond the scope of almost any hardware vendor. Been there, done that, only going to do it again if it makes sense... Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Erm, since everyone managed to HIJACK my sshd thread! ;)
Have we forked OpenSSH? Can I just make the change to our local tree? I really don't want to have to deal with the OpenSSH folks over at openbsd.org. They bite. :) - Jordan --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 23, 2002 at 11:39:01AM -0700, Jordan Hubbard wrote: I'm going to commit the following in 48 hours unless someone can convince me that it's a good idea for FreeBSD to be the odd-OS out with respect to this behavior: Don't change the defaults in sshd_config, change the defaults in the sshd code (and update the commented-out entry in sshd_config to match the new defaults, if appropriate). sshd should work exactly the same with the default sshd_config file present or without any sshd_config file at all. Kris --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8xbdlWry0BWjoQKURAjVOAKCddmAebajzTioCXRcZWY523gNpZACgz4QQ ieQJBpKxOwdfcfe9IH9BR+Y= =hS6R -END PGP SIGNATURE- --6c2NcOVqGQ03X4Wi-- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: More about security, X, rc.conf and changing defaults.
On Tue, 23 Apr 2002, Frank Mayhar wrote: Terry Lambert wrote: FWIW: I wouldn't object to a firewall rule that disallowed remote TCP connections to the X server by default, if the firewall is enabled. I think we already have this... Yep, I agree, and whether or not it's in the distributed rc.firewall, I have the ports blocked in my hand-tuned version. As to Stijn's remarks, he is putting up a strawman at best. If a person runs X, it should be their responsibility to make sure that it's secure. Just like if they ran Windows or any other software with potential security holes. X is plastered with warnings as it is, why do we need to cripple a function it supports? Stijn, if it opens up a hole in your network, that's _your_ problem, not mine. There are many other ways to secure your network than by turning off tcp connections by default in the X server. Hey, I'm not objecting to adding the capability, I'm just objecting to the fact that it was imposed upon everyone else by fiat and (worse) without warning. And before people start saying again that this only affects a port and is irrelevant to the operating system itself, this is one symptom of what I see as a worsening problem. I agree also. Remember what has been stated before, Tools, not Policy. If we want to disable this by default, then there should be a customary knob _where people expect/can see it_. And if we are lacking the mechanism to do it, then the change should wait until it is present. It shouldn't be hacked into an unexpected place. I would like to see this backed out. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
On Tue, Apr 23, 2002 at 02:07:32PM -0600, Nate Williams wrote: Probably true, but the better solution is to find something else (or make something else) that doesn't completely suck like TFTP does. Because it's used so rarely, having it suck every once in a while isn't so bad. TFTP is well supported natively in lots of hardware platforms, so rather than re-inventing the wheel over and over again, we chose to continue using what other vendors have used, but we 'optimized' it for our situation. That's called 'good engineering' in my book. :) That's what everyone else said, and why that stupid protocol still exists. However, it required slight modifications on the part of the sender, and the ability to recognize when the double window size modification had to be disabled because certain (very slow) pieces of hardware couldn't handle even the slight speedup of packets. I suspect that you might be better off solving your lossy network issues with a layer under IP, rather than tinkering with the protocols that sit on top. Actually, I disagree. IP is all about routing, and since we still want packets routed correctly, something on top of IP *is* the best solution. (Check out your OSI model. :) Why should routing enter into it? Ethernet is a pretty mindless MAC layer, but there are others like PPP or Token Ring that aren't, and IP runs fine over them. LLC2 does something similar to what you'd need, although I don't think it'd be the right choice. In any case, even writing my own 'RDP' (Reliable Datagram Protocol) on top of IP was massive overkill. It means messing around with the stack on every OS used in the product (which includes Windoze). Most of the stacks are *NOT* written with extensibility in mind, even assuming you can get your hands on the source code. On Windows, you could put that RDP layer into the network driver, and not mess with the rest of the network stack. Or, perhaps write a driver that sits between an existing network driver and the IP stack. I did something like that with DOS drivers once. The amount of resources (both in terms of finding people with enough expertise as well as the time to do proper testing) to do such a task is beyond the scope of almost any hardware vendor. Been there, done that, only going to do it again if it makes sense... Sounds suspiciously like a problem with the standard for your medium. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
[ moved to -chat, since this has no business being in -hackers anymore ] Probably true, but the better solution is to find something else (or make something else) that doesn't completely suck like TFTP does. Because it's used so rarely, having it suck every once in a while isn't so bad. TFTP is well supported natively in lots of hardware platforms, so rather than re-inventing the wheel over and over again, we chose to continue using what other vendors have used, but we 'optimized' it for our situation. That's called 'good engineering' in my book. :) That's what everyone else said, and why that stupid protocol still exists. No, it exists because it's good enough to do the job. It's not optimal, but it's good enough. Optimal for all situations means re-inventing TCP over and over again, which is non-optimal from an engineering point of view, IMO. However, it required slight modifications on the part of the sender, and the ability to recognize when the double window size modification had to be disabled because certain (very slow) pieces of hardware couldn't handle even the slight speedup of packets. I suspect that you might be better off solving your lossy network issues with a layer under IP, rather than tinkering with the protocols that sit on top. Actually, I disagree. IP is all about routing, and since we still want packets routed correctly, something on top of IP *is* the best solution. (Check out your OSI model. :) Why should routing enter into it? Because that is what IP does. IP's job is to route packets. No reliability, no streaming, no nothing. It just makes sure a packets gets from point A to point B. (See your ISO layering pictures and descriptions.) Ethernet is a pretty mindless MAC layer, but there are others like PPP or Token Ring that aren't, and IP runs fine over them. And your point is? In any case, even writing my own 'RDP' (Reliable Datagram Protocol) on top of IP was massive overkill. It means messing around with the stack on every OS used in the product (which includes Windoze). Most of the stacks are *NOT* written with extensibility in mind, even assuming you can get your hands on the source code. On Windows, you could put that RDP layer into the network driver, and not mess with the rest of the network stack. Or, perhaps write a driver that sits between an existing network driver and the IP stack. I did something like that with DOS drivers once. Yer preaching to the choir. It's *WAY* too much for *WAY* too little gain. On top of it, it's non-portable. The amount of resources (both in terms of finding people with enough expertise as well as the time to do proper testing) to do such a task is beyond the scope of almost any hardware vendor. Been there, done that, only going to do it again if it makes sense... Sounds suspiciously like a problem with the standard for your medium. ??? It's my job to provide optimum solutions to my employer, using the least amount of both my resources and their resources. In other words, if we were in a perfect world, with no time schedules, and infinite resources, a perfect solution as you suggest might be a good idea. But, unfortunately (or fortunately, depending on your perspective), I have to work with what I got, since I've got a zillion others things to do besides trying to perfect a file transfer protocol that is used less than .01% of the time in the lifetime of the product. I'd rather spend my time optimizing the other 99.99% of the functionality of the product, since that's what most of my customer's are more concerned with. Some would call this good engineering, but apparently you aren't in that group. In another product at another company, I messed with perfecting a data transfer protocol that worked over wireless mediums. Like it or not, loss is not only common, it's considered acceptable. In that case, because of design considerations (it must run on legacy hardware running on legacy software, ie; any pc running any version of Win95/98), messing with device drivers is simply unfeasible. So, you work with what you got, which means a standard TCP/IP stack, with no additions. Amazingly enough, both products *work* despite all of the limitations. I know it might be hard for you to believe that one *can* provide a working solution without resorting to OS hacking, but it is not only possible, sometimes it's actually fun. :) Nate ps. I've done my share of kernel hacking, and my current job is *all* kernel hacking, but just because I have a hammer in my toolbox doesn't mean that every problem looks like a nail. :) :) :) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity?
On 2002-04-23 09:49, M. Warner Losh wrote: The decision to go for a more secure system by default was made years ago. I for one think the Security Officers have done a good job at doing this, but even as far as they have come, I suspect that additional things will be locked down over time. That's the nature of the threats to systems on the internet today. What was acceptible years ago now no longer is acceptible. The attackers are getting more and more sophisticated. The countermeasures for these attacks are necessarily becoming more intrusive as the same sorts of bugs raise their ugly head again and again. Very well said. Cutting functionality for the sake of security is the growing trend in today's unsafe, untrusted environment that we like calling the Internet. Things that were the default years ago are now considered silly at best, dangerous for the entire network at worst. As attacks get more sophisticated, the expected functionality of a ``default'' installation is trimmed down to avoid starting dangerous or exploitable services. This is not the first time that the need to lose part of the flexibility of a Unix system is necessary to avoid problems. Note that years ago, Sendmail would relay mail from anyone in its default installation. That was a useful feature of Unix servers around the world. Today, being an open relay is considered dangerous, and we blacklist those that run open relays. Some times, it's necessary to lose flexibility and functionality in the default installation, for the sake of security. Bearing in mind that TCP connection support is not removed from the X11 servers, but merely disabled, is this so very important? - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEYsupport considered harmful?)
At 2:37 PM -0400 4/23/02, Robert Watson wrote: Here I'll disagree with you: we make a concerted effort to produce a system that is safe to use. This involves a number of things, and it doesn't just mean security fixes. I would argue that we have a moral obligation to do so. I agree that there is this obligation. I also observe that the internet is unquestionably getting to be a more hostile place, and we have to adapt the system to stand up to that hostility. Let me claim that it is fact that we will have to make changes to the default system configuration, and that we will also have to make changes to the preferred system configurations when someone is just upgrading. I recognize that some people disagree with that (particularly the second half), but let me claim that for the moment. I think an important component of any such change is making sure the right people find out what changed, and that they get this information when they *need* it, and not as part of some 20,000 line README file which we know no one will read because it's too damn big. In the case of the sshd change, the change was simply wrong and should be fixed. Just MO... :-) In the case of the 'startx -listen_tcp' option, is there some thing we could set up so a person who *wanted* the former behavior is given quick notification of exactly why things suddenly stopped working. Note that the person who runs into the problem is not necessarily the same person who did the system upgrade. I think it's doable, if we just took the attitude that it needed to be done. Some of these changes catch me offguard too, and most of the time it is not the change itself which bothers me, it's the six hours I spent trying to find out why something stopped working. (a six-hour period which may not start until a week or two after the system upgrade...) I think that's the part we need to improve on. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tue, 23 Apr 2002, Terry Lambert wrote: Robert Watson wrote: System programming is hard, let's go shopping. This is exactly the phrase that comes to mind every time someone yanks the plug on a service they are afraid might one day have an exploit found for it. This isn't about yanking services based on blind speculation; this is about managing risk. We ship a system that has a moderate risk trade-off: we focus efforts on reducing risk in two ways. First, we evaluate the risk of components of the system, and focus security development efforts on improving those areas. Second, we evaluate the risk of these same components, and select system defaults in a manner that selects a reasonable balance of service and risk. This is why we've made the following classes of changes: - Changes to address specific known vulnerabilities (performed in a cooperative manner between the security-officer and the broader developer community) - Changes to reduce the privilege level required for management and monitoring applications (largely present in 5.0) - Re-implementation of core authentication components that were previously poorly integrated (PAM, ...) - Investment in improved network stack safety and firewall implementation (DARPA/NAI Labs have a contract with Jonathan Lemon that includes time spent specifically on investigating risks in the IP stack, and reducing them). There's also contract work to Jonathan Lemon to implement improved network crypto hardware integration, which he has a prototype of and will hopefully post when he's back from his current hiatus. - Evaluation of the focus of past vulnerabilities, including their source in the system code, the criticallity of the vulnerability, and the exposure associated with each vulnerability. This includes some time spent looking at how quickly various sorts of vulnerabilities tend to occur following releases, etc. - Investment in new policies and architectures improving flexibility for the administrator. Security is an area of active development in the FreeBSD Project, and we seem to have a strong grasp of a number of areas of the field. Someone who's unaware or unwilling to address security issues will *still* be safer if we provide a safer system. If they are going maliciously out of their way, sure, there will be problems, but if they don't need telnet, and we disable telnet by default, we have actually produced a safer system for them. And if they do need telnet, it's easy to turn on. Securing telnet is hard; let's turn it off and go shopping. 8-). Or maybe, Few people use telnet any more, so we'll spend some time fixing it, but we'll also disable it by default, since many of the reports of compromise come from people who weren't even using it, but left it turned on since it was the default. I think you've correctly identified an area where a lot of future security work is needed. However, that doesn't negate the need for security work in the base system, because without a secure base system, you're building everything else on sand. If you have the time and resources to spend helping to kick KDE and its related dependencies into shape, I welcome your doing that. It's something I haven't had time to work with yet, but have definite future plans to do. No one has *that* much time. Auditing that code base would be on the order of the difficulty of auditing Windows, and we have the source code the KDE. Certainly an in depth audit of something with the size and complexity of KDE will be a challenge; however, there's a lot of work that can be done without doing it line-by-line. I agree that the base system needs to be secure, but I think you either trust your security model, or you don't: X11 *does* have a security model, even if it doesn't encrypt all the traffic over all its connections by default. If the security model is flawed, then it needs to be fixed, not turned off. Security models and vulnerabilities aren't necessarily related issues. Sure, a good model helps in the event there is a vulnerability, but having a good model doesn't mean you'll be invulnerable to implementation flaws, flaws in the model, etc. Personally, I had nothing to do with the choice to turn off X11, but with it now changed, I'm happy with the change. Personally, I'd recommend using SSH and letting it take care of the details. I think it's a lot worse to leave a vulnerable telnetd turned off by default but available to be turned on, than to have one that's non-vulnerable turned on by default. Yeah, the great thing about vulnerabilities is that if you knew they were there you would most likely have fixed them before you released the product. Conservative defaults help you with risk you believe is present, but where you can't necessarily make the material improvement that you'd like to. In the case of telnetd, we accept that the risk exists, we attempt to improve the
Re: Problems with nge driver and copper GbE cards
On Tue, 2002-04-23 at 13:32, Fengrui Gu wrote: Third, I had trouble to set half-duplex mode on nge0. If I issued command ifconfig nge0 media 1000baseTX mediaopt half-duplex, I got the following error message ifconfig: SIOCSIFMEDIA: Device not configured I don't have trouble to issue command ifconfig nge0 media 1000baseTX mediaopt full-duplex. This I can help you with. the correct way of doing it is disabling full-duplex: # iconfig nge0 media 1000baseTX -mediaopt full-duplex cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Problems with nge driver and copper GbE cards
It works. Thanks a lot. So setting half-duplex is to disabe full-duplex.:) I didn't do this before so I was confused in the first place. But the following statement in the man page of nge driver probably may need some changes. === The nge driver supports the following media options: full-duplex Force full duplex operation. half-duplex Force half duplex operation. === thanks, --Fengrui -Original Message- From: Mike Makonnen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 23, 2002 4:29 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Problems with nge driver and copper GbE cards On Tue, 2002-04-23 at 13:32, Fengrui Gu wrote: Third, I had trouble to set half-duplex mode on nge0. If I issued command ifconfig nge0 media 1000baseTX mediaopt half-duplex, I got the following error message ifconfig: SIOCSIFMEDIA: Device not configured I don't have trouble to issue command ifconfig nge0 media 1000baseTX mediaopt full-duplex. This I can help you with. the correct way of doing it is disabling full-duplex: # iconfig nge0 media 1000baseTX -mediaopt full-duplex cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Problems with nge driver and copper GbE cards
There is something interesting. I accidentally started a ping command(ping data sender side) from data receiver side. As you know, ping will continue running until you stop it. I started netperf again from data sender side. You know what? The link seems more stable with additional ping session on receiver side no matter TCP or UDP traffic. I got the following numbers by running netperf. The performance of TCP w/ jumbo frame Copper GbE 650Mb/s (SMC9462TX) Fiber GbE 660Mb/s (GA 620) (Note: my experience told me that enable/disable jumbo frame will cause 20% performance difference). --Fengrui -Original Message- From: Fengrui Gu [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 23, 2002 3:33 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Problems with nge driver and copper GbE cards I am evaluating copper GbE cards for our lab. According to previous talk threads, it seems that SMC9462TX has better performance than NetGear cards. I bought two SMC9462TX cards and connect them through a Cat 5e cross-link cable. The machines in use are two dual PIII 733Mhz with 756MB memory. I use 32bit/33Mhz PCI slots. I know PCI bus of 32bit/33Mhz is slow but the major purpose of evaluation is to compare the performance between copper and Fiber GbE cards. There are another two identical dual PIII 733Mhz machines installed NetGear 620 Fiber GbE cards(using ti driver). So it is not an issue. I am using FreeBSD 4.5 and statically link nge driver into the kernel. First, there are a lot of link up messages from nge driver. I guess this has been reported. I use a small program to measure TCP performance. Basically, it sends 1G or 2G data over the network and calculate time and bit rate. The link between two copper GbE cards became unavailable after some TCP runs. There is no response from ping. The kernel didn't report error messages except some new link up messages. There is no abnormal from the output of ifconfig -a. Based on some suggestions(master or slave mode), I issued command ifconfig nge0 link0. The link would be back sometimes but not always. Did anyone suffer the same problem? Second, it seems that the link is more stable with UDP traffic though it became unavailable now and then. I could manage to collect some UPD performance data: UDP performance(sender) w/o jumbo frame w/ jumbo frame copper GbE 510Mb/s 632Mb/s (SMC9462Tx) Fiber GbE750Mb/s 856Mb/s (GA 620) (Note: data are from the results of netperf and shared the same parameters). Did anybody knows why copper GbE cards are so slow? Both copper and Fiber GbE cards are in the same kind of PCI slot and identical machines. The extra memory on GA620 should not cause 40-50% difference in my opinion. Third, I had trouble to set half-duplex mode on nge0. If I issued command ifconfig nge0 media 1000baseTX mediaopt half-duplex, I got the following error message ifconfig: SIOCSIFMEDIA: Device not configured I don't have trouble to issue command ifconfig nge0 media 1000baseTX mediaopt full-duplex. thanks, --Fengrui To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tuesday, 23 April 2002 at 12:06:01 +0200, Jochem Kossen wrote: On Tuesday 23 April 2002 11:04, you wrote: [...] I've been noticing a continuing trend for more and more safe configurations the default. I spent half a day recently trying to find why I could no longer open windows on my X display, only to discover that somebody had turned off tcp connections by default. *shrug* I was the one who sent in the patch. It was added some time around 2001/10/26 to the XFree86-4 megaport. When the metaport was created, the patch was incorporated too. A simple 'man startx' should have cleared your mind: Well, yes. But I've been using X for 11 years. Why should I have to read the man page to find changes? Because things evolve? :) Not a good reason. If they evolve, the evolution should be more clearly documented. How do I know which man page to read? You start X with startx, seems obvious to me. The disabling of tcp connections only applies to startx I don't stay with startx. Next I go to xinit, then to Xwrapper, then to X. All of these work fine. When I try to start an xterm, nothing happens. So I read the haystack of man pages for all these programs looking for a possible needle? That's 4314 lines of man pages (Xwrapper doesn't have a man page, so Murphy says that it's probably in Xwrapper). Based on prior experience, startx would be the last place I would look. In fact, I suspected a networking problem. If I did that for everything that happened, I wouldn't get any work done. And you can bet your bottom dollar that somebody coming from another UNIX variant and trying out FreeBSD won't do so. OK, then i suggest we mention it in the handbook, the security policy document, the manpage AND the release notes :) You've heard my suggestions. They'll just say that it's broken and wander off again. I note you don't comment on this one. In the case of the X patch, i'd add it to the release notes AND the security policy document, since - i think - few people will look in the security policy document for such a problem. I think it shouldn't happen at all unless people agree to it. 3 people did, 0 people did not...read below So only 3 people use X? Get real. You just haven't heard any objections up to now. I found out about this several weeks ago, but I didn't complain because I was expecting replies with the perspective you're showing. I do have to say you're the first one I see who complains about this... Maybe the others have given up. LOL THIS IS NO LAUGHING MATTER. It's this kind of change which is going to stop people from using FreeBSD. But since we're on the subject, why? What's so insecure about X TCP connections? Until you explicitly allow connections, the only system that can open the server is the local system. For the simple reason I don't like useless open ports on my system. I don't use it, _most_ other people don't use it, so i sent in a patch. Fine, I'm not telling you how to run your system. I don't want you telling me how to run my network. I note that you still haven't given a good technical reason for it. Of course, it was only discussed on the ports@ mailinglist, but it didn't seem like such a big deal to me or apparently the others... That doesn't help end users. We have a user community out there. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Erm, since everyone managed to HIJACK my sshd thread! ;)
We have an openssh maintainer? Right now, policy differs between branches. releng_4's openssh gives a commented alternative in the config, whilst head's gives a commented default. A consistent change to -stable would be: Index: servconf.c === RCS file: /cvs/src/crypto/openssh/servconf.c,v retrieving revision 1.3.2.11 diff -u -u -r1.3.2.11 servconf.c --- servconf.c 28 Sep 2001 01:33:34 - 1.3.2.11 +++ servconf.c 23 Apr 2002 23:20:43 - @@ -207,7 +207,7 @@ if (options-kbd_interactive_authentication == -1) options-kbd_interactive_authentication = 0; if (options-challenge_reponse_authentication == -1) - options-challenge_reponse_authentication = 1; + options-challenge_reponse_authentication = 0; if (options-permit_empty_passwd == -1) options-permit_empty_passwd = 0; if (options-use_login == -1) Index: sshd_config === RCS file: /cvs/src/crypto/openssh/sshd_config,v retrieving revision 1.4.2.6 diff -u -u -r1.4.2.6 sshd_config --- sshd_config 28 Sep 2001 01:33:35 - 1.4.2.6 +++ sshd_config 23 Apr 2002 23:20:54 - @@ -48,8 +48,8 @@ PasswordAuthentication yes PermitEmptyPasswords no -# Uncomment to disable s/key passwords -#ChallengeResponseAuthentication no +# Uncomment to enable s/key passwords +#ChallengeResponseAuthentication yes # To change Kerberos options #KerberosAuthentication no and against -current: Index: servconf.c === RCS file: /cvs/src/crypto/openssh/servconf.c,v retrieving revision 1.30 diff -u -u -r1.30 servconf.c --- servconf.c 20 Apr 2002 09:26:43 - 1.30 +++ servconf.c 23 Apr 2002 23:18:01 - @@ -212,7 +212,7 @@ if (options-kbd_interactive_authentication == -1) options-kbd_interactive_authentication = 0; if (options-challenge_response_authentication == -1) - options-challenge_response_authentication = 1; + options-challenge_response_authentication = 0; if (options-permit_empty_passwd == -1) options-permit_empty_passwd = 0; if (options-use_login == -1) Index: sshd_config === RCS file: /cvs/src/crypto/openssh/sshd_config,v retrieving revision 1.19 diff -u -u -r1.19 sshd_config --- sshd_config 2 Apr 2002 21:53:54 - 1.19 +++ sshd_config 23 Apr 2002 23:24:54 - @@ -60,8 +60,8 @@ #PasswordAuthentication yes #PermitEmptyPasswords no -# Change to no to disable s/key passwords -#ChallengeResponseAuthentication yes +# Change to yes to enable s/key passwords +#ChallengeResponseAuthentication no # Kerberos options # KerberosAuthentication automatically enabled if keyfile exists On Tue, Apr 23, 2002 at 01:05:09PM -0700, Jordan Hubbard wrote: FWIW, I agree with you, but I'm more interested in fixing this right now than I am in chasing the OpenSSH maintainers around with patches (unless we've already forked - have we?). I'll also be happy to change this twice if it turns out that getting the change into OpenSSH is easier than I thought, but I don't want just having this be fixed contingent on that. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: More about security, X, rc.conf and changing defaults.
On Tuesday, 23 April 2002 at 16:35:55 -0400, Daniel Eischen wrote: On Tue, 23 Apr 2002, Frank Mayhar wrote: Terry Lambert wrote: FWIW: I wouldn't object to a firewall rule that disallowed remote TCP connections to the X server by default, if the firewall is enabled. I think we already have this... Yep, I agree, and whether or not it's in the distributed rc.firewall, I have the ports blocked in my hand-tuned version. As to Stijn's remarks, he is putting up a strawman at best. If a person runs X, it should be their responsibility to make sure that it's secure. Just like if they ran Windows or any other software with potential security holes. X is plastered with warnings as it is, why do we need to cripple a function it supports? Stijn, if it opens up a hole in your network, that's _your_ problem, not mine. There are many other ways to secure your network than by turning off tcp connections by default in the X server. Hey, I'm not objecting to adding the capability, I'm just objecting to the fact that it was imposed upon everyone else by fiat and (worse) without warning. And before people start saying again that this only affects a port and is irrelevant to the operating system itself, this is one symptom of what I see as a worsening problem. I agree also. Remember what has been stated before, Tools, not Policy. If we want to disable this by default, then there should be a customary knob _where people expect/can see it_. And if we are lacking the mechanism to do it, then the change should wait until it is present. It shouldn't be hacked into an unexpected place. Agreed entirely. I would like to see this backed out. I think it would be reasonable to fix it by tying it to the securelevel. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEYsupport considered harmful?)
At 8:44 AM +0930 4/24/02, Greg 'groggy' Lehey wrote: On Tuesday, 23 April 2002 at 12:06:01 +0200, Jochem Kossen wrote: *shrug* I was the one who sent in the patch. It was added some time around 2001/10/26 to the XFree86-4 megaport. When the metaport was created, the patch was incorporated too. A simple 'man startx' should have cleared your mind: Well, yes. But I've been using X for 11 years. Why should I have to read the man page to find changes? I think the first thing we need to do, before we get too worked up, is stop taking to Jochem about it. All he did was send in a PR with a suggestion. He's not responsible for the change being committed into the system. How do I know which man page to read? You start X with startx, seems obvious to me. The disabling of tcp connections only applies to startx I don't stay with startx. Next I go to xinit, then to Xwrapper, then to X. All of these work fine. When I try to start an xterm, nothing happens. This is where we (the freebsd project) need to take a bit more time at when we are making a change like this. I think it makes little difference whether we document the change in UPGRADING, or man pages, or heads up on the mailing lists, or errata.html pages on the web site. There will always be some people who are not going to see documentation like that, because it's too far out of the way of what they are doing. What we need, in this case, is something which gives the user the information when they do that *xterm* -- ie, at the time of failure, to the person who is seeing the failure. For the case of 'startx -listen_tcp', this might suggest that if a person uses startx without -listen_tcp, then startx should (one way or another) start some process which *does* listen for an incoming connection, and does nothing but tell the user (one way or another...) when that connection comes in. Yes, that's a bit of work. However, it is also a bit of work when someone (like Greg) wastes six hours of a day trying to understand why something broke. That's a very frustrating six hours of work, and it's also very useless. His six hours of work won't help anyone else when they have to track down the same issue. A simpler solution might be to at least have startx print out a message (somewhere) which mentions the change when it is started up. Maybe print it out only once per userid. I realize that I am being a little vague with these suggestions, but I don't use X all that much, so I'm not sure what the best idea would be. But I do think it is reasonable for FreeBSD to make changes like this, and I do think that *if* we make changes like this then we need to think about how we can best get info about the change to the all people who really *are* effected by the change, and get the info to them when they need it. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tue, 23 Apr 2002, Terry Lambert wrote: The reality is that reducing exposure is an important part of any security posture. This is an argument for security through obscurity. If we are talking risk reduction, then we can easily achieve it statistically through obscurity. In fact, this is exactly what FreeBSD does through its choice of TCP sequence numbers. Security by obscurity refers to a behavioral phenomena in system design and delivery, not to a technical design principle. For example, it refers to using a secret algorithm, but does not refer to using a secret key with a published algorithm. So disabling services in a default configuration reduces risk by reducing exposure, but it's not security by obscurity. When shipping third party code, or our own code, we accept that some code is more at risk than other code. That risk might be the result of complexity, privilege, exposure, ... Whatever the reason, it's disingenuous to sweep it under the rug (all our code is good, so we ship it all turned on) rather than select safe defaults and let people turn on what they need. FWIW: I wouldn't object to a firewall rule that disallowed remote TCP connections to the X server by default, if the firewall is enabled. I think we already have this... The firewall code serves a useful function, but one of its great detriments is a lack of application awareness. The current placement of the policy seems most reasonable to me, but might be supplemented by such a rule if desired. Application state is not necessary for incoming connections which are self-identified by source and destination IP and port; the existing stateless firewall code can handle them completely, without introducing problems. X arguments that disable the X11 protocol over TCP will work regardless of the configured TCP port for XFree86. Firewall rules won't. Also, firewall rules may interfere with other applications, where X11 configuration won't. Both have their place. Actually, it would be more useful to concentrate on so-called stealth firewall technology, so that OS identification due to port scans, etc., is impossible, and so it looks as if there is no machine there whatsoever, if there are no services actively listening AND access is permitted to the source machine. No doubt an interesting area to explore. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Wed, 24 Apr 2002, Greg 'groggy' Lehey wrote: A more conservative default configuration results in a material improvement in system security. *snip* By snipping here, you removed reference to the fact that this was a general discussion of direction and policy, rather than specifically to do with X11, which provides an answer to a number of your questions. A reasonable set of criteria might include: - There have been past vulnerabilities that were exploitable by having the feature enabled by default. Which in this case? As indicated, not all of these criteria may apply in every case -- this was just a suggested list of criteria that might be applied. There have been a number of vulnerabilities in a number of different X protocol implementations. Many of them require first getting past the normal X access control mechanisms before they may be exploited, but not all. - The complexity and exposure of the feature lends it to future vulnerabilities. I don't see any relevance here. If you think that's a problem, then you didn't read my e-mail. However, there is actually a great deal of relevance here: protocol and implementation complexity have a lot to do with the chances that there will be a serious vulnerability. Likewise, the level of privilege associated with X11 is highly relevant: if you compromise the X server, you've got a lot to play with. - Turning the feature on is difficult or impossible without high levels of expertise. Fortunately, this is the case here as well. Otherwise it would really have broken X. Sounds good to me. - The feature does/does not have more secure alternatives accepted by the broader community. The broader community hasn't been consulted here. Not entirely clear, but worth discussing. Security by obscurity does not refer to the act of selecting a conservative security policy, Don't get hung up on terminology. If you can't use terminology properly, we'll have a lot of trouble holding a useful conversation. I objected to your use of the term, because it has a specific meaning, and that meaning doesn't apply here. If you're not going to use the term, maybe we agree on more than we think. What I'm talking about here are differences which users of other UNIX systems won't know about and which will make life difficult for them, to the extent that the casual user won't bother to try to solve the problem. In the current issue of AUUGN, the journal of the Australian UNIX User group (http://www.auug.org.au/), we gave away a FreeBSD 4.5 CD-ROM. Based on previous actions, I'm expecting a number of people to try it out. They're mainly experienced UNIX users; they won't want to go reading through 80 pages of man pages when their X fails to work. They'll throw away the CD and go back to what they were using before. I'm more interested in the general issue here, since you made the general assertion that there was a problem that stretched beyond this one issue. I'm happy to entertain the idea that we discuss this specific issue in more detail. In particular, the decision to not bind the X11 port might take into account this particular implementation (XFree86), and whether we can make this setting more accessible to the administrator (i.e., something that could be mechanically twiddled, rather than through manual editing of scripts...) 2. Document these things very well. Both this ssh change and the X without TCP change are confusing. If three core team members were surprised, it's going to surprise the end user a whole lot more. We should at least have had a HEADS UP, and we probably need a security policy document with the distributions. Part of your confusion That's not the correct word. Not your confusion, rather, the general confusion regarding where the feature change can/should be documented, and how people should be made aware of this kind of change. is probably because X11 isn't part of the base system, so events concerning the X11 port don't tend to get discussed much on the general-purpose mailing lists. I think the issue here is that individuals make this kind of decision. We need a broader consensus for this kind of change. As Jochem points out, only 3 people were involved in the decision, all of them people with security profiles which weren't affected by this change. For something like X11, we need a freebsd-x11 mailing list. Or maybe freebsd-xfree86. For most other large third party applications, we either have a single authoritative maintainer, or a mailing list. For example, both Gnome and KDE have these. These kinds of things do get discussed on the release engineering lists, questions, etc. It may be we need a ports release notes, but that's an effort that's going to have to come out of the ports space. There's another issue here. This isn't the first port I've seen which has made gratuitous changes to the
Re: Problems with nge driver and copper GbE cards
Fengrui Gu wrote: There is something interesting. I accidentally started a ping command(ping data sender side) from data receiver side. As you know, ping will continue running until you stop it. I started netperf again from data sender side. You know what? The link seems more stable with additional ping session on receiver side no matter TCP or UDP traffic. I got the following numbers by running netperf. Do a search engine query on receiver livelock. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: need help: ld final link failed. Memory exhausted
Hi, Setting the max stacksize to 128MB helped. Can we have this as default ? As many users plan to use staroffice, requiring them to recompile kernel just for this would be ... Anyway, is there a reason that the maxstack is 64MB only ? Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: need help: ld final link failed. Memory exhausted
* Martin Blapp [EMAIL PROTECTED] [020423 19:55] wrote: Hi, Setting the max stacksize to 128MB helped. Can we have this as default ? As many users plan to use staroffice, requiring them to recompile kernel just for this would be ... Anyway, is there a reason that the maxstack is 64MB only ? Because 64MB of stack should be enough for anybody? -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: need help: ld final link failed. Memory exhausted
Because 64MB of stack should be enough for anybody? times have changed ... it seems. The OpenOffice build linking needs definitly more that 64MB. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tuesday, 23 April 2002 at 21:38:38 -0400, Robert Watson wrote: On Wed, 24 Apr 2002, Greg 'groggy' Lehey wrote: A more conservative default configuration results in a material improvement in system security. *snip* By snipping here, you removed reference to the fact that this was a general discussion of direction and policy, rather than specifically to do with X11, which provides an answer to a number of your questions. Sorry, I wasn't trying to obfuscate anything. I was just trying to limit the message to a manageable length. It didn't come across too well, though. - The feature does/does not have more secure alternatives accepted by the broader community. The broader community hasn't been consulted here. Not entirely clear, but worth discussing. Well, I see the broader community as the users. Now it's true that they don't have that much of a say, but what I'm seeing here is that very few people get to make these decisions. Security by obscurity does not refer to the act of selecting a conservative security policy, Don't get hung up on terminology. If you can't use terminology properly, we'll have a lot of trouble holding a useful conversation. In this particular case, the subject line was meant ironically and was mainly intended to catch people's eyes. Until you mentioned it, it didn't occur in the text. I'm more interested in the general issue here, since you made the general assertion that there was a problem that stretched beyond this one issue. Well, we saw the ssh problem as well; that's more than one. We also see things like rsh and rlogin die, maybe due to lack of love. I'm sure there are many more, some of which I have seen and accepted, others which I have seen and couldn't be bothered to complain, and others again that I haven't seen and that may or may not bite me in the future. The issue here is that the choice shouldn't be left to the individual if we're working as a team. I'm happy to entertain the idea that we discuss this specific issue in more detail. In particular, the decision to not bind the X11 port might take into account this particular implementation (XFree86), and whether we can make this setting more accessible to the administrator (i.e., something that could be mechanically twiddled, rather than through manual editing of scripts...) Well, what about checking securelevel before setting --nolisten-tcp? I think the issue here is that individuals make this kind of decision. We need a broader consensus for this kind of change. As Jochem points out, only 3 people were involved in the decision, all of them people with security profiles which weren't affected by this change. For something like X11, we need a freebsd-x11 mailing list. Or maybe freebsd-xfree86. For most other large third party applications, we either have a single authoritative maintainer, or a mailing list. For example, both Gnome and KDE have these. No, that's only part of the issue, though it's an important one. I've had complaints from Apache people that we're not communicating back enough, for example. My notion of ease of use would be dependent on the securelevel. I run a network which is heavily firewalled (has to be: I have Linux boxes here too :-), and within which the security is very lax. I have yet to see any proof that this is a problem. Sure, set the machine up for secure operation by default, and issue dire warnings about relaxing security, but don't try to know better than the user. Securelevels are a specific security model that doesn't relate to this at all. Arguably, securelevels contribute more to shoot footing than about any other feature we provide easy access to with sysinstall. I'd rather leave securelevels as they are: a model restricting root privilege, and not tangle them into any more features than necessary. Securelevels are *not* a good model for security management, although they might act as a tool in a general security posture. The security profile concept has provided for similar confusion and problems -- witness NFS breaking between our platform and others because someone selected the default (cancel) rather than moderate as their security profile, but not to other platforms. Tying a bunch of unrelated security features together rather than just itemizing them causes a lot of confusion, especially when the security feature menus conflict with other menus that toggle the same features (enabling NFS specifically vs. having it turned back off again by sysinstall for a security profile). If we can expose this feature via rc.conf, just make it a seperate rc.conf entry and twiddle it off of the security configuration manu in sysinstall. Is that something we can do easily? I think the issue is POLA. Sure, we can put in individual knobs to twiddle, but who will do that? I thought that securelevel would have been a suitable solution to say I want approximately *this* much security. If
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Wed, 24 Apr 2002, Greg 'groggy' Lehey wrote: I think the issue is POLA. Sure, we can put in individual knobs to twiddle, but who will do that? I thought that securelevel would have been a suitable solution to say I want approximately *this* much security. If that's not the case, then we need a few generic statements which can then be further refined. FWIW, the place where this should really go is the X11 configuration tool -- if we extend the configurability of an application, the confuration twiddles for that should live (and be documented) in the normal places for that application, and not have any hooks of this sort in the base system. BTW, one really good reason not to tie securelevel and X11 behavior is that securelevels (when high) specifically break X11, and likewise, other management functionality that you might want to use with X11. Overloading twiddles in this manner is a bad thing :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
SB Audigy Driver?
Anyone know if the current set of FreeBSD pcm drivers support Sound Blaster Audigy? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: fix wrong PNP ID comment
Please submit such things as problem reports. Take a look at 'man send-pr' if you need help. -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
Kenneth Culver writes:
OK, I found another problem, here it is:
static void
linux_prepsyscall(struct trapframe *tf, int *args, u_int *code, caddr_t
*params)
{
args[0] = tf-tf_ebx;
args[1] = tf-tf_ecx;
args[2] = tf-tf_edx;
args[3] = tf-tf_esi;
args[4] = tf-tf_edi;
*params = NULL; /* no copyin */
}
Basically, linux_mmap2 takes 6 args, and this looks here like only 5 args are
making it in... I checked this because the sixth argument to linux_mmap2() in
truss was showing 0x6, but when I printed out that arg from the kernel, it
was showing 0x0. Am I correct here?
Ken
Yes. According to http://john.fremlin.de/linux/asm/, linux used to
parse only 5 args but now it parses six. Try adding:
args[5] = tf-tf_ebp;
Drew
OK, I THINK I found what calls the actual kernel syscall handler, and
sets it's args first, but I'm not sure:
from linux_locore.s
NON_GPROF_ENTRY(linux_sigcode)
call*LINUX_SIGF_HANDLER(%esp)
lealLINUX_SIGF_SC(%esp),%ebx/* linux scp */
movlLINUX_SC_GS(%ebx),%gs
movl%esp, %ebx /* pass sigframe */
push%eax/* fake ret addr */
movl$LINUX_SYS_linux_sigreturn,%eax /* linux_sigreturn() */
int $0x80 /* enter kernel with args
*/
0: jmp 0b
ALIGN_TEXT
I think the stuff above copies the args, and whatnot, but I'm not really
sure where it does this exactly...
It calls LINUX_SIGF_HANDLER, which then calls %esp's sf_handler function.
That is where I draw a blank, I don't know which function this is calling,
and can't find where it's being set. I think this might be what I want to
change though. :-P
Does anyone who actually knows assembly have any ideas?
Ken
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: make installworld failed on 4.0-RELEASE
On Mon, 22 Apr 2002, Dmitry Mottl wrote: Hi, I have a problem when installing 4-STABLE on 4.0-RELEASE from remotely mounted /usr/src and /usr/obj: ELF binary type not known. Use brandelf to brand it You're trying to cross an upgrade boundary that just won't fly. Back up your data and install clean from scratch. Good luck, Doug -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (and /etc/defaults/rc.conf changes)
Thus spake Terry Lambert [EMAIL PROTECTED]: The entire idea of bit rot is really the code did not keep ``up to date'' with my changes, which broke the code, which is really a ridiculous position. It really pissed me off when the AHA-1742 support dropped out when CAM came in, but that, at least, was understandable, since it was a trade: something deisrable for something less desirable to the majority of users. You really *can not* blame breaking something that used to work but which no longer works on evolution. Aah...we'd better put uucp back in the base system, then. Never mind that it might have security problems that we don't know about. :P To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
