Re: IPFilter Bridging
>I am wondering if anyone knows of any workarounds to >get IPFilter to filter across an ethernet bridge. this a FAQ, or at least a Recently AQ. ipfilter bridging only works on OpenBSD Len http://MenAndMice.com/DNS-training http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Signal Handling
On Tue, Aug 14, 2001 at 09:11:58PM -0700, brian o'shea wrote: > On Tue, Aug 14, 2001 at 07:47:50PM -0700, Hans Zaunere wrote: > > > [...] > > > > 2) If a 10k binary is running, the signal is sent, and the program > > > > is reloaded from disk, but is 100k (or 1k even) how does the > > > > signal handling function get called, taking into account what > > > > Stevens says. Steven states that the sigmask remains for calls > > > > across exec, so wouldn't the wrong address to the handler function > > > > be used? > > > > > > No, the signal mask is not the address of the handler function. It > > > is the bit mask which determines which signals are blocked. > > > > > > > Sorry, I think I miss spoke myself. If a signal handler is setup in > > the running process, and exec is called, replacing the same program, > > but this time, the program is much smaller or bigger, will the signal > > handler function be in the right place? The same program is exec'd, > > but since it's a different size, won't the signal handler function > > pointer, point to the wrong place? > > If a program calls exec on the file that is the current text file (i.e. > argv[0]), then the text segment of the process will be the same size as > it was before the call to exec, because it will be identical. The only > reason why the process' size might (and probably will) be different is > because of any dynamically allocated memory, and because of and stack > growth from function calls and local variable allocation. Neither of > these effect the address of any of the functions in the program > (including the signal handlers). This is not necessarily true; a program might exec() a file by the same name, but with different contents - e.g. restarting a recompiled server. G'luck, Peter -- I've heard that this sentence is a rumor. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Signal Handling
On Mon, Aug 13, 2001 at 09:09:32AM -0700, Hans Zaunere wrote: > > In a program that I am working on, I've decided to > catch signal 15, which then calls execl() in the > handler to reload the program from the on-disk binary. > I am able to send it the signal, it reloads, and > works fine. However I could not send the signal again > and have the program respond. I then learned, with > some help, that the signal needs to be unblocked after > each call. It now works as intended. > > However in reading about this, in Steven's Advanced > Programming in the UNIX Environment, he states: > "Naturally a signal that is being caught by a process > that calls exec cannot be caught in the new program, > since the address of the signal-catching function in > the caller probably has no meaning in the new program > file that is execed. Page. 273) > > This makes sense to me, however doesn't seem to be the > case. Three questions: > > 1) Why, in the first place, does a signal become > blocked after it is recieved? Why does the kernel > want to do this? Mainly compatibility - it was done this way in some oold Unixen. The sigaction(2) syscall gives you much more control over how your handlers are called/reset/etc. > 2) If a 10k binary is running, the signal is sent, and > the program is reloaded from disk, but is 100k (or 1k > even) how does the signal handling function get > called, taking into account what Stevens says. Steven > states that the sigmask remains for calls across exec, > so wouldn't the wrong address to the handler function > be used? The sigmask remains, but not the handlers themselves. Look at the execve(2) manual page - it explains exactly what is done to both signal handlers and the signal mask - the part about blocked signals is the one that talks about the signal mask. > 3) Is my using of exec, in fact, the best way to > reload the program on the fly, from within itself? > What would be the best, robust, way to do this in the > future? Executing your own image is a good way to do it. It does have some drawbacks, but it is a good way. I hope that when you exec something, you are really certain that it is your actual program that you are executing, and not just argv[0]. Otherwise, a malicious user might start your program with a different argv[0] setting (all exec*() functions allow this), then send a 'reload' signal/command/whatever, and have your program execute something else, possibly with elevated privileges. G'luck, Peter -- If I were you, who would be reading this sentence? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Promise FastTrack TX2 don't work on 4.3-RELEASE
I'm trying to use this card but it was not recognised by 4.3-RELEASE. I've check the source this model is not listed in ata driver: the model of this card has this identification number: 0x6268105a. Any chance to get it working ? Thank in advance Gabriele To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IP address on bridge
Hello, I'm observing some strange problem when I have an IP address on one card on a bridge machine and want to telnet in. I have 4.2-RELEASE box with two network cards: Realtek 8139 (rl0) and 3Com 3C905B (xl0). rl0 is connected to the world, and xl0 to the intranet switch. FreeBSD handbook says that I'm allowed to assign an IP address to one of the two interfaces. Okay, so I assign the address to xl0. But I'm unable to access it from a machine on xl0 side. arp is found properly, and packets are sent, but somehow bridge machine just ignores those packets (tcpdump shows nothing). If I assign IP address to rl0 rather than xl0, it works for short time, then machine I telnet from says that arp of the bridge is moved to xl0 arp again, and packets get lost. ifconfig rl0 down/up and ping'ing the machine I telnet from (so it gets proper arp) heals, but for the short time again. When I swap network cables on those cards, so that xl0 looks to the world and rl0 to the intranet, then assigning IP address to rl0 works fine, I'm always able to telnet in from intranet side. Is it some bug in the xl0 driver ? Was it already fixed, and would upgrading to -current solve this problem ? Or is it me who misses something ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Promise FastTrack TX2 don't work on 4.3-RELEASE
It seems Gabriele Cecchetti wrote: > I'm trying to use this card but it was not recognised by 4.3-RELEASE. > > I've check the source this model is not listed in ata driver: the model > of this card has this identification number: 0x6268105a. > > Any chance to get it working ? I have the fix here, but havn't had time to get it into 4.4... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel stack size
> In 5-0-KSE there is a single page that contains the stack and > the PCB (which is about 660 bytes). We are also looking at adding > code to set a hardware watchpoint between the stack and the PCB > to catch overruns. Maybe I'm just dumb, but I still don't understand, what is the reason of keeping kernel stack size so small ? I understand there should be no need in huge stack, but why so damn small ? Would someone explain please ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel stack size
We may go to 2 pages but really 1 page is enough as long as people don't store structures on the stack. It's been kept small to keep the overhead of processes and threads down. When we get threads (KSE) we may have theoretically thousands more of these, on potentially smaller boxes.. The main poitn is that it's FIXED and that you can have recursion and interrupts so kernel programmers should know that a stack is a minimal resource. To some extent keeping it VERY small helps force this disciplin on people. As I said before there is a possibility we may go to 2 pages but that's not at all certain. On Fri, 17 Aug 2001, Eugene L. Vorokov wrote: > > In 5-0-KSE there is a single page that contains the stack and > > the PCB (which is about 660 bytes). We are also looking at adding > > code to set a hardware watchpoint between the stack and the PCB > > to catch overruns. > > Maybe I'm just dumb, but I still don't understand, what is the reason of > keeping kernel stack size so small ? I understand there should be no > need in huge stack, but why so damn small ? Would someone explain please ? > > Regards, > Eugene > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting filename from descriptor or vnode struct
you are going to have to examine the name cache and find the inode of the
directories in the full path. Most open directories will have their full
path in the caches..
On Fri, 17 Aug 2001, Eugene L. Vorokov wrote:
> > Hi hackers,
> >
> > I'm confronted to a problem when I try to hack getdirentries(2) in a kld
> > module :
> >
> > To summarize, getdirentries() filled in a buffer a series of dirent struct,
> > and the 'd_name' field represents the filename (without the full path). I
> > must recover the full path because I've on disk a list of files to hide ...
> >
> > The field 'fd' in getdirentries_args is the file descriptor of the
> > directory.. and I've discovered that the field 'p_fd' from struct proc is a
> > filedesc struct which contains a vnode struct representing the current
> > directory ('fd_cdir').
> >
> > VOP_GETATTR() doesn't allow me to recover this..
> >
> > If someone could help me, thanks in advance !
>
> I think the best way would be to also hack open() and close(). You can have
> some table where you store fd and full pathname of each opened directory.
> You add an entry on open() and remove it on close(). Of course, open()
> argument may be a path relative to current directory, so to get full path
> you should simulate __getcwd() syscall; you must allocate userland buffer
> for it with mmap() and then copyin() it (read my previous posting). Once
> you have such table, you can find the path by fd in hacked getdirentries()
> and see if you want to hide the file or not ...
>
> Regards,
> Eugene
>
>
> 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
Kernel bloat
I recently started reading -hackers and noticed something disturbing: a lot of people asking how to do things in the kernel that seem to blatantly not belong there. This makes me wonder if there's a writeup somewhere that provides guidance on such matters? Thanx, 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: IP address on bridge
"Eugene L. Vorokov" wrote: > I'm observing some strange problem when I have an IP address on one card > on a bridge machine and want to telnet in. I have 4.2-RELEASE box with > two network cards: Realtek 8139 (rl0) and 3Com 3C905B (xl0). rl0 is connected > to the world, and xl0 to the intranet switch. FreeBSD handbook says that > I'm allowed to assign an IP address to one of the two interfaces. Okay, > so I assign the address to xl0. But I'm unable to access it from a machine > on xl0 side. arp is found properly, and packets are sent, but somehow > bridge machine just ignores those packets (tcpdump shows nothing). > > If I assign IP address to rl0 rather than xl0, it works for short time, > then machine I telnet from says that arp of the bridge is moved to xl0 > arp again, and packets get lost. ifconfig rl0 down/up and ping'ing the > machine I telnet from (so it gets proper arp) heals, but for the short time > again. 1) The xl0 interface is working for transmit but not receive, or it would keep working after the ARP move. 2) You are putting both interfaces on the same wire; this means you have another bridge out there somewhere, or the wire doesn't need to be bridged, and is why the ARP is claimed to have moved. 3) A gratuitous ARP is sent when you ifconfig an interface to add an IP address (e.g. when you add an alias, or bring the interface from down to up). This is why the "pinging heals" when you reset the interface. So... A) Do not put two interfaces on the same wire, particularly if you have not set your netmask to make their listen ranges non-intersecting. B) Make sure the xl0 interface is correctly assigning an interrupt, etc.. You can check this by making it the default gateway for the machine, not configuring the other interface, and seeing if things work. If they don't, you have a bad card, driver, or BIOS (the BIOS does the IRQ assignment, if you have "PNP OS" enabled in the BIOS configuration, and some BIOS' do it wrong). C) Find the other bridge, if you haven't put both cards on the same wire segment, since _someone_ is forwarding those ARP packets, if that's the case. D) Realize you can only have one default interface on a machine at a time, so correctly use your subnet masks. E) Consider doing routing instead of bridgeing. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel stack size
In message <[EMAIL PROTECTED]> Julian Elischer writes: : We may go to 2 pages but really 1 page is enough as long as people : don't store structures on the stack. It's been kept small to keep the : overhead of processes and threads down. When we get threads (KSE) we may : have theoretically thousands more of these, on potentially smaller boxes.. One interesting note is that if you call PCI BIOS, you have to guarantee you have at least 1k available to do so. I think that the current instances of the code comply, but if the stack size gets a lot smaller, I'm less sure. : The main poitn is that it's FIXED and that you can have recursion and : interrupts so kernel programmers should know that a stack is a minimal : resource. To some extent keeping it VERY small helps force this disciplin : on people. Some forced discipline may not be possible when dealing with external interfaces. I do not know if other platforms (open firmware) have similar requirements or not. Since I have my fingers in the PCI BIOS code at the moment and reading the PCI BIOS docs, I thought I'd mention it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting filename from descriptor or vnode struct
Julian Elischer wrote: > > you are going to have to examine the name cache and find the inode of the > directories in the full path. Most open directories will have their full > path in the caches.. For the problem he is trying to solve, he should: 1) Precompute the path to the configuration file, and save the ino_t and dev_t for the thing. 2) Compare this tuple against the result of VOP_LOOKUP or VOP_READDIR operations, and hide the results if it matches. NB: Life would be easier for multiple configuration files if you picked a configuration directory, instead, and hid that, rather than individual files, making it an O(1), not an O(n) operation. In other words, look it up forwards once, instead of looking it up reverse many times. You should also be aware that the "hiding" you are doing will not "save you" from mounts overlaying your names, so, if you care about consistancy, you should probably open the target file/directory at the start, and cache a reference to it for the duration, so that it can't cache out from under the kernel code you are writing (e.g. if you use the directory approach, you need to to do exactly what a process does when it gets a current working directory, so look at that code in the kernel and copy it). There are other issues of data folding (e.g. you can treat the directory variantly as a file or directory, in order to flod it out from the FS, which would then let you reuse the directory name from user space, and be none the wiser), but that's a topic for later, after you get your initial code working. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
how to trace file error
Sorry, -hackers, no answer on -questions. When using the ecartis 1.0.0 (ex-Listar) web interface on 4.2-release, and trying to log in without a password, login fails and mails this report: Error report: List: User: Action: File: /home/ecartis/lists/SITEDATA/cookies Error: Bad file descriptor -- queuefile in error -- << NO QUEUEFILE! >> The comment by Rachel Blackman, the ecartis developer, is: "After a bit of abuse, I was able to produce this error when my own FreeBSD-4.2 box ran out of file descriptors due to a rogue process (in this case, a faulty PHP/FI engine compile that was not always freeing file handles for some reason). Perhaps something similar is affecting your box?" The box is a dedicated list server, nothing else running. kern.maxfiles: 16384 kern.maxfilesperproc: 16384 vm.zone: ITEMSIZE LIMITUSEDFREE REQUESTS PIPE:160,0, 44, 58, 866 SWAPMETA:160, 256500, 0, 0,0 unpcb:64,0, 26,294, 2960 ripcb: 192,65536, 0, 42,4 tcpcb: 544,65536, 9, 68, 920 udpcb: 192,65536, 6, 36, 2457 tcpcb: 544,65536, 0, 0,0 socket: 192,65536, 41,316, 6346 KNOTE:64,0, 0,128, 2280 NFSNODE: 320,0, 0, 0,0 NFSMOUNT:544,0, 0, 0,0 VNODE: 192,0, 1692,110, 1692 NAMEI: 1024,0, 0, 16, 135476 VMSPACE: 192,0, 38, 90, 864 PROC:416,0, 43,104, 870 DP fakepg:64,0, 0, 0,0 PV ENTRY: 28, 1494926, 10383, 120680, 281535 MAP ENTRY:48,0,808,935,32037 KMAP ENTRY: 48,32190,272,111, 1298 MAP: 108,0, 7, 3,7 VM OBJECT:96,0, 1276,492,19321 What kind of tool is there to watch file openings and catch errors? Or any other ideas? The box works fine as list server, sending 200K+ messages (via postfix) per day just fine. But I only try the LSG web login when no list is being delivered. nothing in maillog, dmesg, or messages. Len http://MenAndMice.com/DNS-training http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silly crackers... NT is for kids...
Which just brings me to another point, why not just turn ssh on by default and turn telnetd off by default, given the latest exploit. Thanks for bringing up a point that I wanted to bring to the security team for awhile. -- Jonathan M. Slivko <[EMAIL PROTECTED]> 4EverMail Hosting Services http://www.4evermail.com "Are YOU ready for the new Internet?" -- - Original Message - From: "Nate Williams" <[EMAIL PROTECTED]> To: "Matt Piechota" <[EMAIL PROTECTED]> Cc: "Carroll, D. (Danny)" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, August 17, 2001 5:11 PM Subject: RE: Silly crackers... NT is for kids... > > Even for authentication? > > > > I can understand using a telnet client to manually test SMTP servers or > > other protocols, but I cannot understand why you *need* telnet. > > Mind you I am against using pop3 as well, unless it's encrypted. > > Example 1: > You're on an internal heavily firewalled corporate LAN, where none of your > information is hidden between employees. So you don't care, and you don't > have to worry about installing ssh on every PC's desktop, and teaching > cluon-deprived people to use it. Agreed, but given the recent telnetd exploit, I'm not sure you want it on by default. Even in our heavily-firewalled environment, we don't want *ALL* of the users to have root access on our FreBSD boxes. :) Having the users enable it by default makes them more aware of what's going on. (Although, one could argue that all the folks who are still infected with CodeRed initially enabled it, and have done nothing since...) > Example 2: You're running realtime applications, or applications that > need all available processing power for performance reasons. The > extra overhead of encrypting and decrypting the ssh traffic may drop > your performance. Then don't telnet into the box. If you need to monitor a box over an insecure network, then encryption/decryption is a necessity, IMHO. > Let's not forget that until the recently done work of the OpenSSH team, > you couldn't use SSH in a commercial environment with out paying for it. > And besides, sniffing passwords isn't that terribly easy if you're using > switched Ethernet anyways. Actually, it is. See the archives of how easy it is to blow the switch out of the water. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silly crackers... NT is for kids...
"Jonathan M. Slivko" wrote: > > Which just brings me to another point, why not just turn ssh on by default > and turn telnetd off by default, given the latest exploit. Umm, because the -next- exploitable bug might be in sshd, not telnetd? There are lots of good reasons to run ssh and not telnet by default, but the fact that telnetd had a recent exploitable bug is not one of those reasons. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silly crackers... NT is for kids...
If memory serves me right, "Jonathan M. Slivko" wrote: > Which just brings me to another point, why not just turn ssh on by default > and turn telnetd off by default, given the latest exploit. Thanks for > bringing up a point that I wanted to bring to the security team for awhile. >From the release notes for -CURRENT and 4-STABLE: All services in inetd.conf are now disabled by default for new installations. sysinstall(8) gives the option of enabling or disabling inetd(8) on new installations, as well as editing inetd.conf. Bruce. PGP signature
Re: Silly crackers... NT is for kids...
I'm saying without any intervention of any kind. -- Jonathan -- Jonathan M. Slivko <[EMAIL PROTECTED]> 4EverMail Hosting Services http://www.4evermail.com "Are YOU ready for the new Internet?" -- - Original Message - From: "Bruce A. Mah" <[EMAIL PROTECTED]> To: "Jonathan M. Slivko" <[EMAIL PROTECTED]> Cc: "Nate Williams" <[EMAIL PROTECTED]>; "Matt Piechota" <[EMAIL PROTECTED]>; "Carroll, D. (Danny)" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, August 17, 2001 5:37 PM Subject: Re: Silly crackers... NT is for kids... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silly crackers... NT is for kids...
On Friday, August 17, 2001, Jonathan M. Slivko wrote: > I'm saying without any intervention of any kind. -- Jonathan Hence the part about "By default". If the person installing FreeBSD does nothing when asked about inetd.conf, no inetd services are enabled. This means telnetd, too. -- +---++ | Chris Costello| Wasting time is an important part of life. | | [EMAIL PROTECTED] || +---++ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silly crackers... NT is for kids...
> Which just brings me to another point, why not just turn ssh on by default > and turn telnetd off by default, given the latest exploit. As Bruce already mentioned, this is the new default in 4.4. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
