Re: mbuf leak found... for real this time.
: between NFSv2 and NFSv3. :Yes, I concur with your patch whole-heartedly. Apparently last night I :was too-tired, and not intoxicated enough to understand the nfs_serv.c code :) : :I alas will not be able to test it. The machine is up and stable with 3k :mbufs in reserve.. maybe later :) : :As an aside, what about getting rid of that mbuf leak if a nfs-service :routine returns with error!=0? : :-- :David Cross | email: [EMAIL PROTECTED] Well, theoretically we just free the mbuf in the error case within nfs_syscalls.c/nfssvc_nfsd(), around line 661 (STABLE), or 650 (CURRENT). Realistically every single nfs server procedure would need to be audited to make sure that a non-NULL *mreq is valid in all error cases - not something I particularly want to do without commit privs from a crediting point of view. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Holy cow - path component freeing a mess? (was Re: D'oh!)
Julian Elischer wrote: talk to terry on this topic :-) He has a set of patches that straighten all this out You know, I almost made that comment. But I'd rather not have Terry started again. :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "Your usefulness to my realm ended the day you made it off Hustaing alive." -- Sun Tzu Liao to his ex-finacee, Isis Marik To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing ld.so in 3.2? SOLVED, Thank you!
Installing compat22 did it, thank you! Matthew At 04:40 PM 7/23/99 -0700, Matthew Dillon wrote: :Install the compat22 dist; you have an old a.out binary there. : : Greetings, : : I have a 3.2 install from CD-ROM and I am trying to run a commerical : program, i.e. I don't have the source, and it is giving me the following error: : : [Fri Jul 23 16:47:48 1999] [error] [client 216.47.238.65] malformed header from : script. Bad header=Couldn't open /usr/libexec/ld.so :... Btw, the netscape4.5.us port needs this too, along with half a dozen libraries in /usr/lib/aout/. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD: the stealth OS?
On Fri, Jul 23, 1999, Wes Peters wrote: Do I get a discount for having the same first name? Nope, you get charged double for attempting to share in the Matt-light. I've got you _all_ beat. Both of their first names is my middle name. I get through free! -- |Chris Costello [EMAIL PROTECTED] |Controlling complexity is the essence of computer programming. - Kernigan `-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Upgrading from 2.2.8 to 3.2-stable...
Well, I'm having problems upgrading a system from 2.2.8 to 3.2-stable. I checked the archives, and apparently others have run into this one as well. Unfortunately, I couldn't find a fix for it. The problem is when the upgrade procedure tries to build the elf version of libmytinfo. It generates an executable, mkcaplist, which it uses to generate the caplist.c file. This is an elf executable, which promptly coredumps when the makefile tries to run it. Now, I _know_ this library has been around for a while, and others have successfully done a "make upgrade." My question is: What the hell am I doing wrong? I'm just doing a "make upgrade" on a clean /usr/obj. It crashes when it gets to libmytinfo. That's it. Any help or pointers would be greatly appreciated. Thanks. -- Frank Mayhar [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: wd0 DMA errors]
On Sun, 25 Jul 1999 10:59:26 MST, Doug wrote: No answer on -current, any help appreciated. We're probably all sitting here thinking "I'm sure this was asked and answered recently. He can read his CURRENT mail like the rest of us." For the terminally lazy, this was a bug in the pci code, introduced a week or so ago and fixed in CURRENT and reverted in STABLE some time in the last few days. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandbox??
Sue Blake wrote: Nobody seems to be confident about the answer to my post to -questions. Below is the only public answer. It is typical of many private answers I received from otherwise knowledgeable people willing to make a partial educated guess but not willing to expose their ignorance publicly. They're all keen to know whatever I can find out :-) :-) On Mon, Jul 19, 1999 at 07:58:01AM -0400, T. William Wells wrote: In article [EMAIL PROTECTED], Sue Blake [EMAIL PROTECTED] wrote: : Could someone tell me what is a sandbox, what does it do, how does it : work, how do I use it, or where is it documented? : named(8) and security(8) seem to assume one already knows. It's a generic term. It refers to a restricted environment in which something is to be done. Exactly how a sandbox is implemented depends on the specific application. Without having read the references in the files you mentioned, here is my own take on sandbox. In some firewall books I have read, sandbox is used to refer to a machine connected to the net in a "protected" way. Basically, all packets to and from that machine go through a firewall. The machine, though inside the firewall, is isolated from the rest of the internal network. The sandbox can then be used to provide services in a more or less secure way. It cannot threat the internal network, because it can reach it even if breached, and it is not as exposed as it would be outside the firewall. If *think* this definition was given in the book by the TIS people, but, alas, I haven't read about firewalls in two years, and my firewall books are 12 thousand km away. And notice, too, that I'm *not* refering to the hacker's trap, whose name I can't recall right now. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "Is it true that you're a millionaire's son who never worked a day in your life?" "Yeah, I guess so." "Lemme tell you, son, you ain't missed a thing." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandbox??
A sandbox is a security term. It can mean two things: * A process which is placed inside a set of virtual walls that are designed to prevent someone who breaks into the process from being able to break into the wider system. The process is said to be able to "play" inside the walls. That is, nothing the process does in regards to executing code is supposed to be able to breech the walls so you do not have to do a detailed audit of its code to be able to say certain things about its security. The walls might be a userid, for example. This is the definition used in the security and named man pages. Take the 'ntalk' service, for example (see /etc/inetd.conf). This service used to run as userid root. Now it runs as userid tty. The tty user is a sandbox desiegned to make it more difficult for someone who has successfully hacked into the system via ntalk from being able to hack beyond that user id. * A process which is placed inside a simulation of the machine. This is more hard-core. Basically it means that someone who is able to break into the process may believe that he can break into the wider machine but is, in fact, only breaking into a simulation of that machine and not modifying any real data. The most common way to accomplish this is to build a simulated environment in a subdirectory and then run the processes in that directory chroot'd (i.e. "/" for that process is this directory, not the real "/" of the system). Another common use is to mount an underlying filesystem read-only and then create a filesystem layer on top of it that gives a process a seemingly writeable view into that filesystem. The process may believe it is able to write to those files, but only the process sees the effects -- other processes in the system do not, necessarily. An attempt is made to make this sort of sandbox so transparent that the user (or hacker) does not realize that he is sitting in it. UNIX implements two core sanboxes. One is at the process level, and one is at the userid level. Every UNIX process is completely firewalled off from every other UNIX process. One process can modify the address space of another. This is unlike Windows where a process can easily overwrite the address space of any other, leading to a crash. A UNIX process is owned by a patricular userid. If the userid is not the root user, it serves to firewall the process off from processes owned by other users. The userid is also used to firewall off on-disk data. -Matt Matthew Dillon [EMAIL PROTECTED] :Hi clever people : :Nobody seems to be confident about the answer to my post to -questions. :Below is the only public answer. It is typical of many private answers :I received from otherwise knowledgeable people willing to make a :partial educated guess but not willing to expose their ignorance :publicly. They're all keen to know whatever I can find out :-) : :On Mon, Jul 19, 1999 at 07:58:01AM -0400, T. William Wells wrote: : In article [EMAIL PROTECTED], : Sue Blake [EMAIL PROTECTED] wrote: : : Could someone tell me what is a sandbox, what does it do, how does it : : work, how do I use it, or where is it documented? : : named(8) and security(8) seem to assume one already knows. : : It's a generic term. It refers to a restricted environment in : which something is to be done. Exactly how a sandbox is : implemented depends on the specific application. : :As you see it is far from the complete 4-5 part answer I need. The :problem that I see is that our named.conf refers to this sandbox thing, :implies that it is actually the default method for BIND in FreeBSD (I :don't think it is though), and directs the user to man pages which :don't provide the necessary info to be able to confidently :(un)implement it. : :If nobody understands how this sandbox thing works, we should change :the named.conf that we supply. If somebody does, then they or someone :who they teach (me if really necessary) needs to document it so that :anyone seriously interested can figure it out on thier own (or at least :accept the defaults with confidence), and then change at least the :named.conf to point to that info. It sounds like a good idea, worth :giving people the resources to use it. : :(Email cc would be appreciated) : :-- : :Regards, :-*Sue*- : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandbox??
Sue Blake wrote: Nobody seems to be confident about the answer to my post to -questions. Below is the only public answer. It is typical of many private answers I received from otherwise knowledgeable people willing to make a partial educated guess but not willing to expose their ignorance publicly. They're all keen to know whatever I can find out :-) The usual use of the term "sandbox" means "restricted environment". A chroot(3) can be used to build this, and jail(3) is a stronger version, although this is not a usual use for the term. The term is popular in Java where it it implies that the (possibly hostile) applet _cannot_ do anything dangerous, because the environment it runs in has no API that allows this (like the applet cannot open arb files). The term "sandbox" in inetd.conf refers to a "su - safe_user; chroot safe_dir; app" environment (I think) so that app cannot do any damage even if compromised. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf leakage
In message [EMAIL PROTECTED] "David E. Cross" writes: : Any-who, is there a way I can get a look at the raw mbuf/mbuf-clusters? : I have a feeling that seeing the data in them would speak volumes of : information. Preferably a way to see them without DDB/panic would be ideal. I've also seen problems with amd with huge links on 3.2 Release The whole system hangs until the link is done, then it starts working again. Can't help you with looking at the mbuf stuff, however. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
In message [EMAIL PROTECTED] Chris Costello writes: :Are you going to be listing all the RFCs that apply? For : example, DNS is 1033, 1034, and 1035, and NNTP is 0850 and 0977. DNS is also 1123 and a few others in the 2xxx range. Then again, a lot are 1123 :-) NNTP should just list 977, however, since it obsoletes earlier RFCs. The net news format RFC isn't relevant to /etc/services, much like RFC 822 wouldn't be the one to list for smtp (since it describes the message format, not the protocol for smtp). For smtp, one of the RFCs would be RFC 823. (I just hope that I've not accidentally reversed those two RFCs). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandbox??
On Sun, Jul 25, 1999 at 11:36:49AM -0700, Matthew Dillon [EMAIL PROTECTED] wrote: A sandbox is a security term. It can mean two things: [...] UNIX implements two core sanboxes. One is at the process level, and one is at the userid level. Every UNIX process is completely firewalled off from every other UNIX process. One process can modify the address space of another. This is Can not. Silly typo ;) BTW, I have running bind running chroot()'ed in /var/named (where OpenBSD puts it). Can we now also put /var/named and all subdirs needed into FreeBSD? We can also add '-t /var/named' flag into commented out rc.conf startup for bind. I could supply more info to someone who can commit this into the tree... % tail /var/named/var/log/named-noise.log 25-Jul-1999 04:11:16.730 security: info: chrooted to /var/named 25-Jul-1999 04:11:16.871 security: info: group = bind 25-Jul-1999 04:11:16.872 security: info: user = bind % ps ax | grep named 113 ?? Is 0:00.02 /var/named/named -u bind -g bind -t /var/named -- Yan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandbox??
On Mon, 26 Jul 1999, Sue Blake wrote: If nobody understands how this sandbox thing works, we should change the named.conf that we supply. If somebody does, then they or someone Understanding a sandbox only requires the ability to read on the part of the user (something anyone in charge of named administration has hopefully learned, else they don't need to be administrating anything). As for the current named.conf format... I agree that it should be changed. Rc.conf currently references the fact that 'it may be possible to run named in a sandbox'. Named.conf says 'FreeBSD runs bind in a sandbox'. Saying FreeBSD does something one place while saying it may be possible to do it in another is... silly. The actual use is up to the administrator, so it seems logical to have named.conf examples for sandbox and non-sandbox configs. Mike Hoskins [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: InterMezzo: Project for kernel/FS hackers
On Thu, Jul 22, 1999 at 04:47:15PM -0600, Ronald G. Minnich wrote: I'm working with intermezzo now. It's interesting. Note that the VFS is quite simple, and defines a simple kernel-user channel which maps VFS ops to requests on an IPC channel. The possibilities are endless ... A freebsd port would be nice. Maybe you could use v9fs as a starting point. Ah, there's that "you" word again. Had everything gone to plan a few years ago, I'd have used FreeBSD to kickstart my Unix FS knowledge, and might be in a position to do that. Somehow I got sidetracked on to the Doc. Proj., which is kind of where I've stayed :-) N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: wd0 DMA errors]
Sheldon Hearn wrote: On Sun, 25 Jul 1999 10:59:26 MST, Doug wrote: No answer on -current, any help appreciated. We're probably all sitting here thinking "I'm sure this was asked and answered recently. He can read his CURRENT mail like the rest of us." I have indeed read my -current mail. Several bugs in the PCI and DMA code have been mentioned in the past week, but frankly I don't have enough expertise in either to know for sure that the bugs mentioned would produce the error messages I saw. A simple, "yes, those were the bugs fixed recently" is all that was needed. Thank you, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Wavelan-WavepointII
Hello, I am wondering if anyone has had success running bridging only between a wavelan IEEE802.11 in a BSD machine and a WavepointII using an IEEE802.11 card. I have had great succes using purely wavelan/BSD. Kirk McDonald To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
Vincent Poy wrote: On Thu, 22 Jul 1999, Doug wrote: On Wed, 21 Jul 1999, Vincent Poy wrote: Greetings everyone, What are the current good motherboards for FreeBSD for the pentium II and III? I know on the Pentium, it was the ASUS board but for the PII/PIII, is the Abit the better board? Also, I was wondering what is the fastest Celeron chip that can be overclocked to run at 100Mhz FSB? Does it matter if it's Slot 1 or PPGA based? Thanks. At work we're having good results with an Intel N440BX motherboard. It's a dual cpu board, running 2 PIII 500's like a champ. It also has the ability to redirect all console output (like boot/bios messages, etc.) to a serial console. It comes with a built in Etherexpress Pro 100+ as well. Cool... I thought the Intel motherboards weren't that good compared to other brands.. Hrrmm... what about them would be "not good," and how would I test it? I don't know enough about SMP hardware to know what to compare, but I do know that these are working fine for us, and at the speed the cpu's are running at I'm not sure that a few percentage points difference would be noticable. Also, the serial console option got me big points with the boss, since we have all sorts of remote console stuff set up in the office and the more that can be seen while booting a troubled box the better. I have an Asus P2B at home that I've run my Celeron 300A overclocked to 450 since the first of the year with no problems (and BIG fans). Hmmm, what kinda fans did you use and where can one get those? Is the 300A overclocked as fast as a regular PII 450Mhz? I got the fans from the store that sold me the CPU. It's a double fan with a big heat sink in the middle. http://www.thechipmerchant.com/ should do you up. As for speed, as far as I can tell on the few benchmarks I've run, yes, it's just as fast. Some things are actually faster since the onboard cache for the 300A runs at full speed. The old celerons without cache are dogs though, even if you do overclock them. If RC5 is any indication I can do 1.2Mkeys per second when there is no other load on the system. HTH, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Upgrading from 2.2.8 to 3.2-stable...
Apologies if this appears twice. The first attempt didn't appear to work. Well, I'm having problems upgrading a system from 2.2.8 to 3.2-stable. I checked the archives, and apparently others have run into this one as well. Unfortunately, I couldn't find a fix for it. The problem is when the upgrade procedure tries to build the elf version of libmytinfo. It generates an executable, mkcaplist, which it uses to generate the caplist.c file. This is an elf executable, which promptly coredumps when the makefile tries to run it. Now, I _know_ this library has been around for a while, and others have successfully done a "make upgrade." My question is: What the hell am I doing wrong? I'm just doing a "make upgrade" on a clean /usr/obj. It crashes when it gets to libmytinfo. That's it. Any help or pointers would be greatly appreciated. Thanks. -- Frank Mayhar [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Sun, 25 Jul 1999, Doug wrote: Vincent Poy wrote: On Thu, 22 Jul 1999, Doug wrote: On Wed, 21 Jul 1999, Vincent Poy wrote: Greetings everyone, What are the current good motherboards for FreeBSD for the pentium II and III? I know on the Pentium, it was the ASUS board but for the PII/PIII, is the Abit the better board? Also, I was wondering what is the fastest Celeron chip that can be overclocked to run at 100Mhz FSB? Does it matter if it's Slot 1 or PPGA based? Thanks. At work we're having good results with an Intel N440BX motherboard. It's a dual cpu board, running 2 PIII 500's like a champ. It also has the ability to redirect all console output (like boot/bios messages, etc.) to a serial console. It comes with a built in Etherexpress Pro 100+ as well. Cool... I thought the Intel motherboards weren't that good compared to other brands.. Hrrmm... what about them would be "not good," and how would I test it? I don't know enough about SMP hardware to know what to compare, but I do know that these are working fine for us, and at the speed the cpu's are running at I'm not sure that a few percentage points difference would be noticable. Also, the serial console option got me big points with the boss, since we have all sorts of remote console stuff set up in the office and the more that can be seen while booting a troubled box the better. I am not sure about the exact problems but I remember that Rodney Grimes of FreeBSD Inc. recommended the ASUS boards over the Intel boards for a reason. How does the serial console option work exactly? I have an Asus P2B at home that I've run my Celeron 300A overclocked to 450 since the first of the year with no problems (and BIG fans). Hmmm, what kinda fans did you use and where can one get those? Is the 300A overclocked as fast as a regular PII 450Mhz? I got the fans from the store that sold me the CPU. It's a double fan with a big heat sink in the middle. http://www.thechipmerchant.com/ should do you up. As for speed, as far as I can tell on the few benchmarks I've run, yes, it's just as fast. Some things are actually faster since the onboard cache for the 300A runs at full speed. The old celerons without cache are dogs though, even if you do overclock them. If RC5 is any indication I can do 1.2Mkeys per second when there is no other load on the system. Cool... We're actually running a Celeron 266 that is overclocked to 400 (4.0x100Mhz) and it's fast but I wonder what level of a PII is it comparable to since it doesn't have cache. Does Chip Merchant let you specify a date for the CPU's so you don't get anything earlier than that date? Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: deny ktrace without read permissions?
In article [EMAIL PROTECTED] you write: Yes, but /if/ KTRACE is present, today's code allows you to bypass the lack of read permissions on an executable. That shouldn't be allowed. The current behaviour could be regarded as a security hole actually :). No more so than core dumps do. I vote strongly against this change. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: deny ktrace without read permissions?
In message [EMAIL PROTECTED] Sheldon Hearn writes: : This doesn't look right. If I can execute a binary, I can have the : system allocate memory to me and but the binary image in it. It's my : memory. :-) Also, one can use a custom libc to get around the readonly ness, since functions in libc can access the entire memory space (at least on intel). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf leak found... for real this time.
: between NFSv2 and NFSv3. :Yes, I concur with your patch whole-heartedly. Apparently last night I :was too-tired, and not intoxicated enough to understand the nfs_serv.c code :) : :I alas will not be able to test it. The machine is up and stable with 3k :mbufs in reserve.. maybe later :) : :As an aside, what about getting rid of that mbuf leak if a nfs-service :routine returns with error!=0? : :-- :David Cross | email: cro...@cs.rpi.edu Well, theoretically we just free the mbuf in the error case within nfs_syscalls.c/nfssvc_nfsd(), around line 661 (STABLE), or 650 (CURRENT). Realistically every single nfs server procedure would need to be audited to make sure that a non-NULL *mreq is valid in all error cases - not something I particularly want to do without commit privs from a crediting point of view. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Holy cow - path component freeing a mess? (was Re: D'oh!)
Julian Elischer wrote: talk to terry on this topic :-) He has a set of patches that straighten all this out You know, I almost made that comment. But I'd rather not have Terry started again. :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Your usefulness to my realm ended the day you made it off Hustaing alive. -- Sun Tzu Liao to his ex-finacee, Isis Marik To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Missing ld.so in 3.2? SOLVED, Thank you!
Installing compat22 did it, thank you! Matthew At 04:40 PM 7/23/99 -0700, Matthew Dillon wrote: :Install the compat22 dist; you have an old a.out binary there. : : Greetings, : : I have a 3.2 install from CD-ROM and I am trying to run a commerical : program, i.e. I don't have the source, and it is giving me the following error: : : [Fri Jul 23 16:47:48 1999] [error] [client 216.47.238.65] malformed header from : script. Bad header=Couldn't open /usr/libexec/ld.so :... Btw, the netscape4.5.us port needs this too, along with half a dozen libraries in /usr/lib/aout/. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD: the stealth OS?
On Fri, Jul 23, 1999, Wes Peters wrote: Do I get a discount for having the same first name? Nope, you get charged double for attempting to share in the Matt-light. I've got you _all_ beat. Both of their first names is my middle name. I get through free! -- |Chris Costello ch...@calldei.com |Controlling complexity is the essence of computer programming. - Kernigan `-- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
[Fwd: wd0 DMA errors]
No answer on -current, any help appreciated. Doug Original Message My boxes at work are -current from 7/16. They both use IDE disks since other than system stuff the disk I/O for the real work is all NFS. In the daily logs this morning I see this: wd0: interrupt timeout (status 58rdy,seekdone,drq error 0) wd0: wdtimeout() DMA status 4 Can anyone shed some light on what that is, and how bad it is? I won't have access to the box itself till monday, but it would be nice to have some answers ready when I go in. Thanks, Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Upgrading from 2.2.8 to 3.2-stable...
Well, I'm having problems upgrading a system from 2.2.8 to 3.2-stable. I checked the archives, and apparently others have run into this one as well. Unfortunately, I couldn't find a fix for it. The problem is when the upgrade procedure tries to build the elf version of libmytinfo. It generates an executable, mkcaplist, which it uses to generate the caplist.c file. This is an elf executable, which promptly coredumps when the makefile tries to run it. Now, I _know_ this library has been around for a while, and others have successfully done a make upgrade. My question is: What the hell am I doing wrong? I'm just doing a make upgrade on a clean /usr/obj. It crashes when it gets to libmytinfo. That's it. Any help or pointers would be greatly appreciated. Thanks. -- Frank Mayhar fr...@exit.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
sandbox??
Hi clever people Nobody seems to be confident about the answer to my post to -questions. Below is the only public answer. It is typical of many private answers I received from otherwise knowledgeable people willing to make a partial educated guess but not willing to expose their ignorance publicly. They're all keen to know whatever I can find out :-) On Mon, Jul 19, 1999 at 07:58:01AM -0400, T. William Wells wrote: In article 19990719212431.d...@welearn.com.au, Sue Blake s...@welearn.com.au wrote: : Could someone tell me what is a sandbox, what does it do, how does it : work, how do I use it, or where is it documented? : named(8) and security(8) seem to assume one already knows. It's a generic term. It refers to a restricted environment in which something is to be done. Exactly how a sandbox is implemented depends on the specific application. As you see it is far from the complete 4-5 part answer I need. The problem that I see is that our named.conf refers to this sandbox thing, implies that it is actually the default method for BIND in FreeBSD (I don't think it is though), and directs the user to man pages which don't provide the necessary info to be able to confidently (un)implement it. If nobody understands how this sandbox thing works, we should change the named.conf that we supply. If somebody does, then they or someone who they teach (me if really necessary) needs to document it so that anyone seriously interested can figure it out on thier own (or at least accept the defaults with confidence), and then change at least the named.conf to point to that info. It sounds like a good idea, worth giving people the resources to use it. (Email cc would be appreciated) -- Regards, -*Sue*- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Fwd: wd0 DMA errors]
On Sun, 25 Jul 1999 10:59:26 MST, Doug wrote: No answer on -current, any help appreciated. We're probably all sitting here thinking I'm sure this was asked and answered recently. He can read his CURRENT mail like the rest of us. For the terminally lazy, this was a bug in the pci code, introduced a week or so ago and fixed in CURRENT and reverted in STABLE some time in the last few days. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sandbox??
Sue Blake wrote: Nobody seems to be confident about the answer to my post to -questions. Below is the only public answer. It is typical of many private answers I received from otherwise knowledgeable people willing to make a partial educated guess but not willing to expose their ignorance publicly. They're all keen to know whatever I can find out :-) :-) On Mon, Jul 19, 1999 at 07:58:01AM -0400, T. William Wells wrote: In article 19990719212431.d...@welearn.com.au, Sue Blake s...@welearn.com.au wrote: : Could someone tell me what is a sandbox, what does it do, how does it : work, how do I use it, or where is it documented? : named(8) and security(8) seem to assume one already knows. It's a generic term. It refers to a restricted environment in which something is to be done. Exactly how a sandbox is implemented depends on the specific application. Without having read the references in the files you mentioned, here is my own take on sandbox. In some firewall books I have read, sandbox is used to refer to a machine connected to the net in a protected way. Basically, all packets to and from that machine go through a firewall. The machine, though inside the firewall, is isolated from the rest of the internal network. The sandbox can then be used to provide services in a more or less secure way. It cannot threat the internal network, because it can reach it even if breached, and it is not as exposed as it would be outside the firewall. If *think* this definition was given in the book by the TIS people, but, alas, I haven't read about firewalls in two years, and my firewall books are 12 thousand km away. And notice, too, that I'm *not* refering to the hacker's trap, whose name I can't recall right now. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Is it true that you're a millionaire's son who never worked a day in your life? Yeah, I guess so. Lemme tell you, son, you ain't missed a thing. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sandbox??
A sandbox is a security term. It can mean two things: * A process which is placed inside a set of virtual walls that are designed to prevent someone who breaks into the process from being able to break into the wider system. The process is said to be able to play inside the walls. That is, nothing the process does in regards to executing code is supposed to be able to breech the walls so you do not have to do a detailed audit of its code to be able to say certain things about its security. The walls might be a userid, for example. This is the definition used in the security and named man pages. Take the 'ntalk' service, for example (see /etc/inetd.conf). This service used to run as userid root. Now it runs as userid tty. The tty user is a sandbox desiegned to make it more difficult for someone who has successfully hacked into the system via ntalk from being able to hack beyond that user id. * A process which is placed inside a simulation of the machine. This is more hard-core. Basically it means that someone who is able to break into the process may believe that he can break into the wider machine but is, in fact, only breaking into a simulation of that machine and not modifying any real data. The most common way to accomplish this is to build a simulated environment in a subdirectory and then run the processes in that directory chroot'd (i.e. / for that process is this directory, not the real / of the system). Another common use is to mount an underlying filesystem read-only and then create a filesystem layer on top of it that gives a process a seemingly writeable view into that filesystem. The process may believe it is able to write to those files, but only the process sees the effects -- other processes in the system do not, necessarily. An attempt is made to make this sort of sandbox so transparent that the user (or hacker) does not realize that he is sitting in it. UNIX implements two core sanboxes. One is at the process level, and one is at the userid level. Every UNIX process is completely firewalled off from every other UNIX process. One process can modify the address space of another. This is unlike Windows where a process can easily overwrite the address space of any other, leading to a crash. A UNIX process is owned by a patricular userid. If the userid is not the root user, it serves to firewall the process off from processes owned by other users. The userid is also used to firewall off on-disk data. -Matt Matthew Dillon dil...@backplane.com :Hi clever people : :Nobody seems to be confident about the answer to my post to -questions. :Below is the only public answer. It is typical of many private answers :I received from otherwise knowledgeable people willing to make a :partial educated guess but not willing to expose their ignorance :publicly. They're all keen to know whatever I can find out :-) : :On Mon, Jul 19, 1999 at 07:58:01AM -0400, T. William Wells wrote: : In article 19990719212431.d...@welearn.com.au, : Sue Blake s...@welearn.com.au wrote: : : Could someone tell me what is a sandbox, what does it do, how does it : : work, how do I use it, or where is it documented? : : named(8) and security(8) seem to assume one already knows. : : It's a generic term. It refers to a restricted environment in : which something is to be done. Exactly how a sandbox is : implemented depends on the specific application. : :As you see it is far from the complete 4-5 part answer I need. The :problem that I see is that our named.conf refers to this sandbox thing, :implies that it is actually the default method for BIND in FreeBSD (I :don't think it is though), and directs the user to man pages which :don't provide the necessary info to be able to confidently :(un)implement it. : :If nobody understands how this sandbox thing works, we should change :the named.conf that we supply. If somebody does, then they or someone :who they teach (me if really necessary) needs to document it so that :anyone seriously interested can figure it out on thier own (or at least :accept the defaults with confidence), and then change at least the :named.conf to point to that info. It sounds like a good idea, worth :giving people the resources to use it. : :(Email cc would be appreciated) : :-- : :Regards, :-*Sue*- : To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sandbox??
Sue Blake wrote: Nobody seems to be confident about the answer to my post to -questions. Below is the only public answer. It is typical of many private answers I received from otherwise knowledgeable people willing to make a partial educated guess but not willing to expose their ignorance publicly. They're all keen to know whatever I can find out :-) The usual use of the term sandbox means restricted environment. A chroot(3) can be used to build this, and jail(3) is a stronger version, although this is not a usual use for the term. The term is popular in Java where it it implies that the (possibly hostile) applet _cannot_ do anything dangerous, because the environment it runs in has no API that allows this (like the applet cannot open arb files). The term sandbox in inetd.conf refers to a su - safe_user; chroot safe_dir; app environment (I think) so that app cannot do any damage even if compromised. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sandbox??
Speaking of jail() ... it might be a good idea to change the int32 being passed for the IP address to something a little more portable or it will not be useable when IPV6 goes in. Perhaps a pointer and a length instead of an int32, or even pass a structural pointer and a length (which can remain backwards compatible by checking the passed length). -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mbuf leakage
In message 199907240405.aaa04...@cs.rpi.edu David E. Cross writes: : Any-who, is there a way I can get a look at the raw mbuf/mbuf-clusters? : I have a feeling that seeing the data in them would speak volumes of : information. Preferably a way to see them without DDB/panic would be ideal. I've also seen problems with amd with huge links on 3.2 Release The whole system hangs until the link is done, then it starts working again. Can't help you with looking at the mbuf stuff, however. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Mentioning RFC numbers in /etc/services
In message 19990724082555.a40...@holly.dyndns.org Chris Costello writes: :Are you going to be listing all the RFCs that apply? For : example, DNS is 1033, 1034, and 1035, and NNTP is 0850 and 0977. DNS is also 1123 and a few others in the 2xxx range. Then again, a lot are 1123 :-) NNTP should just list 977, however, since it obsoletes earlier RFCs. The net news format RFC isn't relevant to /etc/services, much like RFC 822 wouldn't be the one to list for smtp (since it describes the message format, not the protocol for smtp). For smtp, one of the RFCs would be RFC 823. (I just hope that I've not accidentally reversed those two RFCs). Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sandbox??
On Sun, Jul 25, 1999 at 11:36:49AM -0700, Matthew Dillon dil...@apollo.backplane.com wrote: A sandbox is a security term. It can mean two things: [...] UNIX implements two core sanboxes. One is at the process level, and one is at the userid level. Every UNIX process is completely firewalled off from every other UNIX process. One process can modify the address space of another. This is Can not. Silly typo ;) BTW, I have running bind running chroot()'ed in /var/named (where OpenBSD puts it). Can we now also put /var/named and all subdirs needed into FreeBSD? We can also add '-t /var/named' flag into commented out rc.conf startup for bind. I could supply more info to someone who can commit this into the tree... % tail /var/named/var/log/named-noise.log 25-Jul-1999 04:11:16.730 security: info: chrooted to /var/named 25-Jul-1999 04:11:16.871 security: info: group = bind 25-Jul-1999 04:11:16.872 security: info: user = bind % ps ax | grep named 113 ?? Is 0:00.02 /var/named/named -u bind -g bind -t /var/named -- Yan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sandbox??
On Mon, 26 Jul 1999, Sue Blake wrote: If nobody understands how this sandbox thing works, we should change the named.conf that we supply. If somebody does, then they or someone Understanding a sandbox only requires the ability to read on the part of the user (something anyone in charge of named administration has hopefully learned, else they don't need to be administrating anything). As for the current named.conf format... I agree that it should be changed. Rc.conf currently references the fact that 'it may be possible to run named in a sandbox'. Named.conf says 'FreeBSD runs bind in a sandbox'. Saying FreeBSD does something one place while saying it may be possible to do it in another is... silly. The actual use is up to the administrator, so it seems logical to have named.conf examples for sandbox and non-sandbox configs. Mike Hoskins m...@adept.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: InterMezzo: Project for kernel/FS hackers
On Thu, Jul 22, 1999 at 04:47:15PM -0600, Ronald G. Minnich wrote: I'm working with intermezzo now. It's interesting. Note that the VFS is quite simple, and defines a simple kernel-user channel which maps VFS ops to requests on an IPC channel. The possibilities are endless ... A freebsd port would be nice. Maybe you could use v9fs as a starting point. Ah, there's that you word again. Had everything gone to plan a few years ago, I'd have used FreeBSD to kickstart my Unix FS knowledge, and might be in a position to do that. Somehow I got sidetracked on to the Doc. Proj., which is kind of where I've stayed :-) N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in 37514...@cs.colorado.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: VMWare plug/quickie tests.
On Thu, Jul 15, 1999 at 07:14:03PM -0700, Jaye Mathisen wrote: I could grow to like it. I just wish that it was the other way around. I'd actually run NT if I could get it in a VMWare compartment under FreeBSD. Until that happens, I might just have to be content with slagging it off, NT that is, not VMWare ;b. Joe -- Josef KarthauserFreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [...@pavilion.net, j...@uk.freebsd.org, j...@tao.org.uk] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Squid - a bug in src/sys/kern/uipc_socket.c
I think committing this would be beneficial. Would someone w/ commit privs care to review and then commit this bit? I wrote it in rev 1.41 and gave it to the squid folks; it turned out to cause X to fail in unexplained ways so we reverted it. Then I added PRUS_MORETOCOME in rev 1.50, which was supposed to have fixed the problem. Let's please not put the hack back in; if PRUS_MORETOCOME is broken let's fix it instead. Is this an observed problem on recent FreeBSD versions, or just something read in the Squid FAQ? Bill To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: arpresolve: can't allocate llinfo for 255.255.255.0rt
Can anyone explain how or where the 199.15.320xc70f22 entry could have come from? I've been unable to remove it ... Have you tried route -delete 199.15.32.0 -netmask 199.15.34.0? (I'm guessing at the .0 part; it got truncated. netstat -nrA might help figure out what it really is) (I can't explain where it came from, other than maybe an oddly typo'd command; maybe a route add instead of an ifconfig?) Bill To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Fwd: wd0 DMA errors]
Sheldon Hearn wrote: On Sun, 25 Jul 1999 10:59:26 MST, Doug wrote: No answer on -current, any help appreciated. We're probably all sitting here thinking I'm sure this was asked and answered recently. He can read his CURRENT mail like the rest of us. I have indeed read my -current mail. Several bugs in the PCI and DMA code have been mentioned in the past week, but frankly I don't have enough expertise in either to know for sure that the bugs mentioned would produce the error messages I saw. A simple, yes, those were the bugs fixed recently is all that was needed. Thank you, Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Wavelan-WavepointII
Hello, I am wondering if anyone has had success running bridging only between a wavelan IEEE802.11 in a BSD machine and a WavepointII using an IEEE802.11 card. I have had great succes using purely wavelan/BSD. Kirk McDonald To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
Vincent Poy wrote: On Thu, 22 Jul 1999, Doug wrote: On Wed, 21 Jul 1999, Vincent Poy wrote: Greetings everyone, What are the current good motherboards for FreeBSD for the pentium II and III? I know on the Pentium, it was the ASUS board but for the PII/PIII, is the Abit the better board? Also, I was wondering what is the fastest Celeron chip that can be overclocked to run at 100Mhz FSB? Does it matter if it's Slot 1 or PPGA based? Thanks. At work we're having good results with an Intel N440BX motherboard. It's a dual cpu board, running 2 PIII 500's like a champ. It also has the ability to redirect all console output (like boot/bios messages, etc.) to a serial console. It comes with a built in Etherexpress Pro 100+ as well. Cool... I thought the Intel motherboards weren't that good compared to other brands.. Hrrmm... what about them would be not good, and how would I test it? I don't know enough about SMP hardware to know what to compare, but I do know that these are working fine for us, and at the speed the cpu's are running at I'm not sure that a few percentage points difference would be noticable. Also, the serial console option got me big points with the boss, since we have all sorts of remote console stuff set up in the office and the more that can be seen while booting a troubled box the better. I have an Asus P2B at home that I've run my Celeron 300A overclocked to 450 since the first of the year with no problems (and BIG fans). Hmmm, what kinda fans did you use and where can one get those? Is the 300A overclocked as fast as a regular PII 450Mhz? I got the fans from the store that sold me the CPU. It's a double fan with a big heat sink in the middle. http://www.thechipmerchant.com/ should do you up. As for speed, as far as I can tell on the few benchmarks I've run, yes, it's just as fast. Some things are actually faster since the onboard cache for the 300A runs at full speed. The old celerons without cache are dogs though, even if you do overclock them. If RC5 is any indication I can do 1.2Mkeys per second when there is no other load on the system. HTH, Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Upgrading from 2.2.8 to 3.2-stable...
Apologies if this appears twice. The first attempt didn't appear to work. Well, I'm having problems upgrading a system from 2.2.8 to 3.2-stable. I checked the archives, and apparently others have run into this one as well. Unfortunately, I couldn't find a fix for it. The problem is when the upgrade procedure tries to build the elf version of libmytinfo. It generates an executable, mkcaplist, which it uses to generate the caplist.c file. This is an elf executable, which promptly coredumps when the makefile tries to run it. Now, I _know_ this library has been around for a while, and others have successfully done a make upgrade. My question is: What the hell am I doing wrong? I'm just doing a make upgrade on a clean /usr/obj. It crashes when it gets to libmytinfo. That's it. Any help or pointers would be greatly appreciated. Thanks. -- Frank Mayhar fr...@exit.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Sun, 25 Jul 1999, Doug wrote: Vincent Poy wrote: On Thu, 22 Jul 1999, Doug wrote: On Wed, 21 Jul 1999, Vincent Poy wrote: Greetings everyone, What are the current good motherboards for FreeBSD for the pentium II and III? I know on the Pentium, it was the ASUS board but for the PII/PIII, is the Abit the better board? Also, I was wondering what is the fastest Celeron chip that can be overclocked to run at 100Mhz FSB? Does it matter if it's Slot 1 or PPGA based? Thanks. At work we're having good results with an Intel N440BX motherboard. It's a dual cpu board, running 2 PIII 500's like a champ. It also has the ability to redirect all console output (like boot/bios messages, etc.) to a serial console. It comes with a built in Etherexpress Pro 100+ as well. Cool... I thought the Intel motherboards weren't that good compared to other brands.. Hrrmm... what about them would be not good, and how would I test it? I don't know enough about SMP hardware to know what to compare, but I do know that these are working fine for us, and at the speed the cpu's are running at I'm not sure that a few percentage points difference would be noticable. Also, the serial console option got me big points with the boss, since we have all sorts of remote console stuff set up in the office and the more that can be seen while booting a troubled box the better. I am not sure about the exact problems but I remember that Rodney Grimes of FreeBSD Inc. recommended the ASUS boards over the Intel boards for a reason. How does the serial console option work exactly? I have an Asus P2B at home that I've run my Celeron 300A overclocked to 450 since the first of the year with no problems (and BIG fans). Hmmm, what kinda fans did you use and where can one get those? Is the 300A overclocked as fast as a regular PII 450Mhz? I got the fans from the store that sold me the CPU. It's a double fan with a big heat sink in the middle. http://www.thechipmerchant.com/ should do you up. As for speed, as far as I can tell on the few benchmarks I've run, yes, it's just as fast. Some things are actually faster since the onboard cache for the 300A runs at full speed. The old celerons without cache are dogs though, even if you do overclock them. If RC5 is any indication I can do 1.2Mkeys per second when there is no other load on the system. Cool... We're actually running a Celeron 266 that is overclocked to 400 (4.0x100Mhz) and it's fast but I wonder what level of a PII is it comparable to since it doesn't have cache. Does Chip Merchant let you specify a date for the CPU's so you don't get anything earlier than that date? Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: deny ktrace without read permissions?
jk The intent of this change is to prevent a user from seeing how an jk executable with '--x--x--x' perms works by ktrace'ing its execution. jk My question to -hackers is: is this a useful semantic? Would it break jk anything if added? nw If we make kernel auditing based upon KTRACE (which may or may not nw happen), this is not a useful change since we need to be able to 'audit' nw system calls regardless of whether or not KTRACE is used. If this kind This particular change should not affect the future auditing tool. The [execve] system call will still be logged as having been attempted; the control flow remains the same as for the current ``no execute perms'' case but with a stricter check if KTRACE'ing is on for the process. nw If security is an issue, KTRACE shouldn't be in the system. Yes, but /if/ KTRACE is present, today's code allows you to bypass the lack of read permissions on an executable. That shouldn't be allowed. The current behaviour could be regarded as a security hole actually :). Part of the confusion comes from the meaning of the 'x' bit when KTRACE'ing is also permitted. Ordinarily the 'x' bit determines if a user can execute a file. But should execute permissions also imply the ability to trace the execution of the process? If so, the value of a permission mask like '--x--x--x' is weakened because although you cannot read the file, you can 'see inside' it, indirectly. The PR proposes (and the patch given earlier implements) tighter security on the premise that security in the presence of KTRACE should be at least as tight as without KTRACE. It achieves this by requiring read permissions on an executable before it can be KTRACE'd. Regards, Koshy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sandbox??
:Understanding a sandbox only requires the ability to read on the part of :the user (something anyone in charge of named administration has hopefully :learned, else they don't need to be administrating anything). : :As for the current named.conf format... I agree that it should be :changed. Rc.conf currently references the fact that 'it may be possible :to run named in a sandbox'. Named.conf says 'FreeBSD runs bind in a :sandbox'. Saying FreeBSD does something one place while saying it may be :possible to do it in another is... silly. : :The actual use is up to the administrator, so it seems logical to have :named.conf examples for sandbox and non-sandbox configs. : :Mike Hoskins :m...@adept.org The sandbox code for bind is not a novice exercise, which is why it is commented out by default. This is mainly because bind insists on doing things which make sandboxing difficult - you can't HUP it, for example, or bring interfaces down and up. The comment in the sample named.conf is wrong, it isn't on by default. Bind has a number of design faults that make it difficult to run outside of root. It would probably work in a jail(), though, if someone wants to work on that. The sandbox for the comsat and ntalk daemons does work and is on by default. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: deny ktrace without read permissions?
In article 199907260450.vaa10559.kithrup.freebsd.hack...@freefall.freebsd.org you write: Yes, but /if/ KTRACE is present, today's code allows you to bypass the lack of read permissions on an executable. That shouldn't be allowed. The current behaviour could be regarded as a security hole actually :). No more so than core dumps do. I vote strongly against this change. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Squid - a bug in src/sys/kern/uipc_socket.c
:I wrote it in rev 1.41 and gave it to the squid folks; it turned out :to cause X to fail in unexplained ways so we reverted it. Then I added :PRUS_MORETOCOME in rev 1.50, which was supposed to have fixed the problem. :Let's please not put the hack back in; if PRUS_MORETOCOME is broken :let's fix it instead. : :Is this an observed problem on recent FreeBSD versions, or just something :read in the Squid FAQ? : : Bill Looking at the PRUS_MORETOCOME code again I think it does solve this particular problem, albeit in a somewhat more complex fashion. I can see why the original patch failed - it set the atomic flag unconditionally and blew two cases in the loop. In general, I think it would have been cleaner to solve this sort of thing at the higher level. That is, correcting the original patch rather then introducing the comparitively greater complexity of PRUS_MORETOCOME. But since we would no longer be fixing a 'bug' it's up to you as the author to decide which solution you want. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: deny ktrace without read permissions?
On Sun, 25 Jul 1999 21:50:55 MST, jko...@freebsd.org wrote: Yes, but /if/ KTRACE is present, today's code allows you to bypass the lack of read permissions on an executable. That shouldn't be allowed. The current behaviour could be regarded as a security hole actually :). This doesn't look right. If I can execute a binary, I can have the system allocate memory to me and but the binary image in it. It's my memory. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: deny ktrace without read permissions?
jk Yes, but /if/ KTRACE is present, today's code allows you to bypass jkthe lack of read permissions on an executable. That shouldn't be jkallowed. The current behaviour could be regarded as a security jkhole actually :). sef No more so than core dumps do. Yes, but an application can protect itself from an inadvertent core dump. It can't (today) against being ktrace'd. sef I vote strongly against this change. Noted, thanks. I will summarize the result of the discussion in a followup to kern/3546. Regards, Koshy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: deny ktrace without read permissions?
Yes, but an application can protect itself from an inadvertent core dump. It can't (today) against being ktrace'd. You'd better fix ptrace and procfs then. Of course, that breaks everything that has always been true, but, hey, it's better to be wrong than right, I guess? if you care about security, you made the damned executable suid or sgid. Then ktrace, ptrace, truss, and core dumps do not work. Even if it simply does setuid(getruid()). To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
