From owner-freebsd-security Sun Jul 11 1:44:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (Postfix) with ESMTP id 33D3114D3D for ; Sun, 11 Jul 1999 01:44:37 -0700 (PDT) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id SAA01425; Sun, 11 Jul 1999 18:44:44 +1000 (EST) From: Darren Reed Message-Id: <199907110844.SAA01425@cheops.anu.edu.au> Subject: Re: Syslog alternatives? To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Sun, 11 Jul 1999 18:44:43 +1000 (EST) Cc: security@FreeBSD.ORG In-Reply-To: <19990710013937.A9554@keltia.freenix.fr> from "Ollivier Robert" at Jul 10, 99 01:39:37 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Ollivier Robert, sie said: > > According to Sergei Kolobov: > > More information is available at: > > http://coombs.anu.edu.au/~avalon/nsyslog.html > > Don't forget the other one, Secure Syslog, by Brazilian guys. > > ============================================================================== > Secure Syslog package > INSTALL file > > (C)1998 Core-SDI. Buenos Aires, Argentina. > ============================================================================== > ... > 1.a. Getting the last version > > The last version of the secure syslog package will always be available > at http://www.core-sdi.com/ssyslog. You may want to check out for a new > release before installing. I think the URL you want is: http://www.core-sdi.com/English/slogging/ssyslog.html Although from there, the hURL to download ssyslog.tar.gz is broked. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 11 1:57:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (Postfix) with ESMTP id 8748014D3D for ; Sun, 11 Jul 1999 01:57:41 -0700 (PDT) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id SAA01541; Sun, 11 Jul 1999 18:57:54 +1000 (EST) From: Darren Reed Message-Id: <199907110857.SAA01541@cheops.anu.edu.au> Subject: Re: Syslog alternatives? To: robert+freebsd@cyrus.watson.org Date: Sun, 11 Jul 1999 18:57:54 +1000 (EST) Cc: alla@sovlink.ru, security@FreeBSD.ORG In-Reply-To: from "Robert Watson" at Jul 9, 99 04:20:13 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Robert Watson, sie said: [...] > Or even less interesting: > > What happens to log records being sent over the network to a host that is > in the process of rebooting? > > Or: > > What happens to network logging if you send an ICMP connection refused to > the client syslog host? Or what happens to log messages sent whilst it is sync'ing data to disk with fsync() ? Think /dev/klog as well as UDP here! > Clearly syslogd leaves much to be desired. Yes. The current syslogd shipped with Solaris is actually very good for what it can do in avoiding losing messages. > However, it works fairly well if configured carefully. For some broad defniition of "well". > There have been discussions of alternatives, and > I think someone claimed to have written a secure syslog at one point; I > don't have a reference for it. I believe Schneier coauthored a paper on > some of the cryptographic issues, also. Not co-authored, authored. He has also applied for patents on the ideas therein, so wait and see there. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 11 2: 1:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (Postfix) with ESMTP id 0FB2914D3D for ; Sun, 11 Jul 1999 02:01:07 -0700 (PDT) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id TAA01580; Sun, 11 Jul 1999 19:01:26 +1000 (EST) From: Darren Reed Message-Id: <199907110901.TAA01580@cheops.anu.edu.au> Subject: Re: Syslog alternatives? To: imp@village.org (Warner Losh) Date: Sun, 11 Jul 1999 19:01:25 +1000 (EST) Cc: alla@sovlink.ru, security@FreeBSD.ORG In-Reply-To: <199907091625.KAA20308@harmony.village.org> from "Warner Losh" at Jul 9, 99 10:25:55 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Warner Losh, sie said: > > In message <37859B74.7528C158@sovlink.ru> Alla Bezroutchko writes: > : Could someone explain me or point me to some resources that explain > : why syslogd is bad? > > By default, syslogd will accept messages from anybody. DoS > implications in doing that are ignored, so it remains vulnerable to a > fill up the disk attack. Secure switches make it less vulnerable. > > I don't think that there is anything major enough wrong with syslogd > to actually try to replace it. If there are bad things that can > happen when -s is specified, I'd sure like to know about them. Think about the issues with fsync(). I'm looking at ways around it, but without threads, it isn't easy. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 11 2: 1:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (Postfix) with ESMTP id BDC1815156 for ; Sun, 11 Jul 1999 02:01:48 -0700 (PDT) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id TAA01593; Sun, 11 Jul 1999 19:02:08 +1000 (EST) From: Darren Reed Message-Id: <199907110902.TAA01593@cheops.anu.edu.au> Subject: Re: Syslog alternatives? To: imp@village.org (Warner Losh) Date: Sun, 11 Jul 1999 19:02:08 +1000 (EST) Cc: alla@sovlink.ru, avalon@coombs.anu.edu.au, security@FreeBSD.ORG In-Reply-To: <199907091628.KAA20328@harmony.village.org> from "Warner Losh" at Jul 9, 99 10:28:15 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Warner Losh, sie said: > > In message <3785AB58.2B3D8F05@sovlink.ru> Alla Bezroutchko writes: > : > Prove to me that your log files have any integrity, in such a way that > : > I cannot dispute it. > : > : How integrity is achieved with syslog's alternatives? > > That's a good question.... In order to do that, you'd have to have > some kind of public-key private-key mechanism based on shared secrets > to be sure. I'm not sure how you can really achieve a secure log file > integrity when things like VI exist... Who says it needs to be stored in the same file ? Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 11 2: 4:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (Postfix) with ESMTP id C5F4814D3D for ; Sun, 11 Jul 1999 02:04:27 -0700 (PDT) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id TAA01620; Sun, 11 Jul 1999 19:04:36 +1000 (EST) From: Darren Reed Message-Id: <199907110904.TAA01620@cheops.anu.edu.au> Subject: Re: Syslog alternatives? To: robert+freebsd@cyrus.watson.org Date: Sun, 11 Jul 1999 19:04:35 +1000 (EST) Cc: proff@suburbia.net, imp@village.org, alla@sovlink.ru, avalon@coombs.anu.edu.au, security@FreeBSD.ORG In-Reply-To: from "Robert Watson" at Jul 9, 99 12:45:32 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Robert Watson, sie said: [...] > I still lean towards a combination of existing securelevel code, and a > protected process flag indicating that the process may not be intefered > with by unauthorized userland code (i.e., no debugging, signaling, etc). That can be used to solve a suite of different problems. Interesting idea, none the less. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 11 3:15:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (Postfix) with ESMTP id E1CAA14F09 for ; Sun, 11 Jul 1999 03:15:43 -0700 (PDT) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id UAA02040; Sun, 11 Jul 1999 20:15:49 +1000 (EST) From: Darren Reed Message-Id: <199907111015.UAA02040@cheops.anu.edu.au> Subject: Re: Syslog alternatives? To: robert+freebsd@cyrus.watson.org Date: Sun, 11 Jul 1999 20:15:48 +1000 (EST) Cc: sgk@cpmc.net, avalon@coombs.anu.edu.au, alla@sovlink.ru, security@FreeBSD.ORG In-Reply-To: from "Robert Watson" at Jul 9, 99 05:42:26 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Robert Watson, sie said: [...] > Wasn't the one I was thinking of, but it certainly qualifies :-). Does it > actually authenticate the log data, or only the connection? It authenticates the connection (SSL), it can also authenticate the data exchanged (protection against connection corruption). It does not authenticate what gets saved to disk - that takes a human. > I had in mind > a protected process or kernel integrity protection service perhaps > involving key management for signing of log records, plus rotation of key > material, etc. I'll have to dig up the secure logging paper. And how do you authenticate what the kernel says ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 11 9:36:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2485C14CAB for ; Sun, 11 Jul 1999 09:36:56 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id SAA26902; Sun, 11 Jul 1999 18:36:54 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA01155; Sun, 11 Jul 1999 18:36:49 +0200 (MET DST) Date: Sun, 11 Jul 1999 18:36:48 +0200 From: Eivind Eklund To: Warner Losh Cc: proff@suburbia.net, alla@sovlink.ru, avalon@coombs.anu.edu.au, security@FreeBSD.ORG Subject: Re: Syslog alternatives? Message-ID: <19990711183648.A597@bitbox.follo.net> References: <19990709163459.22243.qmail@suburbia.net> <199907091638.KAA20428@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199907091638.KAA20428@harmony.village.org>; from Warner Losh on Fri, Jul 09, 1999 at 10:38:16AM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jul 09, 1999 at 10:38:16AM -0600, Warner Losh wrote: > In message <19990709163459.22243.qmail@suburbia.net> proff@suburbia.net writes: > : Just because you can't think of an answer doesn't mean there isn't one :) > > So elighten me :-) 1. Set up a distributed secure timestamp service (this is non-trivial but doable - you need to base yourself on a trust model where you assume a random N-out-of-M timestamp server will not all fake timestamp signatures, and a lot of constraints on how the timestamp client is allowed to select servers to use). 2. Hash portions of your log regularly (e.g, every hour). 3. Get a timestamp signature on your hash, and store it. Of course, this depends on for what purpose you want your log to be trustworthy. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 11 23:19:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 3A67514C84 for ; Sun, 11 Jul 1999 23:19:29 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id IAA38260; Mon, 12 Jul 1999 08:18:51 +0200 (CEST) (envelope-from des) To: security@freebsd.org Subject: Module magic From: Dag-Erling Smorgrav Date: 12 Jul 1999 08:18:50 +0200 Message-ID: Lines: 7 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thought this'd be of interest to this list: http://thc.pimmel.com/files/thc/bsdkern.html DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 0:43:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (Postfix) with ESMTP id 1B74914C26 for ; Mon, 12 Jul 1999 00:43:48 -0700 (PDT) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id RAA08815; Mon, 12 Jul 1999 17:41:30 +1000 (EST) From: Darren Reed Message-Id: <199907120741.RAA08815@cheops.anu.edu.au> Subject: Re: Module magic To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Mon, 12 Jul 1999 17:41:30 +1000 (EST) Cc: security@FreeBSD.ORG In-Reply-To: from "Dag-Erling Smorgrav" at Jul 12, 99 08:18:50 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Dag-Erling Smorgrav, sie said: > > Thought this'd be of interest to this list: > > http://thc.pimmel.com/files/thc/bsdkern.html So what ? Nothing in that document is "new" although it might be the first time it's been documented for script-kiddies. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 1:44:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 26DAB14BE4 for ; Mon, 12 Jul 1999 01:44:45 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id EAA08962; Mon, 12 Jul 1999 04:41:47 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Mon, 12 Jul 1999 04:41:47 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Nate Williams Cc: Darren Reed , Ben Gras , freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? In-Reply-To: <199907091711.LAA07208@mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 9 Jul 1999, Nate Williams wrote: > My thinking is that we 'pre-allocate' a AUDIT_RECORD_FAILED record, and > use it to inform the system that a record was unable to be generated. > Therefore, you have an idea that something is missing, but you don't > slow down the the system or cause deadlock. Sounds great. And the existence of such a record in the record stream would cause an appropriate IDS module to start flailing. > Ahh, I understand now. You are worried about one or the other of > namei/audit copyin being redundant. I misunderstood both you and > Garrett. Would it be possible to copy the string from the namei buffer, > thus avoiding the issue of modifying namei? I haven't looked closely at the namei implementation -- at some point the entire string is dumped into a KTRACE record by namei(), I assume, and that might be an appropriate place to deal with this. I don't have bundles of source code in front of me, but I seem to recall that namei() acts on a name lookup descriptor of some kind, perhaps allocated on the stack for the process? > > I did something like this to add speculative process execution to > > FreeBSD/i386 a few months ago (that is, generating disk prefetch hints > > based on speculatively executing a sandboxed process copy), and it proved > > quite straightforward. However, I believe the architecture-dependent code > > is what sits directly below the syscall code: we should perhaps insert > > another architecture-independent layer that wraps the syscall, where > > things like this can be placed. > > However, in the 'generic' code, it may not be obvious why the error > occured, and this makes it more difficult to generate an audit record > 'atomically' since the creation of the record happens in a completely > different code-base from the 'end' of the record. We'd need to design > some sort of even model in the audit record generation code, as well as > pass in information in each sub-record to identify which record the > sub-record belongs to. My thought was to arrange the code as follows. Currently, the FreeBSD kernel code does something like the following: kern_exec.c:execve() +------------------+ archspecific:trap.c| | -------------------+ +--------- Again, without source in front of me I'm not sure I have this exacting right but... I am suggesting breaking out some of the syscall switch code from occuring in the architecture-specific section. I.e., kern_exec.c:execve() +------------------- kern/kern_syscall.c| +------------------+ archsp| ------+ And the middle syscall layer would accept a struct proc and information on the syscall request. Its responsibility would be to create an audit record, tag it with the syscall number, pid, credentials, and any other data consistent across syscalls that needs to be in the audit record, then call the appropriate syscall code through the switch/sysvec array. On return from the syscall, it would tag the audit record with the return code, error condition a timestamp, and commit the audit record. It would then be the responsibility of the syscall code itself to submit a list of arguments as appropriate, as well as any more detailed subject/object information, etc. This gives us a architecture-independent location to automatically manage audit records for syscalls, and allows the syscall-specific code to manage its own syscall-specific audit data as it sees fit. Presumably either the current audit record reference would be passed in as an argument to the syscall, be accessible via curproc, or whatever the most appropriate way to do it would be. Signals could probably be handled the same way. > > Similarly, auditing signal delivery would > > need to happen the same way: currently signal deliver lives in > > architecture-dependent-land, and we'd want the auditing wrapper to sit > > somewhere independent of architecture, I suspect. > > Are signals required for IDS? (Showing my ignorance here...) A useful IDS module might consist of: Watch for a process that receives data from a network socket or local IPC pipe and sigsegv's within two (or n) syscalls of receiving the data. Or more specifically: Watch for a process started by inetd that receives data from a network socket or local IPC pipe and sigsegv's within n syscalls of receiving the data. Etc, etc. Clearly also you'd want to be able to ignore uninteresting signals, as things like timer delivery might be quite boring in most circumstances. > > As Garrett mentions, there will still be a context record from somewhere > > that could be extended to carry an active audit record for the activities > > of that context. Presumably that is the place to put it? > > How is this record 'identified' from the other records being generated > in parallel by the other CPUs? (In other words, what identifies this > process from other process in the above code. We're not passing the > proc structure around....) Well, presumably proc p is passed into the syscall, and could be passed elsewhere. I would imagine that p is passed into namei() as it would be required to work from the cwd and process root, etc. What probably does require some more thought would be various thread models that might be implemented later. Really we want to be able to have one audit record in process at any time for each possible active process context, I believe. > n /sys/kern/kern_exec.c, the syscall 'entry/exit' point is in the > routine is: > > /* > * execve() system call. > */ > int > execve(p, uap, retval) > struct proc *p; > register struct execve_args *uap; > int *retval; > { > > This is the code that needs to be instrumented, otherwise we have a > nightmare on our hands. We need to know that kind of information > anyway, so why not put in in the most likely place. This also buys us > the cross-platform compatability (not MD code), and makes it *very* > obvious what information is gathered. > > Unfortunately, it means changing lots of kernel files, but to do this > correctly and in a way that is understandable, I don't see a better > solution. > > Trying to 'sniff' what the syscall is at a lower layer and generating > the necessary information means we may end up doing the same sort of > information gathering that already exists in the real system call > implementation. > > In other words, I think we're in violent agreement, but I'm not sure. ;) Largely. The nice thing about adding the audit record creation/commital outside of this syscall code though is that we get at least introductory auditing on all syscalls without hassle: we know the syscall number, information on the process, and the return value. We can also take this opportunity to determine if the syscall actually did tag it at all: we can flag audit records before executing the syscall and observe if they cleared the flag by submitting data. If not, we can raise a warning message that a syscall without auditing instrumented for it has been called, warning the sysadmin or syscall implementer that all is not well from an auditing standpoint. We indeed both violently agree that argument auditing, etc, must happen inside the syscall. But my temptation is to push a little of the general-purpose work out of the syscall and into the handler. > > > > POSIX.1E only defines a way to tell whether auditing is turned on or off > > > > for a specific process, and to toggle that (so that, for example, the > > > > audit daemon can turn off auditing so as to prevent feedback on audit > > > > record delivery). This seems to broad to me. Suppose active IDS modules > > > > only require fork(), exec() and exit() tracing--then delivering the > > > > 20,000 calls to gettimeofday() is a waste of resources. > > > > > > See above. However, building a truly generic filtering mechanism would > > > be 'hard to do', so for now I think we can live with no filtering, or a > > > very simple filtering scheme. But, will the FreeBSD kernel maintainers > > > allow this is another story. :( > > > > See above: simple stuff in kernel may be the optimum approach, and I > > suspect a little bit of simple goes a long way. > > Agreed, although a mechanism similar to BPF may allow for more 'complex' > filtering mechanisms and still be quite effecient at the kernel. My concern is not that a language and programming model couldn't be devised, but that seeking through arguments to syscalls and managing types may be fairly costly: with packets in bpf you just look at offsets and values, and no looping. Clearly this is something we'll need to experiment with quite a bit: having a flexible query front end in the user-land audit daemon could allow us to experiment with various backends with various degrees of complexity. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 1:45:10 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 76D9F14BE4 for ; Mon, 12 Jul 1999 01:45:07 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id EAA08971; Mon, 12 Jul 1999 04:43:15 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Mon, 12 Jul 1999 04:43:15 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Darren Reed Cc: proff@suburbia.net, imp@village.org, alla@sovlink.ru, security@FreeBSD.ORG Subject: Re: Syslog alternatives? In-Reply-To: <199907110904.TAA01620@cheops.anu.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 11 Jul 1999, Darren Reed wrote: > In some mail from Robert Watson, sie said: > [...] > > I still lean towards a combination of existing securelevel code, and a > > protected process flag indicating that the process may not be intefered > > with by unauthorized userland code (i.e., no debugging, signaling, etc). > > That can be used to solve a suite of different problems. Interesting idea, > none the less. I've been meaning to implement this for a long time, as I've needed it for auditing stuff, as well as a number of other projects. I wonder if it would be appropriate to work on a more general policy, such as requiring processes to flag themselves as accessible from higher securelevels before they are. There might be some race conditions involving forks and pipes, however... Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 1:59:17 1999 Delivered-To: freebsd-security@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 3648B14CF5 for ; Mon, 12 Jul 1999 01:59:03 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 2B14C8A; Mon, 12 Jul 1999 16:58:57 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Darren Reed Cc: des@flood.ping.uio.no (Dag-Erling Smorgrav), security@FreeBSD.ORG Subject: Re: Module magic In-reply-to: Your message of "Mon, 12 Jul 1999 17:41:30 +1000." <199907120741.RAA08815@cheops.anu.edu.au> Date: Mon, 12 Jul 1999 16:58:57 +0800 From: Peter Wemm Message-Id: <19990712085857.2B14C8A@overcee.netplex.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Darren Reed wrote: > In some mail from Dag-Erling Smorgrav, sie said: > > > > Thought this'd be of interest to this list: > > > > http://thc.pimmel.com/files/thc/bsdkern.html > > So what ? > > Nothing in that document is "new" although it might be the > first time it's been documented for script-kiddies. Yeah, the main worrying thing about it is the hard coding of internal data structures and bypassing of proper interfaces. I'm half thinking about doing a couple of arbitary rearrangements of some internal (opaque) data structures to make their life a bit more exciting. I'd rather a box panic and burn if a script kiddie gets in and tries to use some of these ``techniques'' than have it run whatever they like undetected. This will be totally harmless to the existing modules since the data structures are not used outside kern_*.c. > Darren Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 2:39:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2600814C18 for ; Mon, 12 Jul 1999 02:39:30 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id FAA09080; Mon, 12 Jul 1999 05:38:37 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Mon, 12 Jul 1999 05:38:37 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Peter Wemm Cc: Darren Reed , Dag-Erling Smorgrav , security@FreeBSD.ORG Subject: Re: Module magic In-Reply-To: <19990712085857.2B14C8A@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 12 Jul 1999, Peter Wemm wrote: > Darren Reed wrote: > > In some mail from Dag-Erling Smorgrav, sie said: > > > > > > Thought this'd be of interest to this list: > > > > > > http://thc.pimmel.com/files/thc/bsdkern.html > > > > So what ? > > > > Nothing in that document is "new" although it might be the > > first time it's been documented for script-kiddies. > > Yeah, the main worrying thing about it is the hard coding of internal data > structures and bypassing of proper interfaces. I'm half thinking about > doing a couple of arbitary rearrangements of some internal (opaque) data > structures to make their life a bit more exciting. I'd rather a box panic > and burn if a script kiddie gets in and tries to use some of these > ``techniques'' than have it run whatever they like undetected. This will > be totally harmless to the existing modules since the data structures are > not used outside kern_*.c. Have to be a little careful with structs such as struct proc that have zero-able and copy-able sections at fork(). As using securelevels to disable module loading is currently not really too feasible for the mass-market, the best thing to do might just be to provide a sysctl that turns off module loading, and encourage server users to toggle the sysctl once all needed modules are loaded to prevent nasty-modules from being loaded. Needless to say, it would be a one-way toggle. :-) Needless to say, nothing the document says is new (presumably many of us have written modules just like these to experiment with them, and the techniques of syscall intercepting and replacement are useful from the perspective of securing the system, as well as breaking it :-). At least that I've seen, and no doubt it will suffer from the rapid development of the module interface (i.e., dependencies on modules, etc). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 2:45:40 1999 Delivered-To: freebsd-security@freebsd.org Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (Postfix) with ESMTP id 812D014DD6 for ; Mon, 12 Jul 1999 02:45:34 -0700 (PDT) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id TAA09669; Mon, 12 Jul 1999 19:45:57 +1000 (EST) From: Darren Reed Message-Id: <199907120945.TAA09669@cheops.anu.edu.au> Subject: Re: Module magic To: robert+freebsd@cyrus.watson.org Date: Mon, 12 Jul 1999 19:45:57 +1000 (EST) Cc: security@freebsd.org In-Reply-To: from "Robert Watson" at Jul 12, 99 05:38:37 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Robert Watson, sie said: > > Have to be a little careful with structs such as struct proc that have > zero-able and copy-able sections at fork(). As using securelevels to > disable module loading is currently not really too feasible for the > mass-market, the best thing to do might just be to provide a sysctl that > turns off module loading, and encourage server users to toggle the sysctl > once all needed modules are loaded to prevent nasty-modules from being > loaded. Needless to say, it would be a one-way toggle. :-) FWIW, I believe NetBSD systems (and OpenBSD systems) ship configured to boot with securelevel == 0, as opposed to FreeBSD which appears to default to -1. FreeBSD should be the same as the others, in this respect. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 3:25: 2 1999 Delivered-To: freebsd-security@freebsd.org Received: from eltex.ru (ELTEX-2-SPIIRAS.nw.ru [195.19.204.46]) by hub.freebsd.org (Postfix) with ESMTP id 6847814C8E for ; Mon, 12 Jul 1999 03:24:56 -0700 (PDT) (envelope-from antuan@eltex.ru) Received: from gadget.eltex.ru (root@gadget.eltex.ru [195.19.198.14]) by eltex.ru (8.8.8/8.8.8) with SMTP id OAA12444 for ; Mon, 12 Jul 1999 14:24:59 +0400 (MSD) Received: by gadget.eltex.ru (ssmtp TIS-0.5alpha, 19 Oct 1998); Mon, 12 Jul 1999 14:23:23 +0400 Received: from undisclosed-intranet-sender id xma021373; Mon, 12 Jul 99 14:23:10 +0400 Received: (from antuan@localhost) by tyger.hq.eltex.ru (8.9.2/8.8.8) id OAA17553 for security@FreeBSD.ORG; Mon, 12 Jul 1999 14:25:18 +0400 (MSD) (envelope-from antuan) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Mon, 12 Jul 1999 14:25:17 +0400 (MSD) From: Antuan Avdioukhine To: security@FreeBSD.ORG Subject: limit processes by userid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Gentlemen, I want strange thing: to limit number of some processes by userid in the similar to sessionlimit capability in login.conf. Which way can I go? ------ Antuan Avdioukhine St.-Petersburg, Russia 12-Jul-99 14:20:39 ------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 4:53:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from granite.sentex.net (granite.sentex.ca [199.212.134.1]) by hub.freebsd.org (Postfix) with ESMTP id 8560314E2C; Mon, 12 Jul 1999 04:53:17 -0700 (PDT) (envelope-from mike@sentex.net) Received: from gravel (ospf-wat.sentex.net [209.167.248.81]) by granite.sentex.net (8.8.8/8.6.9) with SMTP id HAA22149; Mon, 12 Jul 1999 07:53:16 -0400 (EDT) Message-Id: <4.1.19990712080116.053e4430@granite.sentex.ca> X-Sender: mdtancsa@granite.sentex.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 12 Jul 1999 08:05:03 -0400 To: security@freebsd.org From: Mike Tancsa Subject: 3.x backdoor rootshell security hole Cc: stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Has anyone looked at the articled below ? Here is a quote, "The following module was a nice idea I had when playing around with the proc structure. Load this module, and you can 'SU' without a password. The idea is very simple. The module implements a system call that gets one argument : a PID. This can be the PID of any process, but will normally be the PID of your user account shell (tcsh, sh, bash or whatever). This process will then become root (UID 0) by manipulating its cred structure. Here we go : " >X-To: BUGTRAQ@securityfocus.com >To: BUGTRAQ@SECURITYFOCUS.COM >X-UIDL: 88369f61515db2b291adff1fa2ad57e7 > >Hi folks, > >THC released a new article dealing with FreeBSD 3.x >Kernel modules that can attack/backdoor the >system. >You can find our article on http://thc.pimmel.com or >http://r3wt.base.org. > >Greets, pragmatic / The Hacker's Choice ********************************************************************** Mike Tancsa, Network Admin * mike@sentex.net Sentex Communications Corp, * http://www.sentex.net/mike Cambridge, Ontario * 01.519.651.3400 Canada * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 5: 3:46 1999 Delivered-To: freebsd-security@freebsd.org Received: from atdot.dotat.org (atdot.dotat.org [150.101.89.3]) by hub.freebsd.org (Postfix) with ESMTP id 99E9A14E2C; Mon, 12 Jul 1999 05:03:21 -0700 (PDT) (envelope-from newton@atdot.dotat.org) Received: (from newton@localhost) by atdot.dotat.org (8.9.3/8.7) id VAA05155; Mon, 12 Jul 1999 21:26:21 +0930 (CST) From: Mark Newton Message-Id: <199907121156.VAA05155@atdot.dotat.org> Subject: Re: 3.x backdoor rootshell security hole To: mike@sentex.net (Mike Tancsa) Date: Mon, 12 Jul 1999 21:26:21 +0930 (CST) Cc: security@FreeBSD.ORG, stable@FreeBSD.ORG In-Reply-To: <4.1.19990712080116.053e4430@granite.sentex.ca> from "Mike Tancsa" at Jul 12, 99 08:05:03 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Tancsa wrote: > Has anyone looked at the articled below ? Here is a quote, > "The following module was a nice idea I had when playing around with the > proc structure. Load this module, and you can 'SU' without a password. If you have enough privileges to load a module, you have enough privileges to su without a password already (by creating an suid shell, for example) - mark -------------------------------------------------------------------- I tried an internal modem, newton@atdot.dotat.org but it hurt when I walked. Mark Newton ----- Voice: +61-4-1620-2223 ------------- Fax: +61-8-82231777 ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 6:12:10 1999 Delivered-To: freebsd-security@freebsd.org Received: from thelab.hub.org (nat206.255.mpoweredpc.net [142.177.206.255]) by hub.freebsd.org (Postfix) with ESMTP id 94C1E14D26 for ; Mon, 12 Jul 1999 06:12:00 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id IAA11025 for ; Mon, 12 Jul 1999 08:56:07 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Mon, 12 Jul 1999 08:56:06 -0300 (ADT) From: The Hermit Hacker To: freebsd-security@freebsd.org Subject: THC Article ... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In case nobody else has seen this: http://thc.pimmel.com Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 6:55:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id EACAA14C30 for ; Mon, 12 Jul 1999 06:55:16 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id PAA19300; Mon, 12 Jul 1999 15:54:05 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Peter Wemm Cc: Darren Reed , des@flood.ping.uio.no (Dag-Erling Smorgrav), security@FreeBSD.org Subject: Re: Module magic In-reply-to: Your message of "Mon, 12 Jul 1999 16:58:57 +0800." <19990712085857.2B14C8A@overcee.netplex.com.au> Date: Mon, 12 Jul 1999 15:54:05 +0200 Message-ID: <19298.931787645@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <19990712085857.2B14C8A@overcee.netplex.com.au>, Peter Wemm writes: >Darren Reed wrote: >> In some mail from Dag-Erling Smorgrav, sie said: >> > >> > Thought this'd be of interest to this list: >> > >> > http://thc.pimmel.com/files/thc/bsdkern.html >> >> So what ? >> >> Nothing in that document is "new" although it might be the >> first time it's been documented for script-kiddies. > >Yeah, the main worrying thing about it is the hard coding of internal data >structures and bypassing of proper interfaces. I'm half thinking about >doing a couple of arbitary rearrangements of some internal (opaque) data >structures to make their life a bit more exciting. I'd rather a box panic >and burn if a script kiddie gets in and tries to use some of these >``techniques'' than have it run whatever they like undetected. This will >be totally harmless to the existing modules since the data structures are >not used outside kern_*.c. Hmm, here's a thought: We have many structures where the order of elements isn't that important, so somebody write a perl script which looks for some magic marking (or reads a config file) for which fields are legal game, and rearranges them in /sys/sys before each recompile of the kernel .1 * :-) -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 7:10: 5 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 8A8C814C30; Mon, 12 Jul 1999 07:10:00 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id KAA09930; Mon, 12 Jul 1999 10:09:30 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Mon, 12 Jul 1999 10:09:30 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Mark Newton Cc: Mike Tancsa , security@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: 3.x backdoor rootshell security hole In-Reply-To: <199907121156.VAA05155@atdot.dotat.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 12 Jul 1999, Mark Newton wrote: > Mike Tancsa wrote: > > > Has anyone looked at the articled below ? Here is a quote, > > "The following module was a nice idea I had when playing around with the > > proc structure. Load this module, and you can 'SU' without a password. > > If you have enough privileges to load a module, you have enough > privileges to su without a password already (by creating an suid > shell, for example) In fact, if you have permission to modify the running kernel, you may have more privilege than that of a root process, with securelevels.. :-) What the THC posting is really about it hiding compromises on a machine that has been compromised, and leaving backdoors. The title, "Attacking FreeBSD..." is a little misleading, it's more about "Trojaning FreeBSD Once You Already Have Absolute Control of a Machine". And these aren't even very persistent: they have to be reloaded after each boot, meaning changes to configuration files, etc, etc. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 7:57:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 7F34114C56; Mon, 12 Jul 1999 07:57:27 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id XAA24995; Mon, 12 Jul 1999 23:57:05 +0900 (JST) Message-ID: <378A015B.2CBE0569@newsguy.com> Date: Mon, 12 Jul 1999 23:53:15 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Mike Tancsa Cc: security@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: 3.x backdoor rootshell security hole References: <4.1.19990712080116.053e4430@granite.sentex.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Tancsa wrote: > > Has anyone looked at the articled below ? Here is a quote, > > "The following module was a nice idea I had when playing around with the > proc structure. Load this module, and you can 'SU' without a password. The > idea is very simple. The module implements a system call that gets one > argument : a PID. This can be the PID of any process, but will normally be > the PID of your user account shell (tcsh, sh, bash or whatever). This > process will then become root (UID 0) by manipulating its cred structure. > Here we go : " All of the article assumes you have got into root first. Once you get root, you can do anything. The article just shows how. Or, more to the point, the article doesn't show *any* exploit. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org I'm one of those bad things that happen to good people. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 10:28:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from spork.cs.unm.edu (spork.cs.unm.edu [198.59.151.21]) by hub.freebsd.org (Postfix) with ESMTP id 6875314CB4 for ; Mon, 12 Jul 1999 10:28:20 -0700 (PDT) (envelope-from colinj@cs.unm.edu) Received: from waimea.cs.unm.edu ([198.59.151.18]) by spork.cs.unm.edu with esmtp (Exim 2.12 #3) id 113jrn-0005M4-00 for freebsd-security@freebsd.org; Mon, 12 Jul 1999 11:27:47 -0600 Received: from localhost (colinj@localhost) by waimea.cs.unm.edu (980427.SGI.8.8.8/8.8.8) with ESMTP id LAA71842 for ; Mon, 12 Jul 1999 11:25:10 -0600 (MDT) (envelope-from colinj@waimea.cs.unm.edu) Date: Mon, 12 Jul 1999 11:25:10 -0600 From: Colin Eric Johnson To: freebsd-security@freebsd.org Subject: security levels Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org OK, this is a ``please clue me in question.'' I've seen mention of security levels in several manpages and I know that the behavior of the chflags command changes based on security levels, or at least seems to. What I am not sure is what to change and where to effect a change in security levels. Can someone please clue me in or point me at the right bit of documentation to clue me in? thanks Colin E. Johnson | colinj@unm.edu | http://www.unm.edu/~colinj/ In thousands of sparkling lights and electro-syntho-magnetic musical sounds To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 10:37: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 1382514DC3 for ; Mon, 12 Jul 1999 10:36:52 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id NAA01917; Mon, 12 Jul 1999 13:36:37 -0400 (EDT) (envelope-from wollman) Date: Mon, 12 Jul 1999 13:36:37 -0400 (EDT) From: Garrett Wollman Message-Id: <199907121736.NAA01917@khavrinen.lcs.mit.edu> To: Darren Reed Cc: robert+freebsd@cyrus.watson.org, security@FreeBSD.ORG Subject: Re: Module magic In-Reply-To: <199907120945.TAA09669@cheops.anu.edu.au> References: <199907120945.TAA09669@cheops.anu.edu.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > FWIW, I believe NetBSD systems (and OpenBSD systems) ship configured to > boot with securelevel == 0, as opposed to FreeBSD which appears to default > to -1. We think our users are more concerned about X working. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 11:12:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id 89B0D152A0 for ; Mon, 12 Jul 1999 11:12:16 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id OAA31150; Mon, 12 Jul 1999 14:11:58 -0400 (EDT) Date: Mon, 12 Jul 1999 14:11:58 -0400 (EDT) From: Bosko Milekic To: Colin Eric Johnson Cc: freebsd-security@FreeBSD.ORG Subject: Re: security levels In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you're asking regarding the securelevel which the kernel runs with, try looking at sysctl kern.securelevel, and /etc/rc.conf, try also man sysctl, as well as man rc.conf //Bosko Bosko Milekic Delphi SuperNet bmilekic@dsuper.net http://www.dsuper.net/ PGP key available upon request. tel.: [+1].514.281.7500 http://www.dsuper.net/~bmilekic/ fax.: [+1].514.281.6599 On Mon, 12 Jul 1999, Colin Eric Johnson wrote: > > OK, this is a ``please clue me in question.'' I've seen mention of > security levels in several manpages and I know that the behavior of the > chflags command changes based on security levels, or at least seems to. > What I am not sure is what to change and where to effect a change in > security levels. Can someone please clue me in or point me at the right > bit of documentation to clue me in? > > thanks > > Colin E. Johnson | colinj@unm.edu | http://www.unm.edu/~colinj/ > In thousands of sparkling lights and electro-syntho-magnetic musical sounds > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 12: 7:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from yoshi.iq.org (yoshi.iq.org [203.4.184.224]) by hub.freebsd.org (Postfix) with ESMTP id F0258151F2 for ; Mon, 12 Jul 1999 12:07:24 -0700 (PDT) (envelope-from proff@yoshi.iq.org) Received: (from proff@localhost) by yoshi.iq.org (8.8.8/8.8.8) id UAA00264; Fri, 9 Jul 1999 20:06:04 +1000 (EST) To: Robert Watson Cc: Darren Reed , Alla Bezroutchko , security@FreeBSD.ORG Subject: Re: Syslog alternatives? References: Cc: proff@iq.org From: Julian Assange Date: 09 Jul 1999 20:06:04 +1000 In-Reply-To: Robert Watson's message of "Fri, 9 Jul 1999 04:20:13 -0400 (EDT)" Message-ID: Lines: 12 User-Agent: Gnus/5.070066 (Pterodactyl Gnus v0.66) XEmacs/21.1 (20 Minutes to Nikko) Mime-Version: 1.0 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Watson writes: > don't have a reference for it. I believe Schneier coauthored a paper on > some of the cryptographic issues, also. Again, no references here as I'm > out of town. If you can rely on kernel integrity due to securelevels, > then presumably you can have it hold onto secrets and provide certain > cryptographic integrity services. I don't like Schneier's paper very much. Seems to be an over-engineered patent stalking horse. Darren's nsyslog does cryptographic verification and transmission of its log data -- and keeps the log-files human readable. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 12:36:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 715A31514D; Mon, 12 Jul 1999 12:35:45 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id UAA01594; Mon, 12 Jul 1999 20:33:43 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 12 Jul 1999 20:33:43 +0100 (BST) From: Doug Rabson To: Robert Watson Cc: Mark Newton , Mike Tancsa , security@freebsd.org, stable@freebsd.org Subject: Re: 3.x backdoor rootshell security hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 12 Jul 1999, Robert Watson wrote: > On Mon, 12 Jul 1999, Mark Newton wrote: > > > Mike Tancsa wrote: > > > > > Has anyone looked at the articled below ? Here is a quote, > > > "The following module was a nice idea I had when playing around with the > > > proc structure. Load this module, and you can 'SU' without a password. > > > > If you have enough privileges to load a module, you have enough > > privileges to su without a password already (by creating an suid > > shell, for example) > > In fact, if you have permission to modify the running kernel, you may have > more privilege than that of a root process, with securelevels.. :-) What > the THC posting is really about it hiding compromises on a machine that > has been compromised, and leaving backdoors. The title, "Attacking > FreeBSD..." is a little misleading, it's more about "Trojaning FreeBSD > Once You Already Have Absolute Control of a Machine". And these aren't > even very persistent: they have to be reloaded after each boot, meaning > changes to configuration files, etc, etc. Also if a site is running using securelevel, even root can't load files into the running kernel. The attacker would have to arrange to load the code during startup and reboot the box (a noticable event surely). Hmm. Shouldn't we protect the contents of /boot with the schg flag? -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 14: 7:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 0D0B014D30; Mon, 12 Jul 1999 14:07:17 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id OAA06665; Mon, 12 Jul 1999 14:07:01 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id OAA22780; Mon, 12 Jul 1999 14:06:53 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA27134; Mon, 12 Jul 99 14:06:51 PDT Message-Id: <378A58EA.ACF1412F@softweyr.com> Date: Mon, 12 Jul 1999 15:06:50 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Eivind Eklund Cc: cjclark@home.com, FreeBSD Security Subject: Re: Secure Deletion References: <199906250212.WAA07810@cc942873-a.ewndsr1.nj.home.com> <3773F67A.CC9B6215@softweyr.com> <19990629131529.A61249@bitbox.follo.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Eivind Eklund wrote: > > On Fri, Jun 25, 1999 at 03:36:58PM -0600, Wes Peters wrote: > > This won't do it, if you're really interested in obliterating the file > > contents. What you want to do is overwrite the file blocks with > ^^^^ > disk > > > alternating patterns of 10101010 then 01010101 at least 100 times. > > Due to the way modern recording formats work, and the memory of the > > cells that actually store the bits on the disk, anything less won't > > really erase the disk. > > More or less correct. There are a lot of details to this, and just > writing 0x55/0xaa as normal data values won't make them hit the disk > that way. > > Since what I have to write about this topic would just end up being a > paraphrase of what Peter Gutmann has to say, I suggest you read the > paper he presented at Usenix 1996: > http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html > > Eivind. I've read Peter's paper, which I found to be very informative. I've incorporated his table of successive values into my program, along with a couple of bug fixes. (I wasn't unmapping the file before closing and unlinking it, and I was mapping it MAP_PRIVATE so it wasn't really over- writing the file anyhow. Doh!) Here's the source for the new, improved version if anyone wants to test it themselves. Unless anyone has strenuous objections, I'll make this into a port and commit it (as soon as I learn how to make a port). /* * Obliterate - a simple program to obliterate file contents. * * Copyright (c) 1999 Softweyr LLC, South Jordan, Utah USA. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY Softweyr LLC ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL Softweyr LLC OR ANY CONTRIBUTORS BE LIABLE FOR ANY * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGE. * * Author: Wes Peters * Date: Mon Jul 12 15:04:51 MDT 1999 */ #include #include #include #include #include #define MIN(a,b) ((a < b) ? a : b) /* * The bit patterns used to overwrite the disk blocks. These patterns are * designed to provide a complete overwrite on all common disk recording * formats. * * Pattern devised by Peter Gutmann, Department of Computer Science, * University of Auckland . See Peter's paper * "Secure Deletion of Data from Magnetic and Solid-State Memory" at * http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html for more * information about how and why this pattern works. */ unsigned char *patterns[] = { "R", /* random */ "R", /* random */ "R", /* random */ "R", /* random */ "\x55", /* 1,7 RLL MFM */ "\xaa", /* 1,7 RLL MFM */ "\x92\x49\x24", /* 2,7 RLL MFM */ "\x49\x24\x92", /* 2,7 RLL MFM */ "\x24\x92\x49", /* 2,7 RLL MFM */ "\x00", /* 1,7 RLL 2,7 RLL */ "\x11", /* 1,7 RLL */ "\x22", /* 1,7 RLL */ "\x33", /* 1,7 RLL 2,7 RLL */ "\x44", /* 1,7 RLL */ "\x55", /* 1,7 RLL MFM */ "\x66", /* 1,7 RLL 2,7 RLL */ "\x77", /* 1,7 RLL */ "\x88", /* 1,7 RLL */ "\x99", /* 1,7 RLL 2,7 RLL */ "\xaa", /* 1,7 RLL MFM */ "\xbb", /* 1,7 RLL */ "\xcc", /* 1,7 RLL 2,7 RLL */ "\xdd", /* 1,7 RLL */ "\xee", /* 1,7 RLL */ "\xff", /* 1,7 RLL 2,7 RLL */ "\x92\x49\x24", /* 2,7 RLL MFM */ "\x49\x24\x92", /* 2,7 RLL MFM */ "\x24\x92\x49", /* 2,7 RLL MFM */ "\x6d\xb6\xdb", /* 2,7 RLL */ "\xb6\xdb\x6d", /* 2,7 RLL */ "\xdb\x6d\xb6", /* 2,7 RLL */ "R", /* random */ "R", /* random */ "R", /* random */ "R", /* random */ }; static int npatterns = sizeof (patterns) / sizeof (patterns[0]); /* * A file handle to access the system pool of randomness. */ int randfd = 0; /* * Fill a block of memory with a specified pattern, repeating the pattern as * necessary to completely fill the block. This routine is smart about * "special" patterns such as an apparent NULL pattern (this means zero-fill * the block) and "R" which means fill the block with random values. */ int fill(void *data, off_t size, char *pattern) { /* * If the first byte is zero, it means zero-fill the block. */ if (*pattern == '\0') { (void) memset(data, 0, size); } /* * If the first byte is 'R' it means random fill the block. We use the * system pool of randomness here because it is an easy to use source of * pretty much random data. Reading blocks of any appreciable size from * the pool probably degrades it into a cascade of MD5 signatures, but * should be sufficient for our needs here. */ else if (*pattern == 'R') { read(randfd, data, size); } else { /* * Be smart about using library functions where available. */ int l = strlen(pattern); if (l == 1) { memset(data, *pattern, size); } else { char *p, *e = data + size; for (p = data; p < e; p += l) { memcpy(p, pattern, MIN(l, e - p)); } } } } /* * Overwrite the named file. Return 0 on success, -1 otherwise. */ int obliterate(char *fname) { struct stat S; int fd; void *data; int iteration; if (stat(fname, &S) == -1) { perror(fname); return -1; } if (!S_ISREG(S.st_mode)) { fprintf(stderr, "%s: not a regular file\n", fname); return -1; } fd = open(fname, O_RDWR); if (fd == -1) { perror(fname); return -1; } data = mmap(NULL, S.st_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (data == MAP_FAILED) { perror(fname); close(fd); return -1; } /* * Overwrite the file with successive patterns as specified above. */ for (iteration = 0; iteration < npatterns; iteration++) { fill(data, S.st_size, patterns[iteration]); if (fsync(fd) == -1) { perror(fname); close(fd); return -1; } } /* * Get rid of the file (from the filesystem point of view). */ if (munmap(data, S.st_size) == -1) { perror(fname); close(fd); return -1; } close(fd); if (unlink(fname) == -1) { perror(fname); return -1; } return 0; } /* * Obliterate each file named on the command line. */ int main(int argc, char *argv[]) { int result = 0; /* * Open the system entropy pool for random data. */ if ((randfd = open("/dev/urandom", O_RDONLY)) == -1) { perror("Opening system pool of randomness (/dev/urandom)"); return -1; } while (--argc) { result |= obliterate(*++argv); } close(randfd); return result; } /* EOF */ -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 16:12:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id A179914DDE for ; Mon, 12 Jul 1999 16:12:10 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id BAA61524; Tue, 13 Jul 1999 01:11:40 +0200 (CEST) (envelope-from des) To: Bosko Milekic Cc: Colin Eric Johnson , freebsd-security@FreeBSD.ORG Subject: Re: security levels References: From: Dag-Erling Smorgrav Date: 13 Jul 1999 01:11:39 +0200 In-Reply-To: Bosko Milekic's message of "Mon, 12 Jul 1999 14:11:58 -0400 (EDT)" Message-ID: Lines: 14 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bosko Milekic writes: > On Mon, 12 Jul 1999, Colin Eric Johnson wrote: > > What I am not sure is what to change and where to effect a change in > > security levels. Can someone please clue me in or point me at the right > > bit of documentation to clue me in? > If you're asking regarding the securelevel which the kernel runs with, try > looking at sysctl kern.securelevel, and /etc/rc.conf, try also man sysctl, > as well as man rc.conf The correct answer, of course, is man 8 init. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 16:20: 8 1999 Delivered-To: freebsd-security@freebsd.org Received: from boispop1.bois.uswest.net (boispop1.bois.uswest.net [207.108.224.1]) by hub.freebsd.org (Postfix) with SMTP id 6A45D14E91 for ; Mon, 12 Jul 1999 16:20:04 -0700 (PDT) (envelope-from kvgu@uswest.net) Received: (qmail 22304 invoked by alias); 12 Jul 1999 23:20:03 -0000 Delivered-To: fixup-freebsd-security@freebsd.org@fixme Received: (qmail 22297 invoked by uid 0); 12 Jul 1999 23:20:03 -0000 Received: from lhotse.jgalive.com (HELO lhotse) (207.225.37.154) by boispop1.bois.uswest.net with SMTP; 12 Jul 1999 23:20:03 -0000 Message-Id: <3.0.6.32.19990712172743.00858c40@pop.bois.uswest.net> X-Sender: kvgu@pop.bois.uswest.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 12 Jul 1999 17:27:43 -0600 To: freebsd-security@freebsd.org From: Ken Subject: Web Server Configuration Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello: I'd like to learn more about properly configuring Apache with FreeBSD. I've checked out CERT's module which recommends running the web server chrooted, but this stuff is so dated I am wondering if it is still a best policy? Any resources you could point me to would be appreciated. Thanks-- kg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 16:20:30 1999 Delivered-To: freebsd-security@freebsd.org Received: from WEBBSD1.turnaround.com.au (webbsd1.turnaround.com.au [203.39.138.49]) by hub.freebsd.org (Postfix) with ESMTP id 8D99214F0E for ; Mon, 12 Jul 1999 16:20:21 -0700 (PDT) (envelope-from A_Johns@TurnAround.com.au) Received: from tasajohns (dhcp64.turnaround.com.au [192.168.1.64]) by WEBBSD1.turnaround.com.au (8.8.7/8.8.7) with SMTP id JAA03087; Tue, 13 Jul 1999 09:38:57 +1000 (EST) (envelope-from A_Johns@TurnAround.com.au) From: "Andrew Johns" To: "Colin Eric Johnson" , Subject: RE: security levels Date: Tue, 13 Jul 1999 09:18:37 +1000 Message-ID: <000801beccbc$de92e780$4001a8c0@tasajohns.turnaround.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You may also find http://www.freebsd.org/~jkb/howto.html quite useful. It has a small section devoted to kernel securelevels and their various options. > -----Original Message----- > From: owner-freebsd-security@FreeBSD.ORG > [mailto:owner-freebsd-security@FreeBSD.ORG]On Behalf Of Colin Eric > Johnson > Sent: Tuesday, 13 July 1999 3:25 > To: freebsd-security@FreeBSD.ORG > Subject: security levels > > > > OK, this is a ``please clue me in question.'' I've seen mention of > security levels in several manpages and I know that the > behavior of the > chflags command changes based on security levels, or at least > seems to. > What I am not sure is what to change and where to effect a change in > security levels. Can someone please clue me in or point me at > the right > bit of documentation to clue me in? > > thanks > > Colin E. Johnson | colinj@unm.edu | http://www.unm.edu/~colinj/ > In thousands of sparkling lights and electro-syntho-magnetic > musical sounds > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 16:44: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from zip.com.au (zipper.zip.com.au [203.12.97.1]) by hub.freebsd.org (Postfix) with ESMTP id A53FC1509A for ; Mon, 12 Jul 1999 16:44:01 -0700 (PDT) (envelope-from ncb@zip.com.au) Received: from localhost (ncb@localhost) by zip.com.au (8.9.1/8.9.1) with ESMTP id JAA05538; Tue, 13 Jul 1999 09:43:53 +1000 Date: Tue, 13 Jul 1999 09:43:52 +1000 (EST) From: Nicholas Brawn To: Mike Tancsa Cc: security@FreeBSD.ORG Subject: Re: 3.x backdoor rootshell security hole In-Reply-To: <4.1.19990712080116.053e4430@granite.sentex.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 12 Jul 1999, Mike Tancsa wrote: > Has anyone looked at the articled below ? Here is a quote, > > "The following module was a nice idea I had when playing around with the > proc structure. Load this module, and you can 'SU' without a password. The > idea is very simple. The module implements a system call that gets one > argument : a PID. This can be the PID of any process, but will normally be > the PID of your user account shell (tcsh, sh, bash or whatever). This > process will then become root (UID 0) by manipulating its cred structure. > Here we go : " If an unauthorised individual can get far enough to load rogue modules, then you have far more important security issues to address first. Nick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 12 22:52:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from host07.rwsystems.net (kasie.rwsystems.net [209.197.192.103]) by hub.freebsd.org (Postfix) with ESMTP id AF6E014CA1 for ; Mon, 12 Jul 1999 22:52:28 -0700 (PDT) (envelope-from jwyatt@RWSystems.net) Received: from kasie.rwsystems.net([209.197.192.103]) (1074 bytes) by host07.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Tue, 13 Jul 1999 00:26:21 -0500 (CDT) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-24) Date: Tue, 13 Jul 1999 00:26:20 -0500 (CDT) From: James Wyatt To: Ken Cc: freebsd-security@freebsd.org Subject: Re: Web Server Configuration In-Reply-To: <3.0.6.32.19990712172743.00858c40@pop.bois.uswest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 12 Jul 1999, Ken wrote: > I'd like to learn more about properly configuring Apache with FreeBSD. > I've checked out CERT's module which recommends running the web server > chrooted, but this stuff is so dated I am wondering if it is still a best > policy? Any resources you could point me to would be appreciated. Wow, that *is* old; was the version in roman numerals? 8{) Take a look at the ports collection, there are several variations on Apache - w/ and w/o SSL, PHP, FP, etc... - Jy@ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 1: 7:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 501EB1526C; Tue, 13 Jul 1999 01:07:27 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id EAA14410; Tue, 13 Jul 1999 04:06:42 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Tue, 13 Jul 1999 04:06:41 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Doug Rabson Cc: Mark Newton , Mike Tancsa , security@freebsd.org, stable@freebsd.org Subject: Re: 3.x backdoor rootshell security hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 12 Jul 1999, Doug Rabson wrote: > On Mon, 12 Jul 1999, Robert Watson wrote: > ... > > In fact, if you have permission to modify the running kernel, you may have > > more privilege than that of a root process, with securelevels.. :-) What > > the THC posting is really about it hiding compromises on a machine that > > has been compromised, and leaving backdoors. The title, "Attacking > > FreeBSD..." is a little misleading, it's more about "Trojaning FreeBSD > > Once You Already Have Absolute Control of a Machine". And these aren't > > even very persistent: they have to be reloaded after each boot, meaning > > changes to configuration files, etc, etc. > > Also if a site is running using securelevel, even root can't load files > into the running kernel. The attacker would have to arrange to load the > code during startup and reboot the box (a noticable event surely). > > Hmm. Shouldn't we protect the contents of /boot with the schg flag? Ideally some of the directories themselves, as well as /boot, parts of /etc large parts of /sbin and /bin (including sh, as that gets run in single-user mode)... My feeling is we should maintain a list, but not ship that way as it would be irritating for most of the world. At one point I had a script that did some of the work, but currently due to file layout and the way we do config files, you end up with a fairly hobbled machine. Which is, of course, the idea. :-) I think security(8) (?) discusses a fair amount of this stuff. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 2:36:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from alice.gba.oz.au (gba-254.tmx.com.au [203.9.155.254]) by hub.freebsd.org (Postfix) with SMTP id 8381414E8D for ; Tue, 13 Jul 1999 02:35:57 -0700 (PDT) (envelope-from gjb-freebsd@gba.oz.au) Received: (qmail 2898 invoked by uid 1001); 13 Jul 1999 11:05:31 +1000 Message-ID: <19990713010531.2897.qmail@alice.gba.oz.au> X-Posted-By: GBA-Post 1.03 20-Sep-1998 X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 Date: Tue, 13 Jul 1999 11:05:31 +1000 From: Greg Black To: Garrett Wollman Cc: Darren Reed , robert+freebsd@cyrus.watson.org, security@FreeBSD.ORG Subject: Re: Module magic References: <199907120945.TAA09669@cheops.anu.edu.au> <199907121736.NAA01917@khavrinen.lcs.mit.edu> In-reply-to: <199907121736.NAA01917@khavrinen.lcs.mit.edu> of Mon, 12 Jul 1999 13:36:37 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman writes: > > FWIW, I believe NetBSD systems (and OpenBSD systems) ship configured to > > boot with securelevel == 0, as opposed to FreeBSD which appears to default > > to -1. > > We think our users are more concerned about X working. Are you saying that X does not work when securelevel >= 0 under FreeBSD? -- Greg Black -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 3:35:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 7945814D70 for ; Tue, 13 Jul 1999 03:35:23 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id GAA14745; Tue, 13 Jul 1999 06:34:49 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Tue, 13 Jul 1999 06:34:49 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Greg Black Cc: Garrett Wollman , Darren Reed , security@FreeBSD.ORG Subject: Re: Module magic In-Reply-To: <19990713010531.2897.qmail@alice.gba.oz.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 13 Jul 1999, Greg Black wrote: > Garrett Wollman writes: > > > > FWIW, I believe NetBSD systems (and OpenBSD systems) ship configured to > > > boot with securelevel == 0, as opposed to FreeBSD which appears to default > > > to -1. > > > > We think our users are more concerned about X working. > > Are you saying that X does not work when securelevel >= 0 under > FreeBSD? If I recall, the XiG Accelerated X product requires direct access to memory. vm_mmap.c: /* * cdevs does not provide private mappings of any kind. */ /* * However, for XIG X server to continue to work, * we should allow the superuser to do it anyway. * We only allow it at securelevel < 1. * (Because the XIG X server writes directly to video * memory via /dev/mem, it should never work at any * other securelevel. * XXX this will have to go */ Their code should probably not do this, as direct memory access violates kernel safety. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 5:15:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from alice.gba.oz.au (gba-254.tmx.com.au [203.9.155.254]) by hub.freebsd.org (Postfix) with SMTP id 2DB8914D5A for ; Tue, 13 Jul 1999 05:15:22 -0700 (PDT) (envelope-from gjb-freebsd@gba.oz.au) Received: (qmail 5558 invoked by uid 1001); 13 Jul 1999 22:14:53 +1000 Message-ID: <19990713121453.5557.qmail@alice.gba.oz.au> X-Posted-By: GBA-Post 1.03 20-Sep-1998 X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 Date: Tue, 13 Jul 1999 22:14:52 +1000 From: Greg Black To: Wes Peters Cc: FreeBSD Security Subject: Re: Secure Deletion References: <199906250212.WAA07810@cc942873-a.ewndsr1.nj.home.com> <3773F67A.CC9B6215@softweyr.com> <19990629131529.A61249@bitbox.follo.net> <378A58EA.ACF1412F@softweyr.com> In-reply-to: <378A58EA.ACF1412F@softweyr.com> of Mon, 12 Jul 1999 15:06:50 CST Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wes Peters writes: > Here's the source for the new, improved > version if anyone wants to test it themselves. > > Unless anyone has strenuous objections, I'll make this into a port and > commit it (as soon as I learn how to make a port). There are two things that would be good to change: Throughout, -1 is used as an error return value and that is eventually used as the program's exit value if any error occurs. Those -1 values should be changed to +1, at least for the final exit value. This is required for many reasons which I won't rehash here. If the open() fails, it might be due to read-only permissions. It would be good to attempt a chmod() to make it writeable and retry the open() before bailing out, perhaps controlled by a -f flag as used by programs like rm(1). It's possible to check the reason for the open() failure and to look at the mode of the file to verify its permissions before attempting the chmod(), although that seems superfluous here. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 9:35:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 9E82114C1E for ; Tue, 13 Jul 1999 09:35:27 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id MAA05152; Tue, 13 Jul 1999 12:31:30 -0400 (EDT) (envelope-from wollman) Date: Tue, 13 Jul 1999 12:31:30 -0400 (EDT) From: Garrett Wollman Message-Id: <199907131631.MAA05152@khavrinen.lcs.mit.edu> To: Greg Black Cc: security@FreeBSD.ORG Subject: Re: Module magic In-Reply-To: <19990713010531.2897.qmail@alice.gba.oz.au> References: <199907120945.TAA09669@cheops.anu.edu.au> <199907121736.NAA01917@khavrinen.lcs.mit.edu> <19990713010531.2897.qmail@alice.gba.oz.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Are you saying that X does not work when securelevel >= 0 under > FreeBSD? That is correct. X requires direct access to I/O space, which is fundamentally incompatible with the notion of enhanced security. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 10:23:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 59A3115176; Tue, 13 Jul 1999 10:23:46 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA79286; Tue, 13 Jul 1999 10:23:04 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 10:23:04 -0700 (PDT) From: Matthew Dillon Message-Id: <199907131723.KAA79286@apollo.backplane.com> To: Robert Watson Cc: Doug Rabson , Mark Newton , Mike Tancsa , security@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: 3.x backdoor rootshell security hole References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> :> Hmm. Shouldn't we protect the contents of /boot with the schg flag? : :Ideally some of the directories themselves, as well as /boot, parts of :/etc large parts of /sbin and /bin (including sh, as that gets run in :single-user mode)... My feeling is we should maintain a list, but not :ship that way as it would be irritating for most of the world. At one :point I had a script that did some of the work, but currently due to file :layout and the way we do config files, you end up with a fairly hobbled :machine. Which is, of course, the idea. :-) I think security(8) (?) :discusses a fair amount of this stuff. : : Robert N M Watson : :robert@fledge.watson.org http://www.watson.org/~robert/ Anyone serious enough and paranoid enough simply mounts / and /usr read-only, then bumps the security level up. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 11: 0:45 1999 Delivered-To: freebsd-security@freebsd.org Received: from beatrice.rutgers.edu (beatrice.rutgers.edu [165.230.209.226]) by hub.freebsd.org (Postfix) with SMTP id DAB3E14EB7 for ; Tue, 13 Jul 1999 11:00:41 -0700 (PDT) (envelope-from easmith@beatrice.rutgers.edu) Received: (from easmith@localhost) by beatrice.rutgers.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA08205; Tue, 13 Jul 1999 13:55:00 -0400 From: "Allen Smith" Message-Id: <9907131354.ZM8203@beatrice.rutgers.edu> Date: Tue, 13 Jul 1999 13:54:59 -0400 In-Reply-To: Greg Black "Re: Secure Deletion" (Jul 13, 8:13am) References: <199906250212.WAA07810@cc942873-a.ewndsr1.nj.home.com> <3773F67A.CC9B6215@softweyr.com> <19990629131529.A61249@bitbox.follo.net> <378A58EA.ACF1412F@softweyr.com> <19990713121453.5557.qmail@alice.gba.oz.au> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Wes Peters Subject: Re: Secure Deletion Cc: FreeBSD Security Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jul 13, 8:13am, Greg Black (possibly) wrote: > Wes Peters writes: > > > Here's the source for the new, improved > > version if anyone wants to test it themselves. > > > > Unless anyone has strenuous objections, I'll make this into a port and > > commit it (as soon as I learn how to make a port). One other thing... the paper isn't quite clear about the randomization of order of the deterministic passes. Should the program be doing the deterministic passes in a random order, with the random ones before and after? Or is that just talking about that you do the multiple-byte deterministic passes in each of the possible orders (which probably should be randomized with respect to each other)? -Allen -- Allen Smith easmith@beatrice.rutgers.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 11:10:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id D05B714BF2 for ; Tue, 13 Jul 1999 11:10:20 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id UAA25697; Tue, 13 Jul 1999 20:08:51 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "Allen Smith" Cc: Wes Peters , FreeBSD Security Subject: Re: Secure Deletion In-reply-to: Your message of "Tue, 13 Jul 1999 13:54:59 EDT." <9907131354.ZM8203@beatrice.rutgers.edu> Date: Tue, 13 Jul 1999 20:08:51 +0200 Message-ID: <25695.931889331@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Just in case anybody wants to do this "RIGHT": UFS/FFS will issue B_FREEBUF strategy calls, which a device driver could turn into "secure delete" operations should the drive support this, or multiple over-writes if it doesn't. In message <9907131354.ZM8203@beatrice.rutgers.edu>, "Allen Smith" writes: >On Jul 13, 8:13am, Greg Black (possibly) wrote: >> Wes Peters writes: >> >> > Here's the source for the new, improved >> > version if anyone wants to test it themselves. >> > >> > Unless anyone has strenuous objections, I'll make this into a port and >> > commit it (as soon as I learn how to make a port). > >One other thing... the paper isn't quite clear about the randomization >of order of the deterministic passes. Should the program be doing the >deterministic passes in a random order, with the random ones before >and after? Or is that just talking about that you do the multiple-byte >deterministic passes in each of the possible orders (which probably >should be randomized with respect to each other)? > > -Allen > >-- >Allen Smith easmith@beatrice.rutgers.edu > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 11:15:40 1999 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 998EC150DA for ; Tue, 13 Jul 1999 11:15:38 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA79582; Tue, 13 Jul 1999 11:15:23 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 11:15:23 -0700 (PDT) From: Matthew Dillon Message-Id: <199907131815.LAA79582@apollo.backplane.com> To: Poul-Henning Kamp Cc: "Allen Smith" , Wes Peters , FreeBSD Security Subject: Re: Secure Deletion References: <25695.931889331@critter.freebsd.dk> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :Just in case anybody wants to do this "RIGHT": : :UFS/FFS will issue B_FREEBUF strategy calls, which a device driver :could turn into "secure delete" operations should the drive support :this, or multiple over-writes if it doesn't. ... and this actually would work. I use B_FREEBUF in MFS to deallocate underlying VM when possible, though I don't bother making it secure. :phk@FreeBSD.ORG "Real hackers run -current on their laptop." :FreeBSD -- It will take a long time before progress goes too far! -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 11:17:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from alpha.sea-to-sky.net (sea-to-sky.net [204.244.200.240]) by hub.freebsd.org (Postfix) with ESMTP id B007914DDF for ; Tue, 13 Jul 1999 11:17:13 -0700 (PDT) (envelope-from sreid@alpha.sea-to-sky.net) Received: (from sreid@localhost) by alpha.sea-to-sky.net (8.9.1a/8.8.7) id LAA25100; Tue, 13 Jul 1999 11:16:50 -0700 Date: Tue, 13 Jul 1999 11:16:50 -0700 (PDT) From: Steve Reid To: Garrett Wollman Cc: freebsd-security@freebsd.org Subject: Re: Module magic In-Reply-To: <19990713110916.A454@grok.nodomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Are you saying that X does not work when securelevel >= 0 under > > FreeBSD? > > That is correct. X requires direct access to I/O space, which is > fundamentally incompatible with the notion of enhanced security. I tried OpenBSD a while back (version 2.1) and X was able to function with the default securelevel = 1. This was done via the "aperture driver". I'm not familiar with the details of how it works. I guess it provides access to limited ranges of memory. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 11:25:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 3964714DDF for ; Tue, 13 Jul 1999 11:25:36 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id UAA25783; Tue, 13 Jul 1999 20:22:47 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: "Allen Smith" , Wes Peters , FreeBSD Security Subject: Re: Secure Deletion In-reply-to: Your message of "Tue, 13 Jul 1999 11:15:23 PDT." <199907131815.LAA79582@apollo.backplane.com> Date: Tue, 13 Jul 1999 20:22:46 +0200 Message-ID: <25781.931890166@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199907131815.LAA79582@apollo.backplane.com>, Matthew Dillon writes: > >:Just in case anybody wants to do this "RIGHT": >: >:UFS/FFS will issue B_FREEBUF strategy calls, which a device driver >:could turn into "secure delete" operations should the drive support >:this, or multiple over-writes if it doesn't. > > ... and this actually would work. I use B_FREEBUF in MFS to deallocate > underlying VM when possible, though I don't bother making it secure. Of course it does, it was written to do early delete on flash devices :-) -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 11:53:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from srh0710.urh.uiuc.edu (srh0710.urh.uiuc.edu [130.126.76.32]) by hub.freebsd.org (Postfix) with SMTP id 34B2314EE4 for ; Tue, 13 Jul 1999 11:53:35 -0700 (PDT) (envelope-from ftobin@uiuc.edu) Received: (qmail 93585 invoked by uid 1000); 13 Jul 1999 17:53:15 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Jul 1999 17:53:15 -0000 Date: Tue, 13 Jul 1999 12:53:15 -0500 (CDT) From: Frank Tobin X-Sender: ftobin@srh0710.urh.uiuc.edu To: security@FreeBSD.ORG Subject: Re: Module magic In-Reply-To: <199907131631.MAA05152@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman, at 12:31 on Tue, 13 Jul 1999, wrote: > > Are you saying that X does not work when securelevel >= 0 under > > FreeBSD? > > That is correct. X requires direct access to I/O space, which is > fundamentally incompatible with the notion of enhanced security. However, it seems, the XFree86 wants to open kmem or mem only on startup; one can start xdm and have it running fine with a functional securelevel. The only problem arises if one needs to do a server reset with Ctrl-Alt-Backspace. -- Frank Tobin "To learn what is good and what is to be www.neverending.org/~ftobin valued, those truths which cannot be shaken or changed." Myst: The Book of Atrus FreeBSD: The Power To Serve PGPenvelope = GPG and PGP5 + Pine PGP: 4F86 3BBB A816 6F0A 340F www.neverending.org/~ftobin/resources.html 6003 56FF D10A 260C 4FA3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 12: 3:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from alice.gba.oz.au (gba-254.tmx.com.au [203.9.155.254]) by hub.freebsd.org (Postfix) with SMTP id 5637114ED7 for ; Tue, 13 Jul 1999 12:03:33 -0700 (PDT) (envelope-from gjb-freebsd@gba.oz.au) Received: (qmail 5759 invoked by uid 1001); 13 Jul 1999 22:25:20 +1000 Message-ID: <19990713122520.5758.qmail@alice.gba.oz.au> X-Posted-By: GBA-Post 1.03 20-Sep-1998 X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 Date: Tue, 13 Jul 1999 22:25:20 +1000 From: Greg Black To: Robert Watson Cc: Garrett Wollman , Darren Reed , security@FreeBSD.ORG Subject: Re: Module magic References: In-reply-to: of Tue, 13 Jul 1999 06:34:49 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Watson writes: > > > > FWIW, I believe NetBSD systems (and OpenBSD systems) ship configured to > > > > boot with securelevel == 0, as opposed to FreeBSD which appears to default > > > > to -1. > > > > > > We think our users are more concerned about X working. > > > > Are you saying that X does not work when securelevel >= 0 under > > FreeBSD? > > If I recall, the XiG Accelerated X product requires direct access to > memory. vm_mmap.c: > > [...] > > Their code should probably not do this, as direct memory access violates > kernel safety. Can anybody tell me if this breakage only applies to XiG's Accelerated X or if it is also an issue with XFree86? -- Greg Black -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 14:13:45 1999 Delivered-To: freebsd-security@freebsd.org Received: from alice.gba.oz.au (gba-254.tmx.com.au [203.9.155.254]) by hub.freebsd.org (Postfix) with SMTP id 5736014F9D for ; Tue, 13 Jul 1999 14:13:33 -0700 (PDT) (envelope-from gjb-freebsd@gba.oz.au) Received: (qmail 8503 invoked by uid 1001); 14 Jul 1999 07:11:40 +1000 Message-ID: <19990713211140.8502.qmail@alice.gba.oz.au> X-Posted-By: GBA-Post 1.03 20-Sep-1998 X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 Date: Wed, 14 Jul 1999 07:11:39 +1000 From: Greg Black To: Garrett Wollman Cc: security@FreeBSD.ORG Subject: Re: Module magic References: <199907120945.TAA09669@cheops.anu.edu.au> <199907121736.NAA01917@khavrinen.lcs.mit.edu> <19990713010531.2897.qmail@alice.gba.oz.au> <199907131631.MAA05152@khavrinen.lcs.mit.edu> In-reply-to: <199907131631.MAA05152@khavrinen.lcs.mit.edu> of Tue, 13 Jul 1999 12:31:30 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman writes: > > Are you saying that X does not work when securelevel >= 0 under > > FreeBSD? > > That is correct. X requires direct access to I/O space, which is > fundamentally incompatible with the notion of enhanced security. Can you explain how FreeBSD differs from BSDI in this? I've been running various BSDI releases for years with XiG's XAccel and securelevel set to 2 with no problems at all, and I had hoped to do the same with FreeBSD (albeit with XFree86 rather than XAccel). -- Greg Black -- or To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 15:51:40 1999 Delivered-To: freebsd-security@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id BE89915088 for ; Tue, 13 Jul 1999 15:51:10 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id PAA10214; Tue, 13 Jul 1999 15:48:35 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA07743; Tue, 13 Jul 1999 15:48:30 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA25228; Tue, 13 Jul 99 15:48:33 PDT Message-Id: <378BC241.B73DB51@softweyr.com> Date: Tue, 13 Jul 1999 16:48:33 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Greg Black Cc: FreeBSD Security Subject: Re: Secure Deletion References: <199906250212.WAA07810@cc942873-a.ewndsr1.nj.home.com> <3773F67A.CC9B6215@softweyr.com> <19990629131529.A61249@bitbox.follo.net> <378A58EA.ACF1412F@softweyr.com> <19990713121453.5557.qmail@alice.gba.oz.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greg Black wrote: > > Wes Peters writes: > > > Here's the source for the new, improved > > version if anyone wants to test it themselves. > > > > Unless anyone has strenuous objections, I'll make this into a port and > > commit it (as soon as I learn how to make a port). > > There are two things that would be good to change: > > Throughout, -1 is used as an error return value and that is > eventually used as the program's exit value if any error > occurs. Those -1 values should be changed to +1, at least for > the final exit value. This is required for many reasons which I > won't rehash here. > > If the open() fails, it might be due to read-only permissions. > It would be good to attempt a chmod() to make it writeable and > retry the open() before bailing out, perhaps controlled by a -f > flag as used by programs like rm(1). It's possible to check the > reason for the open() failure and to look at the mode of the > file to verify its permissions before attempting the chmod(), > although that seems superfluous here. Excellent suggestions. Roger Wilco. When I get it done, I'll stick it on my ftp server and post a message here, rather than emailing the source all over the planet. ;^0 -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 17:37:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from entic.net (shell.entic.net [209.157.122.66]) by hub.freebsd.org (Postfix) with SMTP id E0CE915157 for ; Tue, 13 Jul 1999 17:37:18 -0700 (PDT) (envelope-from aj@entic.net) Received: (qmail 22030 invoked by uid 1000); 14 Jul 1999 00:37:32 -0000 Date: Tue, 13 Jul 1999 17:37:32 -0700 (PDT) From: Anil Jangity To: freebsd-security@freebsd.org Subject: INTERNAL_LS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org INTERNAL_LS for my ftp server included with FreeBSD, so users can't traverse directories outsides of $HOME. In their $HOME directory, I have a symbolic links to another part of the partition (not in /home). Now, when I try to use an FTP client to change direcotries to that symbolic link I get: "Too many levels of symbolic links." I am guessing this is related to that INTERNAL_LS feature. Is it possible to have ftp clients work for symbolic links and also follow the INTERNAL_LS feature at the same time? I really wouldnt want to take out that feature, but at the same time I do want FTP clinets to work. Is it all or nothing situation? ;-) Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 17:46:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id B65FF15157 for ; Tue, 13 Jul 1999 17:46:29 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 114DBj-000Dgl-00; Wed, 14 Jul 1999 02:46:19 +0200 From: Sheldon Hearn To: Anil Jangity Cc: security@freebsd.org Subject: Re: INTERNAL_LS In-reply-to: Your message of "Tue, 13 Jul 1999 17:37:32 MST." Date: Wed, 14 Jul 1999 02:46:19 +0200 Message-ID: <52622.931913179@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 13 Jul 1999 17:37:32 MST, Anil Jangity wrote: > In their $HOME directory, I have a symbolic links to another part of the > partition (not in /home). Now, when I try to use an FTP client to > change direcotries to that symbolic link I get: "Too many levels of > symbolic links." Are you sure that ``ls /'' gives you the results you expect? Perhaps you're chrooting them into their home directories. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 17:51:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from entic.net (shell.entic.net [209.157.122.66]) by hub.freebsd.org (Postfix) with SMTP id E58B31536B for ; Tue, 13 Jul 1999 17:51:30 -0700 (PDT) (envelope-from aj@entic.net) Received: (qmail 22391 invoked by uid 1000); 14 Jul 1999 00:50:58 -0000 Date: Tue, 13 Jul 1999 17:50:58 -0700 (PDT) From: Anil Jangity To: Sheldon Hearn Cc: security@freebsd.org Subject: Re: INTERNAL_LS In-Reply-To: <52622.931913179@axl.noc.iafrica.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Yea it does what its supposed to do. When I do ``ls / I'' should get back a listing of my $HOME, which it does. I have a symbolic link $HOME/temp to /tmp, now if i try to do ls $HOME/temp I want it to show me files in /tmp. I guess this is not possible when I have this INTERNAL_LS feature enabled. On Wed, 14 Jul 1999, Sheldon Hearn wrote: | | |On Tue, 13 Jul 1999 17:37:32 MST, Anil Jangity wrote: | |> In their $HOME directory, I have a symbolic links to another part of the |> partition (not in /home). Now, when I try to use an FTP client to |> change direcotries to that symbolic link I get: "Too many levels of |> symbolic links." | |Are you sure that ``ls /'' gives you the results you expect? Perhaps |you're chrooting them into their home directories. | |Ciao, |Sheldon. | Kind regards, Anil Jangity aj@entic.net Network Operations/Web Development http://www.entic.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 18: 9:37 1999 Delivered-To: freebsd-security@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id E042E14CB5 for ; Tue, 13 Jul 1999 18:09:28 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 114DWa-000DwO-00; Wed, 14 Jul 1999 03:07:52 +0200 From: Sheldon Hearn To: Anil Jangity Cc: security@freebsd.org Subject: Re: INTERNAL_LS In-reply-to: Your message of "Tue, 13 Jul 1999 17:50:58 MST." Date: Wed, 14 Jul 1999 03:07:52 +0200 Message-ID: <53589.931914472@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 13 Jul 1999 17:50:58 MST, Anil Jangity wrote: > Yea it does what its supposed to do. When I do ``ls / I'' should get back > a listing of my $HOME, which it does. So then ftp is indeed chrooting you into your home directory. This means that the apparent root directory is really $HOME. So your symlink to /tmp links to itself. This has nothing to do with INTERNAL_LS. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 20:33:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id A75C8151B8 for ; Tue, 13 Jul 1999 20:33:54 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id UAA64252; Tue, 13 Jul 1999 20:34:10 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Anil Jangity Cc: freebsd-security@FreeBSD.ORG Subject: Re: INTERNAL_LS In-reply-to: Your message of "Tue, 13 Jul 1999 17:37:32 PDT." Date: Tue, 13 Jul 1999 20:34:10 -0700 Message-ID: <64248.931923250@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > INTERNAL_LS for my ftp server included with FreeBSD, so users can't > traverse directories outsides of $HOME. No, that's a different feature. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 21:23: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 1FD0F14DC5 for ; Tue, 13 Jul 1999 21:23:02 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id WAA22317; Tue, 13 Jul 1999 22:21:04 -0600 (MDT) Message-Id: <4.2.0.58.19990713204251.044f34f0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 13 Jul 1999 20:43:39 -0600 To: Greg Black , Garrett Wollman From: Brett Glass Subject: Re: Module magic Cc: security@FreeBSD.ORG In-Reply-To: <19990713211140.8502.qmail@alice.gba.oz.au> References: <199907131631.MAA05152@khavrinen.lcs.mit.edu> <199907120945.TAA09669@cheops.anu.edu.au> <199907121736.NAA01917@khavrinen.lcs.mit.edu> <19990713010531.2897.qmail@alice.gba.oz.au> <199907131631.MAA05152@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Does XAccel for FreeBSD or BSDI still exist? I heard rumors that they'd dropped all of the BSDs and now only supported Linux. --Brett At 07:11 AM 7/14/99 +1000, Greg Black wrote: >Garrett Wollman writes: > > > > Are you saying that X does not work when securelevel >= 0 under > > > FreeBSD? > > > > That is correct. X requires direct access to I/O space, which is > > fundamentally incompatible with the notion of enhanced security. > >Can you explain how FreeBSD differs from BSDI in this? I've >been running various BSDI releases for years with XiG's XAccel >and securelevel set to 2 with no problems at all, and I had >hoped to do the same with FreeBSD (albeit with XFree86 rather >than XAccel). > >-- >Greg Black -- or > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 21:50:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id A1C7614D5F for ; Tue, 13 Jul 1999 21:50:47 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id VAA66463; Tue, 13 Jul 1999 21:47:28 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Brett Glass Cc: Greg Black , Garrett Wollman , security@FreeBSD.ORG Subject: Re: Module magic In-reply-to: Your message of "Tue, 13 Jul 1999 20:43:39 MDT." <4.2.0.58.19990713204251.044f34f0@localhost> Date: Tue, 13 Jul 1999 21:47:28 -0700 Message-ID: <66459.931927648@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org XiG continues to support FreeBSD just as it has for years and Thomas Roell, the company founder/chief tech, runs FreeBSD on his own machine. FreeBSD needs to be supported or he can't work. :) If that's not convincing enough, there's also their own web page at http://www.xig.com which you and the rest of the general public are always free to consult. This statement there: "On the other hand, the XFree86 server is free, and ours costs a little. Our ddx module ("graphics driver") for the TNT2 chipset is now available for download - free - for the owners of Accelerated-X Display Server v5. Don't forget, our server works on Solaris x86, too. And FreeBSD" Seems to answer the question to me... - Jordan > Does XAccel for FreeBSD or BSDI still exist? I heard rumors that > they'd dropped all of the BSDs and now only supported Linux. > > --Brett > > At 07:11 AM 7/14/99 +1000, Greg Black wrote: > >Garrett Wollman writes: > > > > > > Are you saying that X does not work when securelevel >= 0 under > > > > FreeBSD? > > > > > > That is correct. X requires direct access to I/O space, which is > > > fundamentally incompatible with the notion of enhanced security. > > > >Can you explain how FreeBSD differs from BSDI in this? I've > >been running various BSDI releases for years with XiG's XAccel > >and securelevel set to 2 with no problems at all, and I had > >hoped to do the same with FreeBSD (albeit with XFree86 rather > >than XAccel). > > > >-- > >Greg Black -- or > > > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-security" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 21:57:55 1999 Delivered-To: freebsd-security@freebsd.org Received: from srh0710.urh.uiuc.edu (srh0710.urh.uiuc.edu [130.126.76.32]) by hub.freebsd.org (Postfix) with SMTP id 5671014D5F for ; Tue, 13 Jul 1999 21:57:52 -0700 (PDT) (envelope-from ftobin@uiuc.edu) Received: (qmail 95600 invoked by uid 1000); 14 Jul 1999 04:56:10 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Jul 1999 04:56:10 -0000 Date: Tue, 13 Jul 1999 23:56:10 -0500 (CDT) From: Frank Tobin X-Sender: ftobin@srh0710.urh.uiuc.edu To: security@FreeBSD.ORG Subject: Re: Module magic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Frank Tobin, at 12:53 on Tue, 13 Jul 1999, wrote: > However, it seems, the XFree86 wants to open kmem or mem only on startup; > one can start xdm and have it running fine with a functional securelevel. > The only problem arises if one needs to do a server reset with > Ctrl-Alt-Backspace. Erm, I'd like to correct this before anyone gets confused. I meant to say that in order to get xdm (followed by x session) to work correctly with a securelevel > 0, one needs to start xdm, and _then_ raise the securelevel. This worked fine for me, anyways. Really caused me a lot of confusion, though, the first time the machine rebooted. I couldn't figure out why X was bombing upon startup; it was because the securelevel was being raised before X was starting. -- Frank Tobin "To learn what is good and what is to be www.neverending.org/~ftobin valued, those truths which cannot be shaken or changed." Myst: The Book of Atrus FreeBSD: The Power To Serve PGPenvelope = GPG and PGP5 + Pine PGP: 4F86 3BBB A816 6F0A 340F www.neverending.org/~ftobin/resources.html 6003 56FF D10A 260C 4FA3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 22:10:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 7114814F1F for ; Tue, 13 Jul 1999 22:10:29 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id XAA22695; Tue, 13 Jul 1999 23:07:54 -0600 (MDT) Message-Id: <4.2.0.58.19990713230358.044ebdb0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 13 Jul 1999 23:07:50 -0600 To: "Jordan K. Hubbard" From: Brett Glass Subject: Re: Module magic Cc: Greg Black , Garrett Wollman , security@FreeBSD.ORG In-Reply-To: <66459.931927648@zippy.cdrom.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 09:47 PM 7/13/99 -0700, Jordan K. Hubbard wrote: >XiG continues to support FreeBSD just as it has for years and Thomas >Roell, the company founder/chief tech, runs FreeBSD on his own >machine. FreeBSD needs to be supported or he can't work. :) Just reviewed my notes, and discovered that it wasn't the X server but rather two other things that were dropped. Here's a message you yourself wrote in January, in which you dismiss the notion of FreeBSD becoming popular on the desktop: >Delivered-To: vmailer-chat@freebsd.org >Received: by hub.freebsd.org (VMailer, from userid 1) > id 6AF83961F; Sun, 31 Jan 1999 16:33:10 -0800 (PST) >Received: (from majordom@localhost) > by hub.freebsd.org (8.8.8/8.8.8) id QAA20266 > for freebsd-chat-outgoing; Sun, 31 Jan 1999 16:33:09 -0800 (PST) > (envelope-from owner-freebsd-chat@FreeBSD.ORG) >Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) > by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA20261 > for ; Sun, 31 Jan 1999 16:33:08 -0800 (PST) > (envelope-from jkh@zippy.cdrom.com) >Received: from zippy.cdrom.com (localhost [127.0.0.1]) > by zippy.cdrom.com (8.9.2/8.9.2) with ESMTP id QAA79878; > Sun, 31 Jan 1999 16:33:49 -0800 (PST) > (envelope-from jkh@zippy.cdrom.com) >To: The Hermit Hacker >Cc: freebsd-chat@FreeBSD.ORG >Subject: Re: From Slashdot... >In-reply-to: Your message of "Sun, 31 Jan 1999 15:17:51 -0400." > >Date: Sun, 31 Jan 1999 16:33:49 -0800 >Message-ID: <79876.917829229@zippy.cdrom.com> >From: "Jordan K. Hubbard" >Sender: owner-freebsd-chat@FreeBSD.ORG >Precedence: bulk >X-Loop: FreeBSD.org >X-UIDL: 2552690906415f8bf48241823ccaf065 >Status: U > > > ...is FreeBSD destined to be a "server" environment only, with anyone > > wanting to do any serious graphics or multimedia needing to fall onto the > > Linux bandwagon? > >Yes. Interest in the desktop has been so marginal as to make it no >longer worth even thinking about and I think it's time to realize that >the server is our bread and butter. > >Everyone talks about how nice desktop support would be but nobody DOES >anything and, as a result, every initiative to support the desktop >more seriously in FreeBSD has been a dead loss. The desktop contest >went down without so much as a single decent entry, XiG sold about 3 >copies of CDE for FreeBSD when they made a play for the (non-existent) >FreeBSD desktop market (and don't tell me this was just anti-CDE >attitudes in action since they sold thousands of copies for Linux) and >the attempt to bring 3DFX support to FreeBSD has been so long in >coming that I'm no longer even waiting for it, etc. > >If I wanted a Unix machine purely for the desktop today, I'd install >Linux. It has all the multimedia frobs, support for exotic 3D gfx and >sound cards, desktop applications, you name it. FreeBSD has a pool of >about 50 users who feel about as strongly about the desktop, it seems, >and that's just not enough to reach critical mass, especially when >those users are not also software developers who can actually write >drivers and improve existing support. > >Do I sound bitter about this? Perhaps just a bit. For whatever >reason, the multimedia developers have not seen fit to actually >develop multimedia support in FreeBSD and, as a result, we merely have >a lot of users milling around asking when their hardware is going to >work. That's not a winning situation, and it's my hope that perhaps >DVD support will be the one thing we can do which allows us to catch >at least the trailing edge of the wave since it's also the one thing >that people who use X for little more than popping up lots of xterms >(as most FreeBSD users, including myself, seem to do in a >server-centric environment) will want. Movies have universal appeal. > >- Jordan > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-chat" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 22:50:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (Postfix) with ESMTP id 85C8614C3B for ; Tue, 13 Jul 1999 22:50:24 -0700 (PDT) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id PAA25344; Wed, 14 Jul 1999 15:49:10 +1000 (EST) From: Darren Reed Message-Id: <199907140549.PAA25344@cheops.anu.edu.au> Subject: Re: Module magic To: brett@lariat.org (Brett Glass) Date: Wed, 14 Jul 1999 15:49:09 +1000 (EST) Cc: jkh@zippy.cdrom.com, gjb-freebsd@gba.oz.au, wollman@khavrinen.lcs.mit.edu, security@FreeBSD.ORG In-Reply-To: <4.2.0.58.19990713230358.044ebdb0@localhost> from "Brett Glass" at Jul 13, 99 11:07:50 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org So, does XiG work with securelevel > 0 ? xdm seems to be a problem, but a solution (start xdm before the securelevel gets raised) is available. What other barriers are there to shipping with kernels that boot up `secure'? Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 23:30:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from entic.net (shell.entic.net [209.157.122.66]) by hub.freebsd.org (Postfix) with SMTP id ED45614DD4 for ; Tue, 13 Jul 1999 23:30:26 -0700 (PDT) (envelope-from aj@entic.net) Received: (qmail 29436 invoked by uid 1000); 14 Jul 1999 06:31:14 -0000 Date: Tue, 13 Jul 1999 23:31:14 -0700 (PDT) From: Anil Jangity To: freebsd-security@freebsd.org Subject: weird w report? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a weird user logon. Its there but at the same time its not there. Commands such as w(1) and last(1) report that a user is logged in but when I do ``ps auxU '' I don't see anything running for that user. Then, I did ``su -m '' and then ``kill -9 -1'' and still no luck. w(1) still reports as if the user is there. I have no zombies running. My question is why is it doing this and if so how can I get rid of it w/o having to reboot? Its not really a problem, but I am just wondering as to how to get rid of it if its possible. Thanks Anil Jangity To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 13 23:49:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 2910F14DD4 for ; Tue, 13 Jul 1999 23:49:09 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id XAA66674; Tue, 13 Jul 1999 23:47:32 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Brett Glass Cc: Greg Black , Garrett Wollman , security@FreeBSD.ORG Subject: Re: Module magic In-reply-to: Your message of "Tue, 13 Jul 1999 23:07:50 MDT." <4.2.0.58.19990713230358.044ebdb0@localhost> Date: Tue, 13 Jul 1999 23:47:32 -0700 Message-ID: <66670.931934852@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brett, did you buy a copy of CDE for FreeBSD when it was available? No? If not then you're part of the problem rather than the solution to this problem (as the message you cited clearly defines) and any further debate on the topic would be pointless. We'd just be going over the same old tired ground again - the non-buyers beating their chests over the fact that more ISVs aren't tripping over their shoelaces in a race to sell commercial software to markets uninterested in buying it. There's no point in getting delusionally paranoid about something which represents nothing more than market forces in action, sheesh! I also think it's somewhat ironic that their CDE sales have been so heavily tilted towards Linux as of late whereas the FreeBSD folks appear to have almost universally jumped on the KDE or GNOME bandwagons rather than buying CDE from XiG when it was available. This rabid insistence on using open source alternatives can't possibly be endearing us to the kind of commercial interests you've been trying to attract. :-) - Jordan > At 09:47 PM 7/13/99 -0700, Jordan K. Hubbard wrote: > >XiG continues to support FreeBSD just as it has for years and Thomas > >Roell, the company founder/chief tech, runs FreeBSD on his own > >machine. FreeBSD needs to be supported or he can't work. :) > > Just reviewed my notes, and discovered that it wasn't the X server > but rather two other things that were dropped. Here's a message > you yourself wrote in January, in which you dismiss the notion > of FreeBSD becoming popular on the desktop: > > >Delivered-To: vmailer-chat@freebsd.org > >Received: by hub.freebsd.org (VMailer, from userid 1) > > id 6AF83961F; Sun, 31 Jan 1999 16:33:10 -0800 (PST) > >Received: (from majordom@localhost) > > by hub.freebsd.org (8.8.8/8.8.8) id QAA20266 > > for freebsd-chat-outgoing; Sun, 31 Jan 1999 16:33:09 -0800 (PST) > > (envelope-from owner-freebsd-chat@FreeBSD.ORG) > >Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) > > by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA20261 > > for ; Sun, 31 Jan 1999 16:33:08 -0800 ( PST) > > (envelope-from jkh@zippy.cdrom.com) > >Received: from zippy.cdrom.com (localhost [127.0.0.1]) > > by zippy.cdrom.com (8.9.2/8.9.2) with ESMTP id QAA79878; > > Sun, 31 Jan 1999 16:33:49 -0800 (PST) > > (envelope-from jkh@zippy.cdrom.com) > >To: The Hermit Hacker > >Cc: freebsd-chat@FreeBSD.ORG > >Subject: Re: From Slashdot... > >In-reply-to: Your message of "Sun, 31 Jan 1999 15:17:51 -0400." > > > >Date: Sun, 31 Jan 1999 16:33:49 -0800 > >Message-ID: <79876.917829229@zippy.cdrom.com> > >From: "Jordan K. Hubbard" > >Sender: owner-freebsd-chat@FreeBSD.ORG > >Precedence: bulk > >X-Loop: FreeBSD.org > >X-UIDL: 2552690906415f8bf48241823ccaf065 > >Status: U > > > > > ...is FreeBSD destined to be a "server" environment only, with anyone > > > wanting to do any serious graphics or multimedia needing to fall onto the > > > Linux bandwagon? > > > >Yes. Interest in the desktop has been so marginal as to make it no > >longer worth even thinking about and I think it's time to realize that > >the server is our bread and butter. > > > >Everyone talks about how nice desktop support would be but nobody DOES > >anything and, as a result, every initiative to support the desktop > >more seriously in FreeBSD has been a dead loss. The desktop contest > >went down without so much as a single decent entry, XiG sold about 3 > >copies of CDE for FreeBSD when they made a play for the (non-existent) > >FreeBSD desktop market (and don't tell me this was just anti-CDE > >attitudes in action since they sold thousands of copies for Linux) and > >the attempt to bring 3DFX support to FreeBSD has been so long in > >coming that I'm no longer even waiting for it, etc. > > > >If I wanted a Unix machine purely for the desktop today, I'd install > >Linux. It has all the multimedia frobs, support for exotic 3D gfx and > >sound cards, desktop applications, you name it. FreeBSD has a pool of > >about 50 users who feel about as strongly about the desktop, it seems, > >and that's just not enough to reach critical mass, especially when > >those users are not also software developers who can actually write > >drivers and improve existing support. > > > >Do I sound bitter about this? Perhaps just a bit. For whatever > >reason, the multimedia developers have not seen fit to actually > >develop multimedia support in FreeBSD and, as a result, we merely have > >a lot of users milling around asking when their hardware is going to > >work. That's not a winning situation, and it's my hope that perhaps > >DVD support will be the one thing we can do which allows us to catch > >at least the trailing edge of the wave since it's also the one thing > >that people who use X for little more than popping up lots of xterms > >(as most FreeBSD users, including myself, seem to do in a > >server-centric environment) will want. Movies have universal appeal. > > > >- Jordan > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-chat" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 14 1:26: 2 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0190314D86 for ; Wed, 14 Jul 1999 01:26:00 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id EAA20143; Wed, 14 Jul 1999 04:25:10 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Wed, 14 Jul 1999 04:25:10 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Greg Black Cc: Garrett Wollman , Darren Reed , security@FreeBSD.ORG Subject: Re: Module magic In-Reply-To: <19990713122520.5758.qmail@alice.gba.oz.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 13 Jul 1999, Greg Black wrote: > Robert Watson writes: > > > > > > FWIW, I believe NetBSD systems (and OpenBSD systems) ship configured to > > > > > boot with securelevel == 0, as opposed to FreeBSD which appears to default > > > > > to -1. > > > > > > > > We think our users are more concerned about X working. > > > > > > Are you saying that X does not work when securelevel >= 0 under > > > FreeBSD? > > > > If I recall, the XiG Accelerated X product requires direct access to > > memory. vm_mmap.c: > > > > [...] > > > > Their code should probably not do this, as direct memory access violates > > kernel safety. > > Can anybody tell me if this breakage only applies to XiG's > Accelerated X or if it is also an issue with XFree86? I believe only for XiG, but I have not tried it in quite a while. The best thing to do to test this is to bump up the sysctl, and then see if X works. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 14 1:35:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 3FFC214D27 for ; Wed, 14 Jul 1999 01:35:35 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id EAA20174; Wed, 14 Jul 1999 04:34:01 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Wed, 14 Jul 1999 04:34:01 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Greg Black Cc: Garrett Wollman , Darren Reed , security@FreeBSD.ORG Subject: Re: Module magic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I believe only for XiG, but I have not tried it in quite a while. The > best thing to do to test this is to bump up the sysctl, and then see if X > works. Recent posts, of course, suggest that I am wrong and that it applies (for the obvious reasons) to all X servers. However, I have still not tried it :-). I am not sure how BSDI manages the securelevel + X thing. Perhaps they provide a kernel driver for the requisite video card interface, which can on demand provide the i/o port access and memory mapping, but only in such a way that the video card can be accessed. Alternatively, they hacked around it and there are holes in their securelevel implementation. I don't have desktop access to any BSDI machines right now, but once I return to the US, I'll give it a try. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 14 2:11:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 817C314DD3 for ; Wed, 14 Jul 1999 02:11:15 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id LAA10178; Wed, 14 Jul 1999 11:09:10 +0200 (CEST) (envelope-from des) To: Anil Jangity Cc: freebsd-security@FreeBSD.ORG Subject: Re: weird w report? References: From: Dag-Erling Smorgrav Date: 14 Jul 1999 11:09:10 +0200 In-Reply-To: Anil Jangity's message of "Tue, 13 Jul 1999 23:31:14 -0700 (PDT)" Message-ID: Lines: 11 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Anil Jangity writes: > Then, I did ``su -m '' and then ``kill -9 -1'' and still no luck. > w(1) still reports as if the user is there. I have no zombies running. My > question is why is it doing this and if so how can I get rid of it w/o > having to reboot? # chown root:wheel /dev/ttyxx DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 14 4:36:17 1999 Delivered-To: freebsd-security@freebsd.org Received: from alice.gba.oz.au (gba-254.tmx.com.au [203.9.155.254]) by hub.freebsd.org (Postfix) with SMTP id CD70C14EC1 for ; Wed, 14 Jul 1999 04:36:10 -0700 (PDT) (envelope-from gjb-freebsd@gba.oz.au) Received: (qmail 9786 invoked by uid 1001); 14 Jul 1999 21:09:43 +1000 Message-ID: <19990714110943.9785.qmail@alice.gba.oz.au> X-Posted-By: GBA-Post 1.03 20-Sep-1998 X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 Date: Wed, 14 Jul 1999 21:09:42 +1000 From: Greg Black To: "Jordan K. Hubbard" Cc: Brett Glass , security@FreeBSD.ORG Subject: XiG support [was: Re: Module magic] References: <66459.931927648@zippy.cdrom.com> In-reply-to: <66459.931927648@zippy.cdrom.com> of Tue, 13 Jul 1999 21:47:28 MST Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jordan K. Hubbard writes: > XiG continues to support FreeBSD just as it has for years and Thomas > Roell, the company founder/chief tech, runs FreeBSD on his own > machine. FreeBSD needs to be supported or he can't work. :) This whole new thread about the existence of XiG support for FreeBSD does not belong on freebsd-security and, since it has nothing whatever to do with anything I have written, should not be copied to me. Please take some care with the addresses and take the time to trim the irrelevant junk from quoted material. -- Greg Black -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 14 10:20:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 7A37E14BB8 for ; Wed, 14 Jul 1999 10:20:05 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 20CF781; Thu, 15 Jul 1999 01:18:26 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: "Jordan K. Hubbard" Cc: Anil Jangity , freebsd-security@FreeBSD.ORG Subject: Re: INTERNAL_LS In-reply-to: Your message of "Tue, 13 Jul 1999 20:34:10 MST." <64248.931923250@zippy.cdrom.com> Date: Thu, 15 Jul 1999 01:18:26 +0800 From: Peter Wemm Message-Id: <19990714171826.20CF781@overcee.netplex.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Jordan K. Hubbard" wrote: > > INTERNAL_LS for my ftp server included with FreeBSD, so users can't > > traverse directories outsides of $HOME. > > No, that's a different feature. And it should be on by default. (INTERNAL_LS that is..) The ftp-chroot I am not so sure about, I almost think it would be best on by default too, but changing that is likely to start another 'my shell is better than your shell type war'.. > - Jordan Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 14 10:44:45 1999 Delivered-To: freebsd-security@freebsd.org Received: from sfmailrelay.hamquist.com (sfmailrelay2.hamquist.com [199.108.89.15]) by hub.freebsd.org (Postfix) with SMTP id 1FC5D14BD8 for ; Wed, 14 Jul 1999 10:44:34 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from 10.40.251.222 by sfmailrelay.hamquist.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v3.6); Wed, 14 Jul 99 10:42:40 -0700 X-Server-Uuid: c29e0ff2-e8b9-11d1-a493-00c04fbbd7d3 Received: by sf1-mail03 with Internet Mail Service (5.5.2448.0) id <3RP6TKFF>; Wed, 14 Jul 1999 10:42:40 -0700 Message-ID: From: "Childers, Richard" To: "'Anil Jangity '" , "'freebsd-security@freebsd.org '" Subject: RE: weird w report? Date: Wed, 14 Jul 1999 10:42:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) X-WSS-ID: 1B92139A161287-01-02 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "I have a weird user logon." I don't mean to sound like an old grouch, here, but trouble reports that are not accompanied by simple ASCII cut-and-paste examples of the 'here's what I do, here's what I see' variety are worth almost nothing. If you (not you, Anil, but the second person, generic 'you') can't be bothered to take this small effort to facilitate the efforts of others to assist you, then how can you expect others to expend any effort to help you resolve your problem ?? Here's an example: When I run the command 'foo -bar blat' I get an error. (That's where the usual description cuts off. The professional reporter of system problems would continue:) Here's what I see: root@spam.vax.com # uname -s -r FreeBSD 2.2.9-RELEASE (-: root@spam.vax.com # which foo /usr/bin/foo root@spam.vax.com # file `which foo` foo: FreeBSD/i386 compact demand-paged executable root@spam.vax.com # foo Usage: foo [-[abcdefghijklmnopqrstuvwxyz] file [file] root@spam.vax.com # ls -l ./blat -rw-r--r-- 1 root bin 123 Feb 29 04:01 ./blat root@spam.vax.com # foo -bar ./blat ERROR: No such file or directory '.' We can take it one step further: root@spam.vax.com # foo -bar ./blat ; echo $status ERROR: No such file or directory '.' 4 Now, *there's* a diagnostic description ... the person(s) on the receiving end now know your operating system version, the path to the executable, the way you are using it, the type of file being run and the type of file the utility is being run on, and, not just the error message, but the return status of the command, as well. This is important for the person reporting the problem, as well as the person resolving the problem; because it is an opportunity to become a better-informed customer, and because it is the first step to becoming independent of those more knowledgeable than oneself, as one grows into the role of being more knowledgeable, oneself, through experience ... -- richard -----Original Message----- From: Anil Jangity To: freebsd-security@freebsd.org Sent: 7/13/99 11:31 PM Subject: weird w report? I have a weird user logon. Its there but at the same time its not there. Commands such as w(1) and last(1) report that a user is logged in but when I do ``ps auxU '' I don't see anything running for that user. Then, I did ``su -m '' and then ``kill -9 -1'' and still no luck. w(1) still reports as if the user is there. I have no zombies running. My question is why is it doing this and if so how can I get rid of it w/o having to reboot? Its not really a problem, but I am just wondering as to how to get rid of it if its possible. Thanks Anil Jangity To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 14 10:52:10 1999 Delivered-To: freebsd-security@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 153C515437 for ; Wed, 14 Jul 1999 10:52:08 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA68097; Wed, 14 Jul 1999 10:50:33 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: "Childers, Richard" Cc: "'Anil Jangity '" , "'freebsd-security@freebsd.org '" Subject: Re: weird w report? In-reply-to: Your message of "Wed, 14 Jul 1999 10:42:39 PDT." Date: Wed, 14 Jul 1999 10:50:33 -0700 Message-ID: <68093.931974633@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I don't mean to sound like an old grouch, here, but trouble reports that are > not accompanied by simple ASCII cut-and-paste examples of the 'here's what I > do, here's what I see' variety are worth almost nothing. An excellent summary. Would you be willing to post this once a month to freebsd-questions? :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 14 11: 4:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from entic.net (shell.entic.net [209.157.122.66]) by hub.freebsd.org (Postfix) with SMTP id 32FAD14DF4 for ; Wed, 14 Jul 1999 11:04:24 -0700 (PDT) (envelope-from aj@entic.net) Received: (qmail 13080 invoked by uid 1000); 14 Jul 1999 18:05:14 -0000 Date: Wed, 14 Jul 1999 11:05:13 -0700 (PDT) From: Anil Jangity To: "Childers, Richard" Cc: "'freebsd-security@freebsd.org '" Subject: RE: weird w report? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org |"I have a weird user logon." | | | |I don't mean to sound like an old grouch, here, but trouble reports that are |not accompanied by simple ASCII cut-and-paste examples of the 'here's what I |do, here's what I see' variety are worth almost nothing. Richard, I don't see how different this is from my explanation post but here goes: -------------------------------------------------------------------------- [root@shell:~] w |grep drenica root p6 fiber.entic.net 10:57AM - grep drenica drenica pj 98CC44E1.ipt.aol Thu07PM 5days - [root@shell:~] ls -la /dev/ttypj crw-rw-rw- 1 root wheel 5, 19 Jul 8 19:31 /dev/ttypj [root@shell:~] w | grep drenica root p6 fiber.entic.net 10:57AM - grep drenica drenica pj 98CC44E1.ipt.aol Thu07PM 5days - [root@shell:~] last drenica | grep pj drenica ttypj 152.204.68.225 Thu Jul 8 19:24 still logged in [root@shell:~] ping 152.204.68.225 PING 152.204.68.225 (152.204.68.225): 56 data bytes ^C36 bytes from 205.188.192.98: Destination Host Unreachable Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 5400 24de 0 0000 f0 01 7c3d 209.157.122.66 152.204.68.225 --- 152.204.68.225 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss [root@shell:~] su -l drenica [drenica@shell:~] ps PID TT STAT TIME COMMAND 12865 p6 S 0:00.08 -su (bash) 12868 p6 R+ 0:00.00 ps [drenica@shell:~] kill -9 -1 su: kill: (-1) - No such pid [drenica@shell:~] exit logout [root@shell:~] ps auxU drenica USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND [root@shell:~] [drenica@shell:~] ps PID TT STAT TIME COMMAND 12865 p6 S 0:00.08 -su (bash) 12868 p6 R+ 0:00.00 ps [drenica@shell:~] kill -9 -1 su: kill: (-1) - No such pid oh and: [root@shell:/var/log] uname -r 2.2.8-STABLE ;-) -------------------------------------------------------------------------- I think a reboot will fix it, but I am not going to reboot over this. So, looking for other alternatives. Kind regards, Anil Jangity To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 14 11:26:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from ds9.sci.fi (ds9.sci.fi [195.74.0.54]) by hub.freebsd.org (Postfix) with ESMTP id A586715402 for ; Wed, 14 Jul 1999 11:26:00 -0700 (PDT) (envelope-from yurtesen@ispro.net.tr) Received: from ispro.net.tr (dyn-0-150.tku.netti.fi [195.16.223.151]) by ds9.sci.fi (8.9.1/8.9.1) with ESMTP id VAA24776; Wed, 14 Jul 1999 21:25:47 +0300 (EET DST) Message-ID: <378CD6E8.D515E81D@ispro.net.tr> Date: Wed, 14 Jul 1999 21:28:57 +0300 From: Evren Yurtesen X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Anil Jangity Cc: "Childers, Richard" , "'freebsd-security@freebsd.org '" Subject: Re: weird w report? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org well, I have had the same kind of thing in FreeBSD 3.1-Stable, and I could not find a way to log out the user, well I also could not find any process owned by that user! I thought the problem was about /var/run/utmp file which was supposed to know the logged in users... then I just deleted it by issuing cat /dev/null > /var/run/utmp and everything is normal right now, there have been 2 weeks so far after this weird thing. when I deleted it I have found myself invisible too, and w was saying there are 0 users logged in! then I logged out and logged in again and it was normal ( for a moment I thought it may say -1 users or something though ) Evren Anil Jangity wrote: > |"I have a weird user logon." > | > | > | > |I don't mean to sound like an old grouch, here, but trouble reports that are > |not accompanied by simple ASCII cut-and-paste examples of the 'here's what I > |do, here's what I see' variety are worth almost nothing. > > Richard, > > I don't see how different this is from my explanation post but here goes: > > -------------------------------------------------------------------------- > [root@shell:~] w |grep drenica > root p6 fiber.entic.net 10:57AM - grep drenica > drenica pj 98CC44E1.ipt.aol Thu07PM 5days - > [root@shell:~] ls -la /dev/ttypj > crw-rw-rw- 1 root wheel 5, 19 Jul 8 19:31 /dev/ttypj > [root@shell:~] w | grep drenica > root p6 fiber.entic.net 10:57AM - grep drenica > drenica pj 98CC44E1.ipt.aol Thu07PM 5days - > [root@shell:~] last drenica | grep pj > drenica ttypj 152.204.68.225 Thu Jul 8 19:24 still logged in > [root@shell:~] ping 152.204.68.225 > PING 152.204.68.225 (152.204.68.225): 56 data bytes > ^C36 bytes from 205.188.192.98: Destination Host Unreachable > Vr HL TOS Len ID Flg off TTL Pro cks Src Dst > 4 5 00 5400 24de 0 0000 f0 01 7c3d 209.157.122.66 152.204.68.225 > > --- 152.204.68.225 ping statistics --- > 1 packets transmitted, 0 packets received, 100% packet loss > [root@shell:~] su -l drenica > [drenica@shell:~] ps > PID TT STAT TIME COMMAND > 12865 p6 S 0:00.08 -su (bash) > 12868 p6 R+ 0:00.00 ps > [drenica@shell:~] kill -9 -1 > su: kill: (-1) - No such pid > [drenica@shell:~] exit > logout > [root@shell:~] ps auxU drenica > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > [root@shell:~] [drenica@shell:~] ps > PID TT STAT TIME COMMAND > 12865 p6 S 0:00.08 -su (bash) > 12868 p6 R+ 0:00.00 ps > [drenica@shell:~] kill -9 -1 > su: kill: (-1) - No such pid > > oh and: > [root@shell:/var/log] uname -r > 2.2.8-STABLE > > ;-) > -------------------------------------------------------------------------- > I think a reboot will fix it, but I am not going to reboot over this. So, > looking for other alternatives. > > Kind regards, > > Anil Jangity > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 14 11:27:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from acetylene.vapornet.net (acetylene.vapornet.net [209.100.218.11]) by hub.freebsd.org (Postfix) with ESMTP id 25DB615431 for ; Wed, 14 Jul 1999 11:27:34 -0700 (PDT) (envelope-from john@vapornet.net) Received: from datapit.home.vapornet.net (vapornet.xnet.com [205.243.141.107]) by acetylene.vapornet.net (8.9.3/8.9.3/VaporHub 1.5) with ESMTP id NAA50409; Wed, 14 Jul 1999 13:27:00 -0500 (CDT) (envelope from: john@vapornet.net) Received: from habanero.chili-pepper.net (habanero.chili-pepper.net [192.168.0.11]) by datapit.home.vapornet.net (8.9.3/8.9.3/VaporServer 1.4) with ESMTP id NAA03194; Wed, 14 Jul 1999 13:26:58 -0500 (CDT) (envelope from: john@vapornet.net) Received: (from john@localhost) by habanero.chili-pepper.net (8.9.3/8.9.3/VaporClient v3.1) id NAA02819; Wed, 14 Jul 1999 13:26:58 -0500 (CDT) (envelope from: john@vapornet.net) From: John Preisler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Jul 1999 13:26:58 -0500 (CDT) To: Anil Jangity Cc: "'freebsd-security@freebsd.org '" Subject: RE: weird w report? In-Reply-To: References: X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14220.54680.327151.509940@habanero.chili-pepper.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org its a remnant leftover from a gnu screen session. -j Anil Jangity writes: > |"I have a weird user logon." > | > | > | > |I don't mean to sound like an old grouch, here, but trouble reports that are > |not accompanied by simple ASCII cut-and-paste examples of the 'here's what I > |do, here's what I see' variety are worth almost nothing. > > > Richard, > > I don't see how different this is from my explanation post but here goes: > > -------------------------------------------------------------------------- > [root@shell:~] w |grep drenica > root p6 fiber.entic.net 10:57AM - grep drenica > drenica pj 98CC44E1.ipt.aol Thu07PM 5days - > [root@shell:~] ls -la /dev/ttypj > crw-rw-rw- 1 root wheel 5, 19 Jul 8 19:31 /dev/ttypj > [root@shell:~] w | grep drenica > root p6 fiber.entic.net 10:57AM - grep drenica > drenica pj 98CC44E1.ipt.aol Thu07PM 5days - > [root@shell:~] last drenica | grep pj > drenica ttypj 152.204.68.225 Thu Jul 8 19:24 still logged in > [root@shell:~] ping 152.204.68.225 > PING 152.204.68.225 (152.204.68.225): 56 data bytes > ^C36 bytes from 205.188.192.98: Destination Host Unreachable > Vr HL TOS Len ID Flg off TTL Pro cks Src Dst > 4 5 00 5400 24de 0 0000 f0 01 7c3d 209.157.122.66 152.204.68.225 > > > --- 152.204.68.225 ping statistics --- > 1 packets transmitted, 0 packets received, 100% packet loss > [root@shell:~] su -l drenica > [drenica@shell:~] ps > PID TT STAT TIME COMMAND > 12865 p6 S 0:00.08 -su (bash) > 12868 p6 R+ 0:00.00 ps > [drenica@shell:~] kill -9 -1 > su: kill: (-1) - No such pid > [drenica@shell:~] exit > logout > [root@shell:~] ps auxU drenica > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > [root@shell:~] [drenica@shell:~] ps > PID TT STAT TIME COMMAND > 12865 p6 S 0:00.08 -su (bash) > 12868 p6 R+ 0:00.00 ps > [drenica@shell:~] kill -9 -1 > su: kill: (-1) - No such pid > > oh and: > [root@shell:/var/log] uname -r > 2.2.8-STABLE > > ;-) > -------------------------------------------------------------------------- > I think a reboot will fix it, but I am not going to reboot over this. So, > looking for other alternatives. > > > Kind regards, > > Anil Jangity > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 14 11:47:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from ds9.sci.fi (ds9.sci.fi [195.74.0.54]) by hub.freebsd.org (Postfix) with ESMTP id A36DE14D0D for ; Wed, 14 Jul 1999 11:47:45 -0700 (PDT) (envelope-from yurtesen@ispro.net.tr) Received: from ispro.net.tr (dyn-0-150.tku.netti.fi [195.16.223.151]) by ds9.sci.fi (8.9.1/8.9.1) with ESMTP id VAA25389; Wed, 14 Jul 1999 21:46:32 +0300 (EET DST) Message-ID: <378CDBC2.7EDF748C@ispro.net.tr> Date: Wed, 14 Jul 1999 21:49:39 +0300 From: Evren Yurtesen X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: John Preisler Cc: Anil Jangity , "'freebsd-security@freebsd.org '" Subject: Re: weird w report? References: <14220.54680.327151.509940@habanero.chili-pepper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org well, how come that can happen if that user does not have a process running? and in my previous email I told that the same thing happened to me, the user who was in w but had no process was myself! and I am sure that I did not use screen command, also it is not even installed on my system. Evren John Preisler wrote: > its a remnant leftover from a gnu screen session. > > -j > > Anil Jangity writes: > > |"I have a weird user logon." > > | > > | > > | > > |I don't mean to sound like an old grouch, here, but trouble reports that are > > |not accompanied by simple ASCII cut-and-paste examples of the 'here's what I > > |do, here's what I see' variety are worth almost nothing. > > > > > > Richard, > > > > I don't see how different this is from my explanation post but here goes: > > > > -------------------------------------------------------------------------- > > [root@shell:~] w |grep drenica > > root p6 fiber.entic.net 10:57AM - grep drenica > > drenica pj 98CC44E1.ipt.aol Thu07PM 5days - > > [root@shell:~] ls -la /dev/ttypj > > crw-rw-rw- 1 root wheel 5, 19 Jul 8 19:31 /dev/ttypj > > [root@shell:~] w | grep drenica > > root p6 fiber.entic.net 10:57AM - grep drenica > > drenica pj 98CC44E1.ipt.aol Thu07PM 5days - > > [root@shell:~] last drenica | grep pj > > drenica ttypj 152.204.68.225 Thu Jul 8 19:24 still logged in > > [root@shell:~] ping 152.204.68.225 > > PING 152.204.68.225 (152.204.68.225): 56 data bytes > > ^C36 bytes from 205.188.192.98: Destination Host Unreachable > > Vr HL TOS Len ID Flg off TTL Pro cks Src Dst > > 4 5 00 5400 24de 0 0000 f0 01 7c3d 209.157.122.66 152.204.68.225 > > > > > > --- 152.204.68.225 ping statistics --- > > 1 packets transmitted, 0 packets received, 100% packet loss > > [root@shell:~] su -l drenica > > [drenica@shell:~] ps > > PID TT STAT TIME COMMAND > > 12865 p6 S 0:00.08 -su (bash) > > 12868 p6 R+ 0:00.00 ps > > [drenica@shell:~] kill -9 -1 > > su: kill: (-1) - No such pid > > [drenica@shell:~] exit > > logout > > [root@shell:~] ps auxU drenica > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > > [root@shell:~] [drenica@shell:~] ps > > PID TT STAT TIME COMMAND > > 12865 p6 S 0:00.08 -su (bash) > > 12868 p6 R+ 0:00.00 ps > > [drenica@shell:~] kill -9 -1 > > su: kill: (-1) - No such pid > > > > oh and: > > [root@shell:/var/log] uname -r > > 2.2.8-STABLE > > > > ;-) > > -------------------------------------------------------------------------- > > I think a reboot will fix it, but I am not going to reboot over this. So, > > looking for other alternatives. > > > > > > Kind regards, > > > > Anil Jangity > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 14 11:51: 7 1999 Delivered-To: freebsd-security@freebsd.org Received: from linux.equilibrate.net (linux.equilibrate.net [193.173.72.25]) by hub.freebsd.org (Postfix) with ESMTP id 861D415715 for ; Wed, 14 Jul 1999 11:50:59 -0700 (PDT) (envelope-from jascha@linux.equilibrate.net) Received: (from jascha@localhost) by linux.equilibrate.net (8.9.3/8.9.3) id UAA20789 for security@freebsd.org; Wed, 14 Jul 1999 20:51:10 +0200 Date: Wed, 14 Jul 1999 20:51:10 +0200 From: jascha@equilibrate.net To: security@freebsd.org Subject: VPN/Secure Tunnel Message-ID: <19990714205110.A20751@equilibrate.net> Reply-To: jascha@equilibrate.net Mime-Version: 1.0 Content-Type: multipart/signed; boundary=iVCmgExH7+hIHJ1A; micalg=pgp-md5; protocol="application/pgp-signature" X-Mailer: Mutt 0.95.6i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --iVCmgExH7+hIHJ1A Content-Type: multipart/mixed; boundary="jy6Sn24JjFx/iggw" --jy6Sn24JjFx/iggw Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi All Readers, I have a little question, i want to setup a VPN or Secure Tunnel from multi= ple FreeBSD machines to 1 main machine behind a firewall, the firewall config is no problem at all, but finding solid software to setup the tunnel is harder, i found ipsec v0.05, and kame (for 3.2 there is only a snapshot while i'm= =20 typing this). I hope there will be some more options, or that there are=20 persons who can mail me back that they are using or used one of the to above programs successfull and stable.=20 Please send reactions directly to jascha@equilibrate.net. Kind Regards, A.J. Hoogenraad Equilibrate Networking --jy6Sn24JjFx/iggw Content-Type: application/pgp-keys Content-Description: PGP Key 0xD367DBE9. Content-Disposition: attachment; filename=mutt-linux-20751-3 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAzeAZzMAAAEEALRB/AKQX7NlCCehWQEWCMdyt2Vf0qLGVmUKSagMjr1rpxSy K7nWusK1PWvUNWjZ67I8QO3AqIUsBWLND5ntuNpdLmpydBYlhpVztdEgBcU3QFcy r74O0rL17BVljchmNfmufvpJC4txhDegx3t0IYbdaiL1ftSpFMv+P/PTZ9vpAAUR tA9BLkouIEhvb2dlbnJhYWSJAJUDBRA3gGczy/4/89Nn2+kBAQ99BACDNq18tRhX 5SlEN/eZPdWo61OtxaMHzAhXA/Z/53c8HNEqqDt6QlISt2yZEjbDMBU+uqTWZyin GMMxj+Rqi9gRxzjXQxJ02vPauhffHQ+qjWBMov64QSHXalnF5N1QcjAMqp4Eyysh 3NrYhCGneDObANImtqgttv8EYdnXuFrOCA== =WKPv -----END PGP PUBLIC KEY BLOCK----- --jy6Sn24JjFx/iggw-- --iVCmgExH7+hIHJ1A Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia iQCVAwUBN4zcHsv+P/PTZ9vpAQFQSQQAqpRegFJCUN7rE+gySVkQIewdd2jEaDg5 1tzrI3g4TsPLPy64Q7181XI7aSdZ6f4uzauUZcYamD5DBuae0kVeUGjq8o51oeip Vxoc75sJvOP7vo6InF3ArD31nrFVsMvWMQYtIm0ncPZu/ymcLEpJW30PrbBUTGsD gDRlZ/vrt1Q= =9Q5q -----END PGP SIGNATURE----- --iVCmgExH7+hIHJ1A-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 14 12:19:48 1999 Delivered-To: freebsd-security@freebsd.org Received: from sfmailrelay.hamquist.com (sfmailrelay2.hamquist.com [199.108.89.15]) by hub.freebsd.org (Postfix) with SMTP id 2EC7615420 for ; Wed, 14 Jul 1999 12:18:46 -0700 (PDT) (envelope-from RCHILDER@hamquist.com) Received: from 10.40.251.222 by sfmailrelay.hamquist.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v3.6); Wed, 14 Jul 99 12:17:55 -0700 X-Server-Uuid: c29e0ff2-e8b9-11d1-a493-00c04fbbd7d3 Received: by sf1-mail03 with Internet Mail Service (5.5.2448.0) id <3RP6TMDC>; Wed, 14 Jul 1999 12:17:54 -0700 Message-ID: From: "Childers, Richard" To: "'Anil Jangity '" , "Childers, Richard" Cc: "''freebsd-security@freebsd.org ' '" Subject: RE: weird w report? Date: Wed, 14 Jul 1999 12:17:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) X-WSS-ID: 1B923DE9173805-01-02 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Anil notes: "kill -9 -1" Umm, why are you doing a "kill -9 -1" ? There is no process ID "-1". I see that the man page for 'kill' describes a usage '-1' where '-1' is a special PID that translates as 'send the signal to all processes' if you are logged in as "root"; you probably don't want to do this. (-: Which is why you su'd to the userid, I am speculating ... it seems intuitive that a user would be able to kill his own processes, but sometimes things are such that killing the process as "root" is preferred; in fact, trying to kill the process and not being successful can lead to the process becoming zombie'd, which is why I advise killing PIDs from "root". Try killing the process ID, as "root" : kill -9 ##### ... where ##### is the process ID reported by something like ps -aux | grep drenica ... where the first column is the userid, and the second column is the process ID. You may find it useful to search for all process IDs owned by that userid, sort them in reverse numeric order (IE, highest to lowest) and kill them in that reversed order; this is because the process ID roughly indicates ordinal sequence, such that killing them in the order of their process ID, reversed, one is killing processes in the reverse order they were started, in this fashion avoiding killing parent processes before child processes (which results in zombie processes). For example: # csh root@spawn.vax.com # ps -aux | grep drenica | grep -v grep \ | awk ' { print $2 }' | sort -rn > /tmp/badpids root@spawn.vax.com # foreach pid ( `cat /tmp/badpids` ) ? echo "killing $pid" && kill -9 ${pid} ? end root@spawn.vax.com # Hope this provides some insight ... -- richard To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 14 13:17:54 1999 Delivered-To: freebsd-security@freebsd.org Received: from acetylene.vapornet.net (acetylene.vapornet.net [209.100.218.11]) by hub.freebsd.org (Postfix) with ESMTP id 8CDBF14CF8 for ; Wed, 14 Jul 1999 13:17:49 -0700 (PDT) (envelope-from john@vapornet.net) Received: from datapit.home.vapornet.net (vapornet.xnet.com [205.243.141.107]) by acetylene.vapornet.net (8.9.3/8.9.3/VaporHub 1.5) with ESMTP id PAA50735; Wed, 14 Jul 1999 15:17:10 -0500 (CDT) (envelope from: john@vapornet.net) Received: from habanero.chili-pepper.net (habanero.chili-pepper.net [192.168.0.11]) by datapit.home.vapornet.net (8.9.3/8.9.3/VaporServer 1.4) with ESMTP id PAA03424; Wed, 14 Jul 1999 15:17:08 -0500 (CDT) (envelope from: john@vapornet.net) Received: (from john@localhost) by habanero.chili-pepper.net (8.9.3/8.9.3/VaporClient v3.1) id PAA03053; Wed, 14 Jul 1999 15:17:08 -0500 (CDT) (envelope from: john@vapornet.net) From: John Preisler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Jul 1999 15:17:07 -0500 (CDT) To: Evren Yurtesen Cc: "'freebsd-security@freebsd.org '" Subject: Re: weird w report? In-Reply-To: <378CDBC2.7EDF748C@ispro.net.tr> References: <14220.54680.327151.509940@habanero.chili-pepper.net> <378CDBC2.7EDF748C@ispro.net.tr> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14220.60921.284563.561916@habanero.chili-pepper.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Evren Yurtesen writes: > well, how come that can happen if that user does not have a process > running? consider it a bug. i always thtought it was a bug in screen because i only see it manifest itself when screen is a factor. after they close the screen session and log out, the entry in utmp still remained. > and in my previous email I told that the same thing happened to me, > the user who was in w but had no process was myself! yes, after you blew away utmp you said nobody showed up not even yourself, and didnt update until you [the next user to do so, presumably] logged in again. expected behavior. > and I am sure that I did not use screen command, also it is not > even installed on my system. > Evren anyway, the user is not logged in as you can tell by the lack of processes running for said user. its a bogus utmp entry. the offending tty is available, and last(1) will still show user logged in even after the tty gets used again. -j > > John Preisler wrote: > > > its a remnant leftover from a gnu screen session. > > > > -j > > > > Anil Jangity writes: > > > |"I have a weird user logon." > > > | > > > | > > > | > > > |I don't mean to sound like an old grouch, here, but trouble reports that are > > > |not accompanied by simple ASCII cut-and-paste examples of the 'here's what I > > > |do, here's what I see' variety are worth almost nothing. > > > > > > > > > Richard, > > > > > > I don't see how different this is from my explanation post but here goes: > > > > > > -------------------------------------------------------------------------- > > > [root@shell:~] w |grep drenica > > > root p6 fiber.entic.net 10:57AM - grep drenica > > > drenica pj 98CC44E1.ipt.aol Thu07PM 5days - > > > [root@shell:~] ls -la /dev/ttypj > > > crw-rw-rw- 1 root wheel 5, 19 Jul 8 19:31 /dev/ttypj > > > [root@shell:~] w | grep drenica > > > root p6 fiber.entic.net 10:57AM - grep drenica > > > drenica pj 98CC44E1.ipt.aol Thu07PM 5days - > > > [root@shell:~] last drenica | grep pj > > > drenica ttypj 152.204.68.225 Thu Jul 8 19:24 still logged in > > > [root@shell:~] ping 152.204.68.225 > > > PING 152.204.68.225 (152.204.68.225): 56 data bytes > > > ^C36 bytes from 205.188.192.98: Destination Host Unreachable > > > Vr HL TOS Len ID Flg off TTL Pro cks Src Dst > > > 4 5 00 5400 24de 0 0000 f0 01 7c3d 209.157.122.66 152.204.68.225 > > > > > > > > > --- 152.204.68.225 ping statistics --- > > > 1 packets transmitted, 0 packets received, 100% packet loss > > > [root@shell:~] su -l drenica > > > [drenica@shell:~] ps > > > PID TT STAT TIME COMMAND > > > 12865 p6 S 0:00.08 -su (bash) > > > 12868 p6 R+ 0:00.00 ps > > > [drenica@shell:~] kill -9 -1 > > > su: kill: (-1) - No such pid > > > [drenica@shell:~] exit > > > logout > > > [root@shell:~] ps auxU drenica > > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > > > [root@shell:~] [drenica@shell:~] ps > > > PID TT STAT TIME COMMAND > > > 12865 p6 S 0:00.08 -su (bash) > > > 12868 p6 R+ 0:00.00 ps > > > [drenica@shell:~] kill -9 -1 > > > su: kill: (-1) - No such pid > > > > > > oh and: > > > [root@shell:/var/log] uname -r > > > 2.2.8-STABLE > > > > > > ;-) > > > -------------------------------------------------------------------------- > > > I think a reboot will fix it, but I am not going to reboot over this. So, > > > looking for other alternatives. > > > > > > > > > Kind regards, > > > > > > Anil Jangity > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-security" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 14 15:21:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from easeway.com (ns1.easeway.com [209.69.39.1]) by hub.freebsd.org (Postfix) with ESMTP id 78E06154BF for ; Wed, 14 Jul 1999 15:21:14 -0700 (PDT) (envelope-from mwlucas@easeway.com) Received: (from mwlucas@localhost) by easeway.com (8.8.8/8.8.5) id SAA17144; Wed, 14 Jul 1999 18:09:33 -0400 (EDT) Message-Id: <199907142209.SAA17144@easeway.com> Subject: Re: VPN/Secure Tunnel In-Reply-To: <19990714205110.A20751@equilibrate.net> from "jascha@equilibrate.net" at "Jul 14, 99 08:51:10 pm" To: jascha@equilibrate.net Date: Wed, 14 Jul 1999 18:09:33 -0400 (EDT) Cc: security@FreeBSD.ORG From: mwlucas@exceptionet.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If the firewall is not a NAT, use SKIP (/usr/ports/security/skip). Very nice, solid, and reliable, and there's even a Windows client if you have to add others later. ==ml > Hi All Readers, > > I have a little question, i want to setup a VPN or Secure Tunnel from multiple > FreeBSD machines to 1 main machine behind a firewall, the firewall config is > no problem at all, but finding solid software to setup the tunnel is harder, > i found ipsec v0.05, and kame (for 3.2 there is only a snapshot while i'm > typing this). I hope there will be some more options, or that there are > persons who can mail me back that they are using or used one of the to > above programs successfull and stable. > > Please send reactions directly to jascha@equilibrate.net. > > Kind Regards, > A.J. Hoogenraad > Equilibrate Networking Content-Description: PGP Key 0xD367DBE9. [Attachment, skipping...] [application/pgp-signature is not supported, skipping...] -- Michael Lucas | Exceptionet, Inc. | www.exceptionet.com "Exceptional Networking" | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 14 17:13:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 8705914BD2 for ; Wed, 14 Jul 1999 17:13:23 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id SAA12583; Wed, 14 Jul 1999 18:12:57 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id SAA29975; Wed, 14 Jul 1999 18:12:55 -0600 Date: Wed, 14 Jul 1999 18:12:55 -0600 Message-Id: <199907150012.SAA29975@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Jordan K. Hubbard" Cc: Brett Glass , Greg Black , Garrett Wollman , security@FreeBSD.ORG Subject: Re: Module magic In-Reply-To: <66670.931934852@zippy.cdrom.com> References: <4.2.0.58.19990713230358.044ebdb0@localhost> <66670.931934852@zippy.cdrom.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Brett, did you buy a copy of CDE for FreeBSD when it was available? I did, so I mus be one of the 3 people who bought a copy. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 14 18:30:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id 028F214EC0 for ; Wed, 14 Jul 1999 18:30:36 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.9.3/8.9.3) id UAA13849; Wed, 14 Jul 1999 20:28:02 -0500 (CDT) Date: Wed, 14 Jul 1999 20:28:02 -0500 From: "Matthew D. Fuller" To: Evren Yurtesen Cc: John Preisler , Anil Jangity , "'freebsd-security@freebsd.org '" Subject: Re: weird w report? Message-ID: <19990714202802.P28335@futuresouth.com> References: <14220.54680.327151.509940@habanero.chili-pepper.net> <378CDBC2.7EDF748C@ispro.net.tr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <378CDBC2.7EDF748C@ispro.net.tr>; from Evren Yurtesen on Wed, Jul 14, 1999 at 09:49:39PM +0300 X-OS: FreeBSD Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jul 14, 1999 at 09:49:39PM +0300, a little birdie told me that Evren Yurtesen remarked > well, how come that can happen if that user does not have a process > running? > and in my previous email I told that the same thing happened to me, > the user who was in w but had no process was myself! > and I am sure that I did not use screen command, also it is not > even installed on my system. I see bogus utmp entries from time to time. Screen seems to be the most obvious culprit, though I think ssh[d] might do something strange if a certain disconnect situation occurs. See the following program (which I've found useful for other things as well). Note the utter lack of error checking, etc. It just works. Compile as: cc -lutil -o utmprem utmprem.c Invoke as: ./utmprem For instance: ./utmprem ttypj /* * utmprem.c * Remove an entry from utmp * Compile as: * cc -lutil -Wall -o utmprem utmprem.c */ #include #include #include #include int main(int argc, char *argv[]) { argv++; if(!(logout(*argv))) err(errno, "Oops"); return(0); } -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ FutureSouth Communications | ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 14 18:39:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (Postfix) with ESMTP id 2B77114C3A for ; Wed, 14 Jul 1999 18:39:19 -0700 (PDT) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id LAA02284; Thu, 15 Jul 1999 11:38:35 +1000 (EST) From: Darren Reed Message-Id: <199907150138.LAA02284@cheops.anu.edu.au> Subject: Re: weird w report? To: fullermd@futuresouth.com (Matthew D. Fuller) Date: Thu, 15 Jul 1999 11:38:34 +1000 (EST) Cc: yurtesen@ispro.net.tr, john@vapornet.net, aj@entic.net, freebsd-security@FreeBSD.ORG In-Reply-To: <19990714202802.P28335@futuresouth.com> from "Matthew D. Fuller" at Jul 14, 99 08:28:02 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You don't need to rely on utmp for `w', or at least I've rewritten `w' that just uses process information to work. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 0:18:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from mordor.xti.org (mordor.xti.org [193.212.232.254]) by hub.freebsd.org (Postfix) with SMTP id 080811517B for ; Thu, 15 Jul 1999 00:18:06 -0700 (PDT) (envelope-from delta@xti.org) Received: (qmail 5726 invoked by alias); 15 Jul 1999 07:18:04 -0000 Received: from mordor.xti.org (193.212.232.254) by login.xti.org with SMTP; 15 Jul 1999 07:18:04 -0000 Date: Thu, 15 Jul 1999 09:18:04 +0200 (CEST) From: Terje Elde To: mwlucas@exceptionet.com Cc: jascha@equilibrate.net, security@FreeBSD.ORG Subject: Re: VPN/Secure Tunnel In-Reply-To: <199907142209.SAA17144@easeway.com> Message-ID: Question: Do you know where *your* towel is? MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 14 Jul 1999 mwlucas@exceptionet.com wrote: >If the firewall is not a NAT, use SKIP (/usr/ports/security/skip). > >Very nice, solid, and reliable, and there's even a Windows client if you >have to add others later. From what I've been told, SKIP is IPSec compatible if you do the keying manyally, is that correct? Also, any way to get SKIP to work through a NAT box? Friendly greetings, Terje Elde "One world, one web, one program" - Microsoft Promo ad. "Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitler To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 5: 0:29 1999 Delivered-To: freebsd-security@freebsd.org Received: from easeway.com (ns1.easeway.com [209.69.39.1]) by hub.freebsd.org (Postfix) with ESMTP id 99CC314C36 for ; Thu, 15 Jul 1999 05:00:26 -0700 (PDT) (envelope-from mwlucas@easeway.com) Received: (from mwlucas@localhost) by easeway.com (8.8.8/8.8.5) id HAA18635; Thu, 15 Jul 1999 07:48:02 -0400 (EDT) Message-Id: <199907151148.HAA18635@easeway.com> Subject: Re: VPN/Secure Tunnel In-Reply-To: from Terje Elde at "Jul 15, 99 09:18:04 am" To: delta@xti.org (Terje Elde) Date: Thu, 15 Jul 1999 07:48:01 -0400 (EDT) Cc: mwlucas@exceptionet.com, jascha@equilibrate.net, security@FreeBSD.ORG From: mwlucas@exceptionet.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've never tried to integrate SKIP with IPSec, so I'm not the one to talk about this. I do know that SKIP does not work behind a NAT, however. Check out www.skip.org; there's a link there for the SKIP mailing list. The NAT/SKIP issue has been beaten to death there. Good luck, ==ml > On Wed, 14 Jul 1999 mwlucas@exceptionet.com wrote: > > >If the firewall is not a NAT, use SKIP (/usr/ports/security/skip). > > > >Very nice, solid, and reliable, and there's even a Windows client if you > >have to add others later. > > >From what I've been told, SKIP is IPSec compatible if you do the keying > manyally, is that correct? Also, any way to get SKIP to work through a NAT > box? -- Michael Lucas | Exceptionet, Inc. | www.exceptionet.com "Exceptional Networking" | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 8: 5:29 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 1D74915582 for ; Thu, 15 Jul 1999 08:05:23 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id JAA22930; Thu, 15 Jul 1999 09:04:20 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA02317; Thu, 15 Jul 1999 09:04:19 -0600 Date: Thu, 15 Jul 1999 09:04:19 -0600 Message-Id: <199907151504.JAA02317@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Watson Cc: Nate Williams , freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? In-Reply-To: References: <199907091711.LAA07208@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ I'm supposed to be on vacation ;( ] > > My thinking is that we 'pre-allocate' a AUDIT_RECORD_FAILED record, and > > use it to inform the system that a record was unable to be generated. > > Therefore, you have an idea that something is missing, but you don't > > slow down the the system or cause deadlock. > > Sounds great. And the existence of such a record in the record stream > would cause an appropriate IDS module to start flailing. You got it. > > Ahh, I understand now. You are worried about one or the other of > > namei/audit copyin being redundant. I misunderstood both you and > > Garrett. Would it be possible to copy the string from the namei buffer, > > thus avoiding the issue of modifying namei? > > I haven't looked closely at the namei implementation -- at some point the > entire string is dumped into a KTRACE record by namei() Assuming we use KTRACE, which I though we decided wasn't up to the task due to many things. Given that it's not up to it, let's not rely on it doing anything, or being reliant on it. > I assume, and > that might be an appropriate place to deal with this. I don't have > bundles of source code in front of me, but I seem to recall that namei() > acts on a name lookup descriptor of some kind, perhaps allocated on the > stack for the process? It acts on a vnode, but the information may be gotten out of it. Then again, it may not be gotten out of it. :( > > > I did something like this to add speculative process execution to > > > FreeBSD/i386 a few months ago (that is, generating disk prefetch hints > > > based on speculatively executing a sandboxed process copy), and it proved > > > quite straightforward. However, I believe the architecture-dependent code > > > is what sits directly below the syscall code: we should perhaps insert > > > another architecture-independent layer that wraps the syscall, where > > > things like this can be placed. > > > > However, in the 'generic' code, it may not be obvious why the error > > occured, and this makes it more difficult to generate an audit record > > 'atomically' since the creation of the record happens in a completely > > different code-base from the 'end' of the record. We'd need to design > > some sort of even model in the audit record generation code, as well as > > pass in information in each sub-record to identify which record the > > sub-record belongs to. > > My thought was to arrange the code as follows. Currently, the FreeBSD > kernel code does something like the following: > > kern_exec.c:execve() > +------------------+ > archspecific:trap.c| | > -------------------+ +--------- > > Again, without source in front of me I'm not sure I have this exacting > right but... I am suggesting breaking out some of the syscall switch code > from occuring in the architecture-specific section. I.e., > > kern_exec.c:execve() > +------------------- > kern/kern_syscall.c| > +------------------+ > archsp| > ------+ The issue I have with this is that there is *NO* specific information you can gather at this layer (kern_syscall) that isn't already gathered by KTRACE, unless you speculatively guess at what's needed, thus causing you to end up 're-implementing' much of the code that is already in kern_exec. You only have the arguments to the syscall, but not any of the 'extended' information needed by an IDS setup. To get that information, you need to perform the same kinds of calls that execve is already doing. Why not just stick the IDS code into execve, thus avoiding re-inventing the wheel? > And the middle syscall layer would accept a struct proc and information on > the syscall request. Its responsibility would be to create an audit > record, tag it with the syscall number, pid, credentials, and any other > data consistent across syscalls that needs to be in the audit record, then > call the appropriate syscall code through the switch/sysvec array. We could do that, but what would it gain us? > On > return from the syscall, it would tag the audit record with the return > code, error condition a timestamp, and commit the audit record. But, we'd still need to instrument execve to get information such as the stat information from the inode (ownership, permissions, mount information, etc...). This information only exists inside of execve() (unless we decided to do another stat on the file in the code, which seems absolutely silly since the information already exists.) > It would then be the responsibility of the syscall code itself to > submit a list of arguments as appropriate, as well as any more > detailed subject/object information, etc. Again, since we're already instrumenting the syscall code, let's do it all there, and provide some 'generic' stubs that each syscall can do on it's own, rather than do the re-direction in the kernel. Again, I think we're in agreement on *what* needs to be done, but not on the specifics of how it needs to be done. Your way adds a level of indirection that isn't obvious. My way makes it obvious what is being done *PLUS* allows us to create a record in one fell swoop, instead of in pieces. Ex: execve() { .... #if _POSIX_AUD audit_rec ac; ac = new ac(p); ac.syscallNum = KERN_EXECVE; #endif .... #if _POSIX_AUD /* Totall bogus code */ ac.perms = vnode.perms; ac.owner = vnode.uid; ac.group = vnode.gid; #endif Hopefully you get the point. This entire record is created from start to finish inside the syscall, thus making it very obvious what information is gathered at the code level, rather than trying to run around the different parts of the kernel to figure out what is going on. > > > Similarly, auditing signal delivery would > > > need to happen the same way: currently signal deliver lives in > > > architecture-dependent-land, and we'd want the auditing wrapper to sit > > > somewhere independent of architecture, I suspect. > > > > Are signals required for IDS? (Showing my ignorance here...) > > A useful IDS module might consist of: > > Watch for a process that receives data from a network socket or local > IPC pipe and sigsegv's within two (or n) syscalls of receiving the > data. > > Or more specifically: > > Watch for a process started by inetd that receives data from a network > socket or local IPC pipe and sigsegv's within n syscalls of receiving > the data. > > Etc, etc. Gotcha. > > > As Garrett mentions, there will still be a context record from somewhere > > > that could be extended to carry an active audit record for the activities > > > of that context. Presumably that is the place to put it? > > > > How is this record 'identified' from the other records being generated > > in parallel by the other CPUs? (In other words, what identifies this > > process from other process in the above code. We're not passing the > > proc structure around....) > > Well, presumably proc p is passed into the syscall, and could be passed > elsewhere. My issue was that 'p' wasn't passed into any of your code above, so I was concerned to how it was going to be done. > Largely. The nice thing about adding the audit record creation/commital > outside of this syscall code though is that we get at least introductory > auditing on all syscalls without hassle: we know the syscall number, > information on the process, and the return value. This is essentially what KTRACE is doing today, and it's not adequate. There's no need to add 'Yet Another' auditing system on top of it, because it would buy us very little. But, it's not adequate, so let's take the time to do it Right (tm), and make it obvious what's we're doing. > We indeed both violently agree that argument auditing, etc, must happen > inside the syscall. But my temptation is to push a little of the > general-purpose work out of the syscall and into the handler. See above. I think by pushing it outside of the syscall we end up obfuscating (a little bit) of what's going on. Making these easy to understand is of prime importance to me, because the chances of it being accepted and maintained are much greater. If kernel writers think they don't have to do anything do make new syscalls work correctly in the new IDS setup, they won't. > > > See above: simple stuff in kernel may be the optimum approach, and I > > > suspect a little bit of simple goes a long way. > > > > Agreed, although a mechanism similar to BPF may allow for more 'complex' > > filtering mechanisms and still be quite effecient at the kernel. > > My concern is not that a language and programming model couldn't be > devised, but that seeking through arguments to syscalls and managing types > may be fairly costly: with packets in bpf you just look at offsets and > values, and no looping. Clearly this is something we'll need to > experiment with quite a bit: having a flexible query front end in the > user-land audit daemon could allow us to experiment with various backends > with various degrees of complexity. Agreed. This is why I don't think this is a 1.0 feature. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 8:50:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B206414E68 for ; Thu, 15 Jul 1999 08:50:19 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id LAA28994; Thu, 15 Jul 1999 11:48:47 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Thu, 15 Jul 1999 11:48:46 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Nate Williams Cc: freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? In-Reply-To: <199907151504.JAA02317@mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 15 Jul 1999, Nate Williams wrote: > [ I'm supposed to be on vacation ;( ] Then don't read your email, or at least ignore it. :-) > > > Ahh, I understand now. You are worried about one or the other of > > > namei/audit copyin being redundant. I misunderstood both you and > > > Garrett. Would it be possible to copy the string from the namei buffer, > > > thus avoiding the issue of modifying namei? > > > > I haven't looked closely at the namei implementation -- at some point the > > entire string is dumped into a KTRACE record by namei() > > Assuming we use KTRACE, which I though we decided wasn't up to the task > due to many things. Given that it's not up to it, let's not rely on it > doing anything, or being reliant on it. My point we merely that wherever KTRACE is doing it seems to be a good place to do it--we definitely want only one copyin, and it really should be the same copyin as namei() is using, to prevent races where shared memory is in use on an SMP. Otherwise two processes can deceive the auditing mechanism: p1 and p2 share a memory segment. p1 invokes chmod() with a string argument in the shared secment. The kernel, on behalf of p1, copies in the auditing record from p1. Then p2 modifies the value, followed by the kernel reading the value in again for the purposes of namei(). There are other similar nasties: you should use the same copied in value in situations like read(), as otherwise the kernel can be pursuaded to conveniently obliterate the data as a result of the syscall. I don't really have anything to prove here, except that copying in arguments is something that has to be done properly to minimize the chances of races. > > On > > return from the syscall, it would tag the audit record with the return > > code, error condition a timestamp, and commit the audit record. > > But, we'd still need to instrument execve to get information such as the > stat information from the inode (ownership, permissions, mount > information, etc...). This information only exists inside of execve() > (unless we decided to do another stat on the file in the code, which > seems absolutely silly since the information already exists.) > > > It would then be the responsibility of the syscall code itself to > > submit a list of arguments as appropriate, as well as any more > > detailed subject/object information, etc. > > Again, since we're already instrumenting the syscall code, let's do it > all there, and provide some 'generic' stubs that each syscall can do on > it's own, rather than do the re-direction in the kernel. > > Again, I think we're in agreement on *what* needs to be done, but not on > the specifics of how it needs to be done. > > Your way adds a level of indirection that isn't obvious. My way makes > it obvious what is being done *PLUS* allows us to create a record in one > fell swoop, instead of in pieces. > > Ex: > > execve() > { > .... > #if _POSIX_AUD > audit_rec ac; > > ac = new ac(p); > ac.syscallNum = KERN_EXECVE; > > #endif > .... > #if _POSIX_AUD > /* Totall bogus code */ > ac.perms = vnode.perms; > ac.owner = vnode.uid; > ac.group = vnode.gid; > #endif > > Hopefully you get the point. This entire record is created from start > to finish inside the syscall, thus making it very obvious what > information is gathered at the code level, rather than trying to run > around the different parts of the kernel to figure out what is going on. Having implemented a number of syscalls like this already, I found the experience to be quite painful: every possible exit condition from the syscall needs to have an individual commit with appropriate data, etc. This means instead of fairly nice i = copyin(...arg); if (i) return(i); ac_add_arg(ac, arg); You end up with i = copyin(...arg...); if (i) { ac.errorcode = i; ac_commit(ac); return(i); } ac_add_arg(ac, arg); If you look at most syscalls, there are lots of possible return points based on a plethora of failures: chmod will copy in a string, namei to a vnode, attempt to apply the operationg to the vnode. By the way, I think it'd possible for a syscall to return EFAULT without ever getting into the syscall code itself. It looks like syscall() in trap.c performs the copyin on arguments specified by the function prototype in syscalls.master: syscall(frame) struct trapframe frame; { caddr_t params; int i; struct sysent *callp; struct proc *p = curproc; u_quad_t sticks; int error; int args[8]; u_int code; ... if (params && (i = callp->sy_narg * sizeof(int)) && (error = copyin(params, (caddr_t)args, (u_int)i))) { #ifdef KTRACE if (KTRPOINT(p, KTR_SYSCALL)) ktrsyscall(p->p_tracep, code, callp->sy_narg, args); #endif goto bad; } #ifdef KTRACE if (KTRPOINT(p, KTR_SYSCALL)) ktrsyscall(p->p_tracep, code, callp->sy_narg, args); #endif p->p_retval[0] = 0; p->p_retval[1] = frame.tf_edx; STOPEVENT(p, S_SCE, callp->sy_narg); error = (*callp->sy_call)(p, args); switch (error) { ... This means that to audit this case, we would have to create, set up, and commit an audit record inside the syscall handling code anyway. > > We indeed both violently agree that argument auditing, etc, must happen > > inside the syscall. But my temptation is to push a little of the > > general-purpose work out of the syscall and into the handler. > > See above. I think by pushing it outside of the syscall we end up > obfuscating (a little bit) of what's going on. Making these easy to > understand is of prime importance to me, because the chances of it being > accepted and maintained are much greater. If kernel writers think they > don't have to do anything do make new syscalls work correctly in the new > IDS setup, they won't. I agree that ease of understanding is important, but I feel that retaining code simplicity for syscall implementors is also important. We get a big stepping stone towards having implemented a lot of syscall auditing just by putting in record creation and commital outside of the syscall, as we already have return codes audited, as well as credentials. I hope your vacation is going well, leaving aside my pestering :-). My plan is to not bring a notebook with my on my vacation to Maine in mid-August for this very reason. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 9: 5:58 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 3FBDE15592 for ; Thu, 15 Jul 1999 09:05:54 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id KAA23718; Thu, 15 Jul 1999 10:05:17 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA02632; Thu, 15 Jul 1999 10:05:16 -0600 Date: Thu, 15 Jul 1999 10:05:16 -0600 Message-Id: <199907151605.KAA02632@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Watson Cc: Nate Williams , freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? In-Reply-To: References: <199907151504.JAA02317@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > [ I'm supposed to be on vacation ;( ] > > Then don't read your email, or at least ignore it. :-) I did for awhile, then it started building up. :) > > > > Ahh, I understand now. You are worried about one or the other of > > > > namei/audit copyin being redundant. I misunderstood both you and > > > > Garrett. Would it be possible to copy the string from the namei buffer, > > > > thus avoiding the issue of modifying namei? > > > > > > I haven't looked closely at the namei implementation -- at some point the > > > entire string is dumped into a KTRACE record by namei() > > > > Assuming we use KTRACE, which I though we decided wasn't up to the task > > due to many things. Given that it's not up to it, let's not rely on it > > doing anything, or being reliant on it. > > My point we merely that wherever KTRACE is doing it seems to be a good > place to do it--we definitely want only one copyin, and it really should > be the same copyin as namei() is using, to prevent races where shared > memory is in use on an SMP. Otherwise two processes can deceive the > auditing mechanism: p1 and p2 share a memory segment. p1 invokes chmod() > with a string argument in the shared secment. The kernel, on behalf of > p1, copies in the auditing record from p1. Then p2 modifies the value, > followed by the kernel reading the value in again for the purposes of > namei(). This 'race' exists in SMP already, so there's nothing the kernel can do to stop it anymore than it could today. If two threads were running in parallet (and we had kernel threads implemented), these kinds of problems would have to be dealt with anyway. Where this 'safety' exists in the kernel is mostly irrelevant since the kernel will have to guarantee that the data passed in will be constant and unchanging from the time the system enters the kernel. > I don't really have anything to prove here, except that copying in > arguments is something that has to be done properly to minimize the > chances of races. My issue is that we only want to do the copyin() once (for performance reasons), and secondly to minimize core modifications as much as possible to make it more likely that the changes will be accepted, and finally to make it 'easy' to understand what it going on, to ease long-term maintanence of the code base by future developers. > > Again, since we're already instrumenting the syscall code, let's do it > > all there, and provide some 'generic' stubs that each syscall can do on > > it's own, rather than do the re-direction in the kernel. ... > > Having implemented a number of syscalls like this already, I found the > experience to be quite painful: every possible exit condition from the > syscall needs to have an individual commit with appropriate data, etc. I understand. Terry Lambert would jump in here and state that we need a single entry/exit point. However, he uses goto's all over the place to accomplish this. :( In defense of him (I'm acctually defending him), this kind of modification would make alot of things easier. Most notably, kernel threads are going to benefit from these kind of modifications in any case, so it may be necessary to add single exit points. However, that is not a change I'm willing to make (yet), at least without some support from 'those that can accept/reject kernel changes'. > I agree that ease of understanding is important, but I feel that retaining > code simplicity for syscall implementors is also important. We get a big > stepping stone towards having implemented a lot of syscall auditing just > by putting in record creation and commital outside of the syscall, as we > already have return codes audited, as well as credentials. But, we are missing alot of the necessary information that still needs to be done. And, it adds a lot of complexity to the problem, because we know need to 'build' records made up of sub-records. How many 'partially built' records can we have active at any one time (remember, kernel memory is precious)? Do we pre-allocate records? In essence, we move from a 'record gathering' system to an 'event based' system, where IDS records are created/passed on depending on the events given to them. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 9:49:52 1999 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.veriohosting.com (gatekeeper.veriohosting.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id 6CB08155DF for ; Thu, 15 Jul 1999 09:49:38 -0700 (PDT) (envelope-from hart@iserver.com) Received: by gatekeeper.veriohosting.com; Thu, 15 Jul 1999 10:48:35 -0600 (MDT) Received: from unknown(192.168.1.109) by gatekeeper.veriohosting.com via smap (V3.1.1) id xma026496; Thu, 15 Jul 99 10:48:17 -0600 Received: (hart@localhost) by anchovy.orem.iserver.com (8.9.2) id KAA19280; Thu, 15 Jul 1999 10:47:23 -0600 (MDT) Date: Thu, 15 Jul 1999 10:47:23 -0600 (MDT) From: Paul Hart X-Sender: hart@anchovy.orem.iserver.com To: freebsd-security@freebsd.org Subject: OpenBSD's strlcpy(3) and strlcat(3) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I was just reviewing the proceedings from the USENIX 1999 Annual Technical Conference where Todd Miller and Theo de Raadt presented a paper on two new functions that OpenBSD has integrated into libc. The new functions, strlcpy(3) and strlcat(3), are intended to provide an easily understood means of safe string copying and concatenation to programmers. Of course, strcpy(3) and strcat(3) have obvious dangers, but their standardized intended replacements, strncpy(3) and strncat(3), suffer from some subtle dangers as well that can trip up even experienced programmers. I was impressed by the paper and wondered if anyone besides myself would be amenable to including them in FreeBSD's libc. Are there members of the FreeBSD core and community that would be interested in importing these new functions? The semantics of strncpy(3) and strncat(3) have struck me as warts on the C standard for some time. I'm not sure what debate took place on the standardization committee, but whatever it was seems to have produced some strange results. If you are a USENIX member you can access the text of the paper at: http://www.usenix.org/events/usenix99/millert.html Paul Hart -- Paul Robert Hart ><8> ><8> ><8> Verio Web Hosting, Inc. hart@iserver.com ><8> ><8> ><8> http://www.iserver.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 9:57:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id F2C141567F for ; Thu, 15 Jul 1999 09:57:16 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA11249; Thu, 15 Jul 1999 09:57:13 -0700 (PDT) (envelope-from dillon) Date: Thu, 15 Jul 1999 09:57:13 -0700 (PDT) From: Matthew Dillon Message-Id: <199907151657.JAA11249@apollo.backplane.com> To: Paul Hart Cc: freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :I was just reviewing the proceedings from the USENIX 1999 Annual Technical :Conference where Todd Miller and Theo de Raadt presented a paper on two :new functions that OpenBSD has integrated into libc. The new functions, :strlcpy(3) and strlcat(3), are intended to provide an easily understood :... :I was impressed by the paper and wondered if anyone besides myself would :be amenable to including them in FreeBSD's libc. Are there members of the :FreeBSD core and community that would be interested in importing these new :functions? The semantics of strncpy(3) and strncat(3) have struck me as :warts on the C standard for some time. I'm not sure what debate took :... : :If you are a USENIX member you can access the text of the paper at: : : http://www.usenix.org/events/usenix99/millert.html : :Paul Hart :Paul Robert Hart ><8> ><8> ><8> Verio Web Hosting, Inc. I was quite impressed with that paper too and would love to see the functions added to libc. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 10:10:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 73D3D155AA for ; Thu, 15 Jul 1999 10:10:30 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id NAA12942; Thu, 15 Jul 1999 13:08:58 -0400 (EDT) (envelope-from wollman) Date: Thu, 15 Jul 1999 13:08:58 -0400 (EDT) From: Garrett Wollman Message-Id: <199907151708.NAA12942@khavrinen.lcs.mit.edu> To: Paul Hart Cc: freebsd-security@FreeBSD.ORG Subject: OpenBSD's strlcpy(3) and strlcat(3) In-Reply-To: References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > The semantics of strncpy(3) and strncat(3) have struck me as warts > on the C standard for some time. I'm not sure what debate took > place on the standardization committee, but whatever it was seems to > have produced some strange results. These functions were not creations of the committee -- they have been in C for a very long time. They (along with strncmp()) were originally created for the purpose of dealing with `struct direct' in Seventh Edition, which looked something like this (I've probably got the member names wrong): struct direct { int d_ino; char d_name[MAXNAMLEN]; }; The `d_name' member defined the semantics of strncpy() and strncmp(). X3J11 standardized these functions as they were. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 10:11:45 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id E474414D9E for ; Thu, 15 Jul 1999 10:11:37 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id LAA08597; Thu, 15 Jul 1999 11:11:29 -0600 (MDT) Message-Id: <4.2.0.58.19990715110902.044e7cc0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 15 Jul 1999 11:11:22 -0600 To: Paul Hart , freebsd-security@FreeBSD.ORG From: Brett Glass Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org When I met him at Def Con, Mike Smith pooh-poohed Theo's presentation. I've looked it over on my own, however, and think that Theo has some good points. In particular, the notion that one should be able to detect and react to unexpected truncation of a string is a good one. I'd like to see these functions in FreeBSD's standard libraries, and to see them used in FreeBSD's kernel and userland. --Brett At 10:47 AM 7/15/99 -0600, Paul Hart wrote: >I was just reviewing the proceedings from the USENIX 1999 Annual Technical >Conference where Todd Miller and Theo de Raadt presented a paper on two >new functions that OpenBSD has integrated into libc. The new functions, >strlcpy(3) and strlcat(3), are intended to provide an easily understood >means of safe string copying and concatenation to programmers. Of course, >strcpy(3) and strcat(3) have obvious dangers, but their standardized >intended replacements, strncpy(3) and strncat(3), suffer from some subtle >dangers as well that can trip up even experienced programmers. > >I was impressed by the paper and wondered if anyone besides myself would >be amenable to including them in FreeBSD's libc. Are there members of the >FreeBSD core and community that would be interested in importing these new >functions? The semantics of strncpy(3) and strncat(3) have struck me as >warts on the C standard for some time. I'm not sure what debate took >place on the standardization committee, but whatever it was seems to have >produced some strange results. > >If you are a USENIX member you can access the text of the paper at: > > http://www.usenix.org/events/usenix99/millert.html > >Paul Hart > >-- >Paul Robert Hart ><8> ><8> ><8> Verio Web Hosting, Inc. >hart@iserver.com ><8> ><8> ><8> http://www.iserver.com/ > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 10:26: 9 1999 Delivered-To: freebsd-security@freebsd.org Received: from atlas.cc.uregina.ca (ATLAS.CC.UREGINA.CA [142.3.100.254]) by hub.freebsd.org (Postfix) with ESMTP id 0BFA114D9E for ; Thu, 15 Jul 1999 10:25:59 -0700 (PDT) (envelope-from galbraik@uregina.ca) Received: from hyperion.cc.uregina.ca (HYPERION.CC.UREGINA.CA [142.3.100.33]) by atlas.cc.uregina.ca (8.9.1/8.9.1) with ESMTP id LAA01456 for ; Thu, 15 Jul 1999 11:25:55 -0600 (CST) Received: from uregina.ca ([142.3.217.83]) by hyperion.cc.uregina.ca (8.9.1/8.9.1) with ESMTP id LAA10917 for ; Thu, 15 Jul 1999 11:25:55 -0600 (CST) Message-ID: <378E1C51.B88C99A3@uregina.ca> Date: Thu, 15 Jul 1999 11:37:21 -0600 From: Kristopher Galbraith Organization: University of Regina X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: Fw: Skip configuration References: <002101be7742$400997f0$23b197ce@ezo.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Perhaps this isn't a security related question, but I still have to ask it: My question is whether I could build an ATM packet switch (or an ATM router) with FreeBSD? If so where is a good source of information for setup/maintenance/upgrade the switch, and what hardware should I use? I don't think physical layer is too important; I am hoping to run ATM over either 10BaseX or the like. -- Kristopher Galbraith Technician, Computing Services, University of Regina To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 12:59:10 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 8356E155E8 for ; Thu, 15 Jul 1999 12:59:08 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id NAA10161 for ; Thu, 15 Jul 1999 13:58:47 -0600 (MDT) Message-Id: <4.2.0.58.19990715134215.04612ec0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 15 Jul 1999 13:48:53 -0600 To: freebsd-security@FreeBSD.ORG From: Brett Glass Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-Reply-To: <4.2.0.58.19990715110902.044e7cc0@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org By the way, in case anyone wants to see the paper and/or the slides from the talk, they're on the OpenBSD site. Paper: http://www.openbsd.org/papers/strlcpy-paper.ps Slides (worth looking at too): http://www.openbsd.org/papers/strlcpy-slides.ps The USENIX site (mentioned in an earlier message) denies access to the full text of the paper unless you're a member. But the URLs I've listed above are available to anyone with a PostScript viewer. Again, I think the paper makes some great points, and can't understand why Mike was so negative about the paper or the adoption of these functions. They appear to be both faster AND safer than what's commonly used now. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 14:15:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from mirage.nlink.com.br (mirage.nlink.com.br [200.249.195.3]) by hub.freebsd.org (Postfix) with ESMTP id 56AE714D3E for ; Thu, 15 Jul 1999 14:15:31 -0700 (PDT) (envelope-from paulo@nlink.com.br) Received: from localhost (paulo@localhost) by mirage.nlink.com.br (8.9.3/8.9.1) with SMTP id SAA08793 for ; Thu, 15 Jul 1999 18:15:28 -0300 (EST) Date: Thu, 15 Jul 1999 18:15:28 -0300 (EST) From: Paulo Fragoso To: freebsd-security@freebsd.org Subject: FreeBSD exploit? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Has anyone ever read this article: http://www.securityfocus.com/level2/bottom.html?go=vulnerabilities&id=526 all version of freebsd has this problem!!! Paulo. ------ " ... Overall we've found FreeBSD to excel in performace, stability, technical support, and of course price. Two years after discovering FreeBSD, we have yet to find a reason why we switch to anything else" -David Filo, Yahoo! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 14:27:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from magnesium.net (toxic.magnesium.net [204.188.6.238]) by hub.freebsd.org (Postfix) with SMTP id 4420E14D3E for ; Thu, 15 Jul 1999 14:27:24 -0700 (PDT) (envelope-from unfurl@magnesium.net) Received: (qmail 23781 invoked by uid 1001); 15 Jul 1999 21:27:24 -0000 Date: 15 Jul 1999 14:27:24 -0700 Date: Thu, 15 Jul 1999 14:27:24 -0700 From: Bill Swingle To: Paulo Fragoso Cc: freebsd-security@freebsd.org Subject: Re: FreeBSD exploit? Message-ID: <19990715142724.A23752@dub.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Paulo Fragoso on Thu, Jul 15, 1999 at 06:15:28PM -0300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jul 15, 1999 at 06:15:28PM -0300, Paulo Fragoso wrote: > Hi, > > Has anyone ever read this article: > > http://www.securityfocus.com/level2/bottom.html?go=vulnerabilities&id=526 > > all version of freebsd has this problem!!! > > Paulo. Before starting the hype-engine please use the correct term. It is a _Denial of Service_ attack, not an exploit. No one is going to get root with this program. -Bill -- -=| Bill Swingle - unfurl@dub.net - unfurl@freebsd.org - bill@cdrom.com -=| "Computers are useless. They can only give you answers" Pablo Picasso To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 14:33:37 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 8B1A8155BA for ; Thu, 15 Jul 1999 14:33:31 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id RAA10722; Thu, 15 Jul 1999 17:33:29 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: Date: Thu, 15 Jul 1999 17:33:29 -0400 To: Paul Hart , freebsd-security@FreeBSD.ORG From: Garance A Drosihn Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 10:47 AM -0600 7/15/99, Paul Hart wrote: > ... Todd Miller and Theo de Raadt presented a paper on two new > functions that OpenBSD has integrated into libc. The new functions, > strlcpy(3) and strlcat(3), are intended to provide an easily understood > means of safe string copying and concatenation to programmers. > > I was impressed by the paper and wondered if anyone besides myself would > be amenable to including them in FreeBSD's libc. Seems to me they would be good to have, seeing that some other platforms have started using them. I've been meaning to address the same issues via a slightly different set of routines, but given that my routines are not written yet I'll have to admit these have a significant advantage. :-) What I wanted to do was have "estr" routines, where the destination is specified as the starting point and the ending point of the area available for the string (as two parameters). The routines would return the position of the current string-terminator. So you could do things like: eos = estrcpy(dest, endp, src1); eos = estrcat(eos, endp, src2); eos = estrcat(eos, endp, src3); and you could check for "string is full" by comparing 'eos' (the return value) to 'endp' (which you'd already have). Strictly speaking that won't work quite right in some cases, so the strlcpy routines also have an advantage there. My idea was that estrcpy and estrcat could be written to be pretty fast. If you were doing a lot of concatinations, for instance, the above could end up FASTER than using regular strcpy and strcat (never mind strncpy and strncat). You could also have 'estrncpy' and 'estrncat' if you wanted. In fact, I also wanted to have estrcat2 and estrcat3, which allowed for two/three source strings, so one could write: if (ptr != NULL) eos = estrcat2(eos, endp, ", ", ptr); or if (ptr != NULL) eos = estrcat3(eos, endp, " ", ptr, ","); > The semantics of strncpy(3) and strncat(3) have struck me as warts > on the C standard for some time. I'm not sure what debate took > place on the standardization committee, but whatever it was seems > to have produced some strange results. Seems to me that they are fine routines, it's just that everyone is now using them for something that they were never designed for. [also, we probably should discuss this in some wider audience than freebsd-security, perhaps freebsd-hackers?] --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 14:55:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id CDE7B15013 for ; Thu, 15 Jul 1999 14:55:43 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id PAA11213; Thu, 15 Jul 1999 15:53:07 -0600 (MDT) Message-Id: <4.2.0.58.19990715154344.00cc5db0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 15 Jul 1999 15:46:43 -0600 To: Bill Swingle , Paulo Fragoso From: Brett Glass Subject: Re: FreeBSD exploit? Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <19990715142724.A23752@dub.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 02:27 PM 7/15/99 -0700, Bill Swingle wrote: >Before starting the hype-engine please use the correct term. It is a >_Denial of Service_ attack, not an exploit. The term "exploit" is a broad one; it covers both denial of service attacks and attacks that grant supervisor privileges to a local or remote user. >No one is going to get root >with this program. Actually, under Linux, they might. I understand that in some versions of Red Hat, forcing a reboot at the wrong moment during installation leaves the system open to a remote takeover. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 15:16:22 1999 Delivered-To: freebsd-security@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 70AF01563B for ; Thu, 15 Jul 1999 15:16:15 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 114tnV-000KgU-00 for freebsd-security@freebsd.org; Fri, 16 Jul 1999 00:16:09 +0200 From: Sheldon Hearn To: Garance A Drosihn Cc: Paul Hart , freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-reply-to: Your message of "Thu, 15 Jul 1999 17:33:29 -0400." Date: Fri, 16 Jul 1999 00:15:31 +0200 Message-ID: <79492.932076931@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Hijacked from freebsd-security] On Thu, 15 Jul 1999 17:33:29 -0400, Garance A Drosihn wrote: > What I wanted to do was have "estr" routines, where the destination > is specified as the starting point and the ending point of the area > available for the string (as two parameters). The routines would > return the position of the current string-terminator. So you could > do things like: As I understand it, the goal here is to return to the caller the number of bytes copied (however you represent it), so that the caller can easily determine whether or not dst is safe for operations demanding a null-terminated string. If that is true, then I think the interface you propose is overly complex. Looking at the existing functions, their only flaw is that they return known (and therefore useless) information, "wasting" the return value. All we need is: size_t foocpy(char *dst, const char *src) size_t fooncpy(char *dst, const char *src, size_t len) size_t foocat(char *s, const char *append) size_t fooncat(char *s, const char *append, size_t count) where the return value is the number of bytes {copied,appended}. Since the goal is simply to make it easier to do what is already possible, I think that this approach is better than what you're suggesting, since the pointer arithmetic required in the caller is simpler. And since the prototypes for fooncpy and fooncat above match exactly those of the proposed strlcpy and strlcat respectively (just had a look before I "hit the send button"), I'd say that the latter two are definitely the functions you want. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 15:53:48 1999 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id B8EF5155E8 for ; Thu, 15 Jul 1999 15:53:46 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA13514; Thu, 15 Jul 1999 15:53:11 -0700 (PDT) (envelope-from dillon) Date: Thu, 15 Jul 1999 15:53:11 -0700 (PDT) From: Matthew Dillon Message-Id: <199907152253.PAA13514@apollo.backplane.com> To: Paulo Fragoso Cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD exploit? References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :Hi, : :Has anyone ever read this article: : :http://www.securityfocus.com/level2/bottom.html?go=vulnerabilities&id=526 : :all version of freebsd has this problem!!! : :Paulo. Yes, but it isn't an exploit, it's a denial of service attack ( and there is a difference ). Yes, it appears to be a real bug. I can set my datasize limit to 16m and then mmap() a 64m file MAP_PRIVATE and touch all the pages without getting a fault. We could conceivably fix it by adding a new resource limit to the system for privately mmap'd space. But I think, ultimately, the only way to fix it would be to add a per-user VM quota resource that accounts for it properly. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 16:20:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id BA87314EAE for ; Thu, 15 Jul 1999 16:20:14 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id RAA29504; Thu, 15 Jul 1999 17:19:05 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id RAA73667; Thu, 15 Jul 1999 17:19:05 -0600 (MDT) Message-Id: <199907152319.RAA73667@harmony.village.org> To: Paul Hart Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Jul 1999 10:47:23 MDT." References: Date: Thu, 15 Jul 1999 17:19:05 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I *STRONGLY* support adding strl routines to FreeBSD's libc. I've had them in my local library for a long time, but haven't had the time to commit them. Solaris is also adding them. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 16:21:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 0401414FF8 for ; Thu, 15 Jul 1999 16:21:37 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id RAA29511; Thu, 15 Jul 1999 17:20:57 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id RAA73691; Thu, 15 Jul 1999 17:20:57 -0600 (MDT) Message-Id: <199907152320.RAA73691@harmony.village.org> To: Garance A Drosihn Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: Paul Hart , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Jul 1999 17:33:29 EDT." References: Date: Thu, 15 Jul 1999 17:20:57 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Garance A Drosihn writes: : What I wanted to do was have "estr" routines, where the destination : is specified as the starting point and the ending point of the area : available for the string (as two parameters). The routines would : return the position of the current string-terminator. So you could : do things like: : eos = estrcpy(dest, endp, src1); : eos = estrcat(eos, endp, src2); : eos = estrcat(eos, endp, src3); : and you could check for "string is full" by comparing 'eos' (the : return value) to 'endp' (which you'd already have). Strictly : speaking that won't work quite right in some cases, so the strlcpy : routines also have an advantage there. Yes. It would take a lot of talking and convincing to get me to support adding something other than strl* routines. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 16:28: 7 1999 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 09C9C15653 for ; Thu, 15 Jul 1999 16:28:01 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA13727; Thu, 15 Jul 1999 16:26:42 -0700 (PDT) (envelope-from dillon) Date: Thu, 15 Jul 1999 16:26:42 -0700 (PDT) From: Matthew Dillon Message-Id: <199907152326.QAA13727@apollo.backplane.com> To: Warner Losh Cc: Paul Hart , freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) References: <199907152319.RAA73667@harmony.village.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :I *STRONGLY* support adding strl routines to FreeBSD's libc. I've had :them in my local library for a long time, but haven't had the time to :commit them. : :Solaris is also adding them. : :Warner I'd say go for it. I would sure use them! -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 16:40: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 03A0D15636 for ; Thu, 15 Jul 1999 16:39:54 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 114v56-000Kwt-00; Fri, 16 Jul 1999 01:38:24 +0200 From: Sheldon Hearn To: Warner Losh Cc: Paul Hart , freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-reply-to: Your message of "Thu, 15 Jul 1999 17:19:05 CST." <199907152319.RAA73667@harmony.village.org> Date: Fri, 16 Jul 1999 01:38:24 +0200 Message-ID: <80530.932081904@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 15 Jul 1999 17:19:05 CST, Warner Losh wrote: > I *STRONGLY* support adding strl routines to FreeBSD's libc. I've had > them in my local library for a long time, but haven't had the time to > commit them. What do you think of this? " size_t strlcpy(char *dst, char *src, size_t len [, shortfall]); size_t strlcat(char *dst, char *src, size_t len [, shortfall]); [...] RETURN VALUES If the optional shortfall argument is passed non-zero, the functions return the number of characters from src that are missing in dst after the operation. Otherwise, they return the length of dst. In either case, the return value does not include the NUL terminator. " This way, we get compatibility with the other vendors who've chosen to implement the functions, but we also get the cheaper option Tim wants. It'd be up to the other vendors to choose to implement the extension. I'll come up with a commit candidate in the next 48 hours and post a URL, including a manpage replacement. The OpenBSD manpage for these functions includes in DESCRIPTION too much that should be in HISTORY (and perhaps IMPLEMENTATION NOTES). The only thing I can think of that would make this extension a bad idea is va_alist processing cost. Is it significant? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 16:47:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 0773E14D66 for ; Thu, 15 Jul 1999 16:47:35 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id RAA12279; Thu, 15 Jul 1999 17:47:06 -0600 (MDT) Message-Id: <4.2.0.58.19990715174241.045f0550@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 15 Jul 1999 17:47:03 -0600 To: Sheldon Hearn , Warner Losh From: Brett Glass Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: Paul Hart , freebsd-security@FreeBSD.ORG In-Reply-To: <80530.932081904@axl.noc.iafrica.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org How about returning the shortfall as the return value of the function? This would allow the programmer to wrap an "if" right around the function call and handle the error easily if the string was truncated. Making a check convenient would encourage programmers to insert it into their code. Having to write a separate test would actually discourage this practice and could lead to malfunctioning code. --Brett At 01:38 AM 7/16/99 +0200, Sheldon Hearn wrote: >On Thu, 15 Jul 1999 17:19:05 CST, Warner Losh wrote: > > > I *STRONGLY* support adding strl routines to FreeBSD's libc. I've had > > them in my local library for a long time, but haven't had the time to > > commit them. > >What do you think of this? > >" >size_t >strlcpy(char *dst, char *src, size_t len [, shortfall]); > >size_t >strlcat(char *dst, char *src, size_t len [, shortfall]); > >[...] > >RETURN VALUES > >If the optional shortfall argument is passed non-zero, the functions >return the number of characters from src that are missing in dst after >the operation. Otherwise, they return the length of dst. In either case, >the return value does not include the NUL terminator. >" > >This way, we get compatibility with the other vendors who've chosen to >implement the functions, but we also get the cheaper option Tim wants. >It'd be up to the other vendors to choose to implement the extension. > >I'll come up with a commit candidate in the next 48 hours and post a >URL, including a manpage replacement. The OpenBSD manpage for these >functions includes in DESCRIPTION too much that should be in HISTORY >(and perhaps IMPLEMENTATION NOTES). > >The only thing I can think of that would make this extension a bad idea >is va_alist processing cost. Is it significant? > >Ciao, >Sheldon. > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 16:53:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 9F48B14CB7 for ; Thu, 15 Jul 1999 16:53:22 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 114vJ3-000L13-00; Fri, 16 Jul 1999 01:52:49 +0200 From: Sheldon Hearn To: Brett Glass Cc: Warner Losh , Paul Hart , freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-reply-to: Your message of "Thu, 15 Jul 1999 17:47:03 CST." <4.2.0.58.19990715174241.045f0550@localhost> Date: Fri, 16 Jul 1999 01:52:49 +0200 Message-ID: <80788.932082769@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 15 Jul 1999 17:47:03 CST, Brett Glass wrote: > How about returning the shortfall as the return value of the function? Um, hello? That's exactly what I'm proposing: > >RETURN VALUES > > > >If the optional shortfall argument is passed non-zero, the functions > >return the number of characters from src that are missing in dst after > >the operation. Otherwise, they return the length of dst. In either case, > >the return value does not include the NUL terminator. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 17: 7:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id B74041562C for ; Thu, 15 Jul 1999 17:07:51 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id SAA12436; Thu, 15 Jul 1999 18:06:44 -0600 (MDT) Message-Id: <4.2.0.58.19990715180119.04723d20@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 15 Jul 1999 18:05:06 -0600 To: Sheldon Hearn From: Brett Glass Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: Warner Losh , Paul Hart , freebsd-security@FreeBSD.ORG In-Reply-To: <80788.932082769@axl.noc.iafrica.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The danger here is that the semantics are changed so radically by the value of the argument. This is an invitation to confusion. A more consistent way to do it would be to have the function return zero if the programmer opted not to know about any shortfall. Or, even better, ALWAYS return the shortfall. The programmer can then discard the return value if he's really willing to ignore it (perhaps at his peril). --Brett At 01:52 AM 7/16/99 +0200, Sheldon Hearn wrote: >On Thu, 15 Jul 1999 17:47:03 CST, Brett Glass wrote: > > > How about returning the shortfall as the return value of the function? > >Um, hello? That's exactly what I'm proposing: > > > >RETURN VALUES > > > > > >If the optional shortfall argument is passed non-zero, the functions > > >return the number of characters from src that are missing in dst after > > >the operation. Otherwise, they return the length of dst. In either case, > > >the return value does not include the NUL terminator. > >:-) > >Ciao, >Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 17:13:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id BDF8F15689 for ; Thu, 15 Jul 1999 17:13:36 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 114vcB-000L9G-00; Fri, 16 Jul 1999 02:12:35 +0200 From: Sheldon Hearn To: Brett Glass Cc: Warner Losh , Paul Hart , freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-reply-to: Your message of "Thu, 15 Jul 1999 18:05:06 CST." <4.2.0.58.19990715180119.04723d20@localhost> Date: Fri, 16 Jul 1999 02:12:35 +0200 Message-ID: <81297.932083955@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 15 Jul 1999 18:05:06 CST, Brett Glass wrote: > A more consistent way to do it would be to have the function return zero > if the programmer opted not to know about any shortfall. That'd break code that doesn't expect to have to pass the additional argument that we've opted to allow for. > Or, even better, ALWAYS return the shortfall. The programmer can then > discard the return value if he's really willing to ignore it (perhaps > at his peril). Reality check: we're talking about portability here. If we take these functions into our own libc, we really should make them work as expected on other platforms. However, there's nothing to stop us extending them beyond those expectations. What I'm getting at here is that, while the strl* functions may be nice (and Mike Smith's arguments are casting some serious doubt over that idea) they could certainly be nicer. At least two other vendors already have a defined API for the functions. If we use them, we shouldn't break that API. What I propose doesn't, put it does allow for more convenient use of the functions. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 17:15: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id D28CF15676 for ; Thu, 15 Jul 1999 17:14:24 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id SAA29653; Thu, 15 Jul 1999 18:13:38 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA00978; Thu, 15 Jul 1999 18:13:37 -0600 (MDT) Message-Id: <199907160013.SAA00978@harmony.village.org> To: Sheldon Hearn Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: Paul Hart , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Fri, 16 Jul 1999 01:38:24 +0200." <80530.932081904@axl.noc.iafrica.com> References: <80530.932081904@axl.noc.iafrica.com> Date: Thu, 15 Jul 1999 18:13:37 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <80530.932081904@axl.noc.iafrica.com> Sheldon Hearn writes: : If the optional shortfall argument is passed non-zero, the functions Impossible to implement, gratuitously incompatible with OpenBSD. I'd say no. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 17:17: 7 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 76E38156EA for ; Thu, 15 Jul 1999 17:16:59 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id SAA29669; Thu, 15 Jul 1999 18:16:15 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA01040; Thu, 15 Jul 1999 18:16:15 -0600 (MDT) Message-Id: <199907160016.SAA01040@harmony.village.org> To: Brett Glass Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: Sheldon Hearn , Paul Hart , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Jul 1999 18:05:06 MDT." <4.2.0.58.19990715180119.04723d20@localhost> References: <4.2.0.58.19990715180119.04723d20@localhost> Date: Thu, 15 Jul 1999 18:16:15 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.0.58.19990715180119.04723d20@localhost> Brett Glass writes: : Or, even better, ALWAYS return the shortfall. The programmer can then discard : the return value if he's really willing to ignore it (perhaps at his peril). That's what strl* are defined to do. They always return the length of the string that would have resulted, had it not been truncated. That way it can either be used or ignored as the programmer sees fit. I don't see much value in computing return-value - size as another, incompatible argument. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 17:17:11 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id E5EA4156ED for ; Thu, 15 Jul 1999 17:17:02 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id UAA39204; Thu, 15 Jul 1999 20:16:11 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <80530.932081904@axl.noc.iafrica.com> References: Your message of "Thu, 15 Jul 1999 17:19:05 CST." <199907152319.RAA73667@harmony.village.org> Date: Thu, 15 Jul 1999 20:16:09 -0400 To: Sheldon Hearn , Warner Losh From: Garance A Drosihn Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: Paul Hart , freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 1:38 AM +0200 7/16/99, Sheldon Hearn wrote: >On Thu, 15 Jul 1999 17:19:05 CST, Warner Losh wrote: > >> I *STRONGLY* support adding strl routines to FreeBSD's libc. >> I've had them in my local library for a long time, but haven't >> had the time to commit them. > > What do you think of this? > >" >size_t >strlcpy(char *dst, char *src, size_t len [, shortfall]); > >size_t >strlcat(char *dst, char *src, size_t len [, shortfall]); > >[...] I like the idea of strl* routines, but I think we should just add them the way they'll be implemented everywhere else. If everyone else (openbsd, solaris, etc) likes the above idea then I'm certainly all for it. If they don't, then I see no benefit in making slightly different routines for freebsd. If I'm writing code, I'm writing it for more than one platform. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 17:17:52 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 60B9C15724 for ; Thu, 15 Jul 1999 17:17:47 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id SAA29682; Thu, 15 Jul 1999 18:17:46 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA01078; Thu, 15 Jul 1999 18:17:45 -0600 (MDT) Message-Id: <199907160017.SAA01078@harmony.village.org> To: Sheldon Hearn Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: Brett Glass , Paul Hart , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Fri, 16 Jul 1999 02:12:35 +0200." <81297.932083955@axl.noc.iafrica.com> References: <81297.932083955@axl.noc.iafrica.com> Date: Thu, 15 Jul 1999 18:17:45 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <81297.932083955@axl.noc.iafrica.com> Sheldon Hearn writes: : Reality check: we're talking about portability here. If we take these : functions into our own libc, we really should make them work as expected : on other platforms. However, there's nothing to stop us extending them : beyond those expectations. No. They will be 100% compatible, or not imported. No extensions that could bite people when porting *TO* OpenBSD. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 17:26:17 1999 Delivered-To: freebsd-security@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 6ECC21579A for ; Thu, 15 Jul 1999 17:26:05 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 114voS-000LCj-00; Fri, 16 Jul 1999 02:25:16 +0200 From: Sheldon Hearn To: Warner Losh Cc: Brett Glass , Paul Hart , freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-reply-to: Your message of "Thu, 15 Jul 1999 18:17:45 CST." <199907160017.SAA01078@harmony.village.org> Date: Fri, 16 Jul 1999 02:25:16 +0200 Message-ID: <81512.932084716@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 15 Jul 1999 18:17:45 CST, Warner Losh wrote: > No. They will be 100% compatible, or not imported. No extensions > that could bite people when porting *TO* OpenBSD. Ah yes. The gotcha. :-) Cool, so now I face that icky sticky problem of "who first". Rather than hoping that an implementation of an extension will be backported to the platform of origin, I need to contact the vendor of that platform. I can see where that'll get me, but it's worth a shot. Nonetheless, your call is definitely the decisive blow to the idea. I shoulda thought of it myself. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 17:43:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id E1CA615653 for ; Thu, 15 Jul 1999 17:43:32 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id RAA03807; Thu, 15 Jul 1999 17:41:35 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Sheldon Hearn Cc: Warner Losh , Brett Glass , Paul Hart , freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-reply-to: Your message of "Fri, 16 Jul 1999 02:25:16 +0200." <81512.932084716@axl.noc.iafrica.com> Date: Thu, 15 Jul 1999 17:41:35 -0700 Message-ID: <3803.932085695@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Cool, so now I face that icky sticky problem of "who first". Rather than > hoping that an implementation of an extension will be backported to the > platform of origin, I need to contact the vendor of that platform. Naw, I think this is REALLY SIMPLE and very definitely unworth the length of this thread so far. Not that "proper defensive coding" is an unworthy topic in its own right, and perhaps we should all have that discussion again some time, but it's not immediately germin to the issue of whether or not to bring the OpenBSD strlcpy()/strlcat() routines in. I'd say that's a decision made on simple compatibility grounds and if X or more sister OSen have already adopted them into their libc, where X is a positive integer greater than or equal to 2, then it's a foregone conclusion that apps writers will begin using them and we should provide compatibility. Unvarnished, uncomplicated, just a 100% compatible implementation with the standard that OpenBSD has already set. Now if other security mavens have their own ideas about a much better family of additions to libc which promote even better and secure programming practices, by all means knock yourselves out in producing this family of routines and maybe even someday the man pages for these first OpenBSD efforts can bear the "SUPERSEDED BY" tag. :-) Until then, let's kindly not debate this particular bike shelter into the ground. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 18:48:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 6F9EB15641 for ; Thu, 15 Jul 1999 18:48:55 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id TAA13199; Thu, 15 Jul 1999 19:48:31 -0600 (MDT) Message-Id: <4.2.0.58.19990715194032.045ee340@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 15 Jul 1999 19:48:31 -0600 To: Sheldon Hearn From: Brett Glass Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: Warner Losh , Paul Hart , freebsd-security@FreeBSD.ORG In-Reply-To: <81297.932083955@axl.noc.iafrica.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 02:12 AM 7/16/99 +0200, Sheldon Hearn wrote: >That'd break code that doesn't expect to have to pass the additional >argument that we've opted to allow for. Well, at this point, it's early enough to specify the function so that no such code is written. > > Or, even better, ALWAYS return the shortfall. The programmer can then > > discard the return value if he's really willing to ignore it (perhaps > > at his peril). > >Reality check: we're talking about portability here. That's why this is the time to set the standard sensibly -- before Solaris and other standard bearers have decided one way or the other. >If we take these >functions into our own libc, we really should make them work as expected >on other platforms. Right now, there's only one other platform doing it: OpenBSD. And it's still early enough to make OpenBSD consistent if there are strong arguments for the approach that is taken. >What I'm getting at here is that, while the strl* functions may be nice >(and Mike Smith's arguments are casting some serious doubt over that >idea) What arguments? (They must be on some list to which I'm not subscribed.) However, based on what Mike said to be at Def Con, I'm concerned that Mike's arguments might arise from a personality conflict with Theo. >they could certainly be nicer. At least two other vendors already >have a defined API for the functions. If we use them, we shouldn't break >that API. What I propose doesn't, put it does allow for more convenient >use of the functions. Alas, the approach you've taken makes the functions slower (You have to check an argument that's going to be a constant in all cases -- why not just provide two separate functions?), bigger (you have to check the number of arguments AND the value of the extra one), and semantically confusing (the meaning of the return value is influenced both by the presence and the value of an argument). I would not take the approach you've mentioned for this reason. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 18:53:43 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 59E83150B5 for ; Thu, 15 Jul 1999 18:53:41 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id TAA13242; Thu, 15 Jul 1999 19:53:03 -0600 (MDT) Message-Id: <4.2.0.58.19990715194914.045ee7d0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 15 Jul 1999 19:53:04 -0600 To: Warner Losh From: Brett Glass Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: Sheldon Hearn , Paul Hart , freebsd-security@FreeBSD.ORG In-Reply-To: <199907160016.SAA01040@harmony.village.org> References: <4.2.0.58.19990715180119.04723d20@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I agree with you. What I was suggesting, though, is that the SHORTFALL be the return value. Why? Because it facilitates a conditional test for truncation. If the return value is the number of bytes copied, one must do additional arithmetic to test for an error. Since OpenBSD is the only platform currently integrating the functions, there's time to work with them to make this the standard if we'd like. --Brett At 06:16 PM 7/15/99 -0600, Warner Losh wrote: >In message <4.2.0.58.19990715180119.04723d20@localhost> Brett Glass writes: >: Or, even better, ALWAYS return the shortfall. The programmer can then discard >: the return value if he's really willing to ignore it (perhaps at his peril). > >That's what strl* are defined to do. They always return the length of >the string that would have resulted, had it not been truncated. That >way it can either be used or ignored as the programmer sees fit. I >don't see much value in computing return-value - size as another, >incompatible argument. > >Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 18:58:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 54D6214E44 for ; Thu, 15 Jul 1999 18:58:45 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id TAA29974; Thu, 15 Jul 1999 19:56:45 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id TAA61822; Thu, 15 Jul 1999 19:56:45 -0600 (MDT) Message-Id: <199907160156.TAA61822@harmony.village.org> To: Brett Glass Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: Sheldon Hearn , Paul Hart , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Jul 1999 19:53:04 MDT." <4.2.0.58.19990715194914.045ee7d0@localhost> References: <4.2.0.58.19990715194914.045ee7d0@localhost> <4.2.0.58.19990715180119.04723d20@localhost> Date: Thu, 15 Jul 1999 19:56:44 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.0.58.19990715194914.045ee7d0@localhost> Brett Glass writes: : Since OpenBSD is the only platform currently integrating the functions, : there's time to work with them to make this the standard if we'd like. Too late. Linux (glibc I'm told) and Solaris 7 (or is that Solaris 8) implements that. It is too late to change. So arguing about it is useless. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 19: 4:43 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id D46FE14BD2 for ; Thu, 15 Jul 1999 19:04:40 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id UAA13363; Thu, 15 Jul 1999 20:03:03 -0600 (MDT) Message-Id: <4.2.0.58.19990715200237.047246e0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 15 Jul 1999 20:03:00 -0600 To: Warner Losh From: Brett Glass Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: Sheldon Hearn , Paul Hart , freebsd-security@FreeBSD.ORG In-Reply-To: <199907160156.TAA61822@harmony.village.org> References: <4.2.0.58.19990715194914.045ee7d0@localhost> <4.2.0.58.19990715180119.04723d20@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Darn. In that case, I'll just have to create macros that do it right. ;-) --Brett At 07:56 PM 7/15/99 -0600, Warner Losh wrote: >In message <4.2.0.58.19990715194914.045ee7d0@localhost> Brett Glass writes: >: Since OpenBSD is the only platform currently integrating the functions, >: there's time to work with them to make this the standard if we'd like. > >Too late. Linux (glibc I'm told) and Solaris 7 (or is that Solaris 8) >implements that. It is too late to change. So arguing about it is >useless. > >Warner > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 20:26:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 6F7D414E64 for ; Thu, 15 Jul 1999 20:26:23 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id VAA30130; Thu, 15 Jul 1999 21:24:48 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id VAA35056; Thu, 15 Jul 1999 21:24:47 -0600 (MDT) Message-Id: <199907160324.VAA35056@harmony.village.org> To: Brett Glass Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: Sheldon Hearn , Paul Hart , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Jul 1999 20:03:00 MDT." <4.2.0.58.19990715200237.047246e0@localhost> References: <4.2.0.58.19990715200237.047246e0@localhost> <4.2.0.58.19990715194914.045ee7d0@localhost> <4.2.0.58.19990715180119.04723d20@localhost> Date: Thu, 15 Jul 1999 21:24:47 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.0.58.19990715200237.047246e0@localhost> Brett Glass writes: : Darn. In that case, I'll just have to create macros that do it right. ;-) Sure would be easier than arguing with Theo :-) #define BrettStrlcat(a,b,c) ((c) - strlcat((a),(b),(c))) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 15 21:35:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 4E48314DF1 for ; Thu, 15 Jul 1999 21:35:29 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id WAA14458; Thu, 15 Jul 1999 22:34:46 -0600 (MDT) Message-Id: <4.2.0.58.19990715223310.0472a100@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 15 Jul 1999 22:34:45 -0600 To: Warner Losh From: Brett Glass Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: Sheldon Hearn , Paul Hart , freebsd-security@FreeBSD.ORG In-Reply-To: <199907160324.VAA35056@harmony.village.org> References: <4.2.0.58.19990715200237.047246e0@localhost> <4.2.0.58.19990715194914.045ee7d0@localhost> <4.2.0.58.19990715180119.04723d20@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 09:24 PM 7/15/99 -0600, Warner Losh wrote: >Sure would be easier than arguing with Theo :-) Arguing with Theo is kinda fun, actually. We had good discussions about gun control and health care during dinner at Def Con. (Of course, Theo thought that the Canadian approaches to both were absolutely The Right Thing. ;-) --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 16 5:20:45 1999 Delivered-To: freebsd-security@freebsd.org Received: from blubb.pdc.kth.se (blubb.nada.kth.se [130.237.225.158]) by hub.freebsd.org (Postfix) with SMTP id C8DF914D11 for ; Fri, 16 Jul 1999 05:20:11 -0700 (PDT) (envelope-from joda@pdc.kth.se) Received: from joda by blubb.pdc.kth.se with local (Exim 1.71 #3) id 1156w0-0000AS-00; Fri, 16 Jul 1999 14:17:48 +0200 To: Paul Hart Cc: freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) References: From: joda@pdc.kth.se (Johan Danielsson) Date: 16 Jul 1999 14:17:48 +0200 In-Reply-To: Paul Hart's message of "Thu, 15 Jul 1999 10:47:23 -0600 (MDT)" Message-ID: Lines: 12 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Paul Hart writes: > I was impressed by the paper and wondered if anyone besides myself > would be amenable to including them in FreeBSD's libc. I must admit that I didn't read the paper that thoroughly , but I was at the presentation. The only thing they missed was `prior art'. We did implemented the exact same functionality (but with other names) for our Krb4 distribution, and I beleive that those functions got imported into OpenBSD before they added strl* to libc. :-) /Johan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 16 6:38: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 6E92B14E47 for ; Fri, 16 Jul 1999 06:37:53 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id PAA81482; Fri, 16 Jul 1999 15:34:39 +0200 (CEST) (envelope-from des) To: "Childers, Richard" Cc: "'Anil Jangity '" , "''freebsd-security@freebsd.org ' '" Subject: Re: weird w report? References: From: Dag-Erling Smorgrav Date: 16 Jul 1999 15:34:39 +0200 In-Reply-To: "Childers, Richard"'s message of "Wed, 14 Jul 1999 12:17:53 -0700" Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Childers, Richard" writes: > Anil notes: > > "kill -9 -1" > > Umm, why are you doing a "kill -9 -1" ? To kill all processes in the shell's process group. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 16 12:11:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 5A2B915733 for ; Fri, 16 Jul 1999 12:11:19 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id MAA20660; Fri, 16 Jul 1999 12:09:22 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id MAA03117; Fri, 16 Jul 1999 12:09:22 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA08907; Fri, 16 Jul 99 12:09:14 PDT Message-Id: <378F8359.E68C040A@softweyr.com> Date: Fri, 16 Jul 1999 13:09:13 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Brett Glass Cc: Sheldon Hearn , Warner Losh , Paul Hart , freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) References: <4.2.0.58.19990715174241.045f0550@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brett Glass wrote: > > How about returning the shortfall as the return value of the function? > > This would allow the programmer to wrap an "if" right around the function > call and handle the error easily if the string was truncated. Making a > check convenient would encourage programmers to insert it into their code. > Having to write a separate test would actually discourage this practice > and could lead to malfunctioning code. A good idea, but it's already provided. As pointed out on Slide 9, if (strlcat(..., size) >= size) an overflow occured and should be handled. I agree with Mike that for future development or audits of existing code, moving away from static buffers is THE way to make the codebase less fragile. strl* does seem to have some compelling features for fixing existing code when a complete audit is either not warranted or just not feasible given the available "headcount." Relatively inexperienced programmers could be given a set of rules for replacing strcat and strcpy with strlcat and strlcpy to improve, if not perfect, many programs quite quickly. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 16 12:33:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from sapphire.alisa.org (mail.i-legal.com [209.181.77.105]) by hub.freebsd.org (Postfix) with ESMTP id 17C5315517 for ; Fri, 16 Jul 1999 12:33:47 -0700 (PDT) (envelope-from jjr@sapphire.alisa.org) Received: (from jjr@localhost) by sapphire.alisa.org (8.9.3/8.9.3) id NAA60719; Fri, 16 Jul 1999 13:30:33 -0600 (MDT) (envelope-from jjr) Date: Fri, 16 Jul 1999 13:30:33 -0600 (MDT) From: "John J. Rushford Jr." Message-Id: <199907161930.NAA60719@sapphire.alisa.org> To: brett@lariat.org, imp@village.org Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: freebsd-security@FreeBSD.ORG, hart@iserver.com, sheldonh@uunet.co.za In-Reply-To: <4.2.0.58.19990715194914.045ee7d0@localhost> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'd use the latest with FreeBSD 3.2. There were new features added to the libalias library and NATD. The latest feature added that I use is pptpalias. This allows you to have an NT server behind a FreeBSD firewall that MS Windows clients may login to with pptp from the internet. pptpalias first appears in FreeBSD 3.2. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 16 16:18:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id D30BE14CAE for ; Fri, 16 Jul 1999 16:18:21 -0700 (PDT) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id QAA31342; Fri, 16 Jul 1999 16:18:05 -0700 Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by point.osg.gov.bc.ca, id smtpda31340; Fri Jul 16 16:17:57 1999 Received: (from uucp@localhost) by cwsys.cwsent.com (8.9.3/8.9.1) id QAA16274; Fri, 16 Jul 1999 16:17:51 -0700 (PDT) Message-Id: <199907162317.QAA16274@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdI16270; Fri Jul 16 16:17:07 1999 X-Mailer: exmh version 2.0.2 2/24/98 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 2.2.8-RELEASE X-Sender: cy To: Nate Williams Cc: "Jordan K. Hubbard" , Brett Glass , Greg Black , Garrett Wollman , security@FreeBSD.ORG Subject: Re: Module magic In-reply-to: Your message of "Wed, 14 Jul 1999 18:12:55 MDT." <199907150012.SAA29975@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Jul 1999 16:17:05 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199907150012.SAA29975@mt.sri.com>, Nate Williams writes: > > Brett, did you buy a copy of CDE for FreeBSD when it was available? > > I did, so I mus be one of the 3 people who bought a copy. :) So did I. Who's the third person? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Province of BC "e**(i*pi)+1=0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jul 17 4:55:48 1999 Delivered-To: freebsd-security@freebsd.org Received: from mirage.nlink.com.br (mirage.nlink.com.br [200.249.195.3]) by hub.freebsd.org (Postfix) with ESMTP id 2C85C14CAA for ; Sat, 17 Jul 1999 04:55:40 -0700 (PDT) (envelope-from paulo@nlink.com.br) Received: from localhost (paulo@localhost) by mirage.nlink.com.br (8.9.3/8.9.1) with SMTP id IAA00116; Sat, 17 Jul 1999 08:55:28 -0300 (EST) Date: Sat, 17 Jul 1999 08:55:28 -0300 (EST) From: Paulo Fragoso To: Matthew Dillon Cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD exploit? In-Reply-To: <199907152253.PAA13514@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 15 Jul 1999, Matthew Dillon wrote: > :Hi, > : > :Has anyone ever read this article: > : > :http://www.securityfocus.com/level2/bottom.html?go=vulnerabilities&id=526 > : > :all version of freebsd has this problem!!! > : > :Paulo. > > Yes, but it isn't an exploit, it's a denial of service attack > ( and there is a difference ). Excuse my mistakes :-) > > Yes, it appears to be a real bug. I can set my datasize limit > to 16m and then mmap() a 64m file MAP_PRIVATE and touch all the > pages without getting a fault. > > We could conceivably fix it by adding a new resource limit to > the system for privately mmap'd space. But I think, ultimately, > the only way to fix it would be to add a per-user VM quota > resource that accounts for it properly. I thought it was more dangerous, because the article is classified "remote", and someone can remotely use to afsect another system. Thanks, Paulo. > > -Matt > Matthew Dillon > > ------ " ... Overall we've found FreeBSD to excel in performace, stability, technical support, and of course price. Two years after discovering FreeBSD, we have yet to find a reason why we switch to anything else" -David Filo, Yahoo! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jul 17 5:14:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 6998B14CBF for ; Sat, 17 Jul 1999 05:13:47 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 115TJV-000O5t-00; Sat, 17 Jul 1999 14:11:33 +0200 From: Sheldon Hearn To: Paulo Fragoso Cc: Matthew Dillon , freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD exploit? In-reply-to: Your message of "Sat, 17 Jul 1999 08:55:28 -0300." Date: Sat, 17 Jul 1999 14:11:32 +0200 Message-ID: <92620.932213492@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 17 Jul 1999 08:55:28 -0300, Paulo Fragoso wrote: > I thought it was more dangerous, because the article is classified > "remote", and someone can remotely use to afsect another system. I think that's a mistake. Since the exploit "allows any user to bypass rlimits", a login is implied. Also, the code provided must be run on the host in question. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jul 17 5:29:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.antisocial.net (ns1.antisocial.net [208.10.211.34]) by hub.freebsd.org (Postfix) with ESMTP id EEA0F14CE6 for ; Sat, 17 Jul 1999 05:29:45 -0700 (PDT) (envelope-from modred@ns1.antisocial.net) Received: from localhost (modred@localhost) by ns1.antisocial.net (8.9.3/8.9.3) with ESMTP id HAA07689; Sat, 17 Jul 1999 07:29:19 -0500 (EST) Date: Sat, 17 Jul 1999 07:29:19 -0500 (EST) From: Modred To: Brett Glass Cc: Warner Losh , Sheldon Hearn , Paul Hart , freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-Reply-To: <4.2.0.58.19990715223310.0472a100@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 15 Jul 1999, Brett Glass wrote: [snip] > thought that the Canadian approaches to both were absolutely The Right > Thing. ;-) *bow chikka bow wow* 'continuing a thread that's about as relevant to -security as 70's porno funk...' *chikka chikka bow wow* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message