Determining userland return address (from syscall)
Greetings, much respected FreeBAS Hackers! :) I am developing a kernel module that implements a custom syscall and needs to know from what exact userland address was the call made. Being concerned about choosing the most correct approach, I turned to this list for help. Please provide as much information as you can. For those interested I will explain the purpose. I've been thinking of some way to let Apache children a limited ability to setuid() as a solution for both suexec and the infamous PHP-as-a-module issue. The solution I am about to implement is based on a custom setuid syscall, that would allow limited list of processes to obtain root privileges from a limited set of locations (supposedly, the trusted ones, originating in the httpd's .text section). The modified Apache child would issue such a syscall, get root privileges and then immediately setusercontext() for the request it is about to process. The list of processes and locations would be maintained by Apache parent that runs with root privileges already, child processes would not be allowed to modify the list. The key point here is ability to trust a call being made from a specific location. I assume that process cannot change its .text section once loaded so this scheme would no be abused by overwriting the location with malicious code. Am I correct here? What do you think of this scheme overall? Thank you. -- Deomid Ryabkov aka Rojer [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 8025844 smime.p7s Description: S/MIME Cryptographic Signature
Re: Determining userland return address (from syscall)
Steve Watt wrote: In article <[EMAIL PROTECTED]> you write: [ snip ] The solution I am about to implement is based on a custom setuid syscall, that would allow limited list of processes to obtain root privileges from a limited set of locations (supposedly, the trusted ones, originating in the httpd's .text section). Unfortunately, the extremely powerful mmap() and munmap() system calls will allow remapping of text addresses, which kinda blows away your whole scheme. yes, but i could check if the memory region covering the return address is indeed a shared text segment (e.g. is backed by the file with given inode). or if it is just the same as that of the parent process. and to my understanding, while able to remap .text, malicious user would not be able to remap it read-write from the same file (httpd), as he wouldn't be allowed to by file permissions. The key point here is ability to trust a call being made from a specific location. I assume that process cannot change its .text section once loaded so this scheme would no be abused by overwriting the location with malicious code. Am I correct here? What do you think of this scheme overall? Probably insufficient. The safest way is still isolated processes, possibly one (or, worse resource-wise, more) per UID, and those processes communicate via pipes, unix-domain socket pairs, or similar controlled IPC. The parent vfork()s, does appropriate uid/gid/gidset rearrangement, and execs the "user server" process, which would then hang around servicing stuff for some time. There don't seem to be better alternatives for doing this securely and still keep reasonable *NIX-like behavior. this is no good either... overhead would bring down our servers right away. -- Deomid Ryabkov aka Rojer [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 8025844 smime.p7s Description: S/MIME Cryptographic Signature
Re: occasional ECONNREFUSED when connect()ing.
I have a strange case of occasional refused connect()'s. The system is running 4.10-STABLE. ... The question is - why do connections get refused at all? I can think of no valid reasons... FWIW, I can't either. The client is single-threaded so it's difficult to see why this should occur. Unfortunately, I don't have ready access to a 4.x system with perl 5.8 but I don't see the problem with FreeBSD 5.3. problem solved by upgrading system to 4.11-STABLE. the problem is specific to 4.10: it does NOT show up on any of 3 systems running FreeBSD 4.9-STABLE #4: Mon Nov 10 18:47:10 MSK 2003 it DOES, however, show up on every one of 3 other systems, running FreeBSD 4.10-STABLE #10: Wed Aug 4 18:42:45 MSD 2004 and, as i said, it seems to have had been fixed somewhere before FreeBSD 4.11-STABLE #12: Sun Jan 23 14:09:07 MSK 2005 i don't feel like diving deep into the issue here... thanks everyone :) [Haven't read your code] Try to turn net.inet.ip.portrange.randomized off. yes, this does solve the problem on 4.10-STABLE. thanks, Maxim :) mink[/home/rojer]# uname -rms FreeBSD 4.10-STABLE i386 mink[/home/rojer]# ./x.pl 24045, http://localhost:8000/junk, 2000: starting. 42 500 Can't connect to localhost:8000 (Timeout) 397 500 Can't connect to localhost:8000 (Timeout) 478 500 Can't connect to localhost:8000 (Timeout) 1303 500 Can't connect to localhost:8000 (Timeout) 1746 500 Can't connect to localhost:8000 (Timeout) mink[/home/rojer]# sysctl -w net.inet.ip.portrange.randomized=0 net.inet.ip.portrange.randomized: 1 -> 0 mink[/home/rojer]# ./x.pl 24056, http://localhost:8000/junk, 2000: starting. mink[/home/rojer]# ./x.pl 24077, http://localhost:8000/junk, 2000: starting. mink[/home/rojer]# ./x.pl 24080, http://localhost:8000/junk, 2000: starting. mink[/home/rojer]# -- Deomid Ryabkov aka Rojer [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 8025844 smime.p7s Description: S/MIME Cryptographic Signature
Re: Freebsd 5.3 hangs under heavy load????
Amandeep Pannu wrote: Hi all, I have two Seagate SCSI drives 36GB and 8GB RAM and installed 5.3-REL with PAE and SMP support. Now the problem arises that the system hangs under heavy load and there are no error messages nothing. I have to hard boot it everytime it hangs. PAE must have something to do with this. i have similar reports from fellow admins (they run large free mail service): machines with lots (4+ gigs) of memory, 5.3R, SMP and PAE enabled just refused to cooperate, freezing and crashing all the way under load. sadly, having no time to dive into gory details, they just installed Linux on those and all has been going well since that... the point is: PAE and large memory configurations in general need more testing. -- Deomid Ryabkov aka Rojer [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 8025844 smime.p7s Description: S/MIME Cryptographic Signature
Re: Freebsd 5.3 with Broadcom BCM5721 PCI Express GbE
Amandeep Pannu wrote: 2) It doesnt detect the broadcom interfaces. They are Broadcom BCM5721 PCI Express GbE. the support is in -STABLE already, update to latest RELENG_5. -- Deomid Ryabkov aka Rojer [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 8025844 smime.p7s Description: S/MIME Cryptographic Signature
Re: FreeBSD 5.3R SMP Kernel not detecting 2nd CPU in a HP DL360(?)
Ulf Zimmermann wrote: I have a DL380 g3 with dual P4-3.2GHz 1MB L3 cache, the kern conf has just "options SMP" to make it work. Here is the top part and bottom part of dmesg from boot: ... SMP: AP CPU #1 Launched! ... kern.smp.active: 1 kern.smp.disabled: 0 kern.smp.cpus: 2 you should see 4 cpus "launching", assuming you haven't disabled hyperthreading. in fact, i have seen similar situation myself. FreeBSD would not recognize second physical CPU with hyperthreading enabled. it'd launch cpu #1 but not cpus 2 and 3. after eventually noticing it, i tried disabling hyperthreading in BIOS - it worked fine. i still had 2 cpus, but this time 2 physical cpus, and lower cpu load figures confirmed that those 2 "previous" cpus were in fact one physical + 1 hyperdreaded :) and this is not a problem of the particular server, i actually tried replacing the platform (moved hdds to the same box nearby) and it behaved in exactly the same manner. the platform is Fujitsu RX200 (2 x 2.8 Xeon), OS is FreeBSD 4.11-PRERELEASE. i still kinda have a box to play with (can bring it down to test during weekend), so if someone can offer insight, i can provide more info and maybe even a short-term remote ssh/serial console access. -- Deomid Ryabkov aka Rojer [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 8025844 smime.p7s Description: S/MIME Cryptographic Signature
Re: Low umass performance with USB 2.0 ports
Ian Dowse wrote: The patch in from the email below may help with the wdrain state - can you see if it makes any difference? this solved the problem i had with umass devices on VIA controller. works fine, thanks a lot! the problem i hade is described in the followup to usb/81621 (http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/81621) the original submitter seems to have VIA controller too. -- Deomid Ryabkov aka Rojer [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 8025844 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
Scott Long wrote: I wonder if that's the whole trick here. Would someone be willing to try the attached patch instead of the one that Ian posted? just tried the patch... no, it doesn't help. stalls still happen when reading large files from the device. -- Deomid Ryabkov aka Rojer [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 8025844 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
Hans Petter Selasky wrote: If Scott's patch doesn't work, could you have tried to install the following (compiles on FreeBSD 5/6/7): Download the three files below into a new directory and type "make install" (to uninstall type "make deinstall") http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2 http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2 Then recompile all USB modules and/or kernel, depending on your configuration. doesn't apply to freshly cvsupped RELENG_6: [skip] x sys/dev/usb2/usb_quirks.h x sys/dev/usb2/usb_subr.h (bzcat new_usb_1_5_4.diff.bz2 | patch -N -l -d /usr/src) || echo -n Hmm... Looks like a new-style context diff to me... The text leading up to this was: -- |*** sys/i386/include/bus_at386.h.ref Wed Oct 20 21:32:58 2004 |--- sys/i386/include/bus_at386.h Sat Nov 11 11:11:00 2000 -- File to patch: ^C -- Deomid Ryabkov aka Rojer [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 8025844 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
