Date: Mon, 4 Dec 2000 18:17:55 -0800 From: "John Howie" <JHowie@msn.com> To: "David G. Andersen" <dga@pobox.com> Cc: "David G. Andersen" <dga@pobox.com>, <freebsd-security@FreeBSD.ORG> Subject: Re: [spam score 10.00/10.0 -pobox] Re: Fw: NAPTHA Advisory Updated - BindView RAZOR Message-ID: <014a01c05e61$944b37d0$fd01a8c0@pacbell.net> References: <200012050138.SAA03007@faith.cs.utah.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
David G. Andersen wrote: > Lo and behold, John Howie once said: > > > > I'm afraid I disagree - this is not purely a daemon problem. I wonder if you > > had time to read the whole advisory for the FreeBSD information near the end > > of the report (I've included it below). > > > > > > affected. The daemons targeted in this > > > > > testing are not necessarily at fault for > > > > > the problems encountered. > > That's where there may be some disagreement. I personally feel that a > base system should provide more resource isolation between daemons than > FreeBSD, Linux, and most other operating systems do, but that's a matter > of opinion. ;-) > Actually I don't believe that we are too far off the mark on this one. The concept of providing each isolated server process a virtual OS to run in is a good idea, and one worth investigating further. If a process exhausts its allocated resources in its virtual OS the rest of the system runs unaffected. Makes other aspects of security easier too. > > Unsurprising that UDP DNS was unaffected. There's no way for an > attacker to connect and say, "Oh, hang on, I'll send you the rest of that > in a bit." > I cut and pasted the whole section but you are right, I should have commented on this one - UDP being stateless would not be affected. > > If a daemon becomes unusable because it is subject to attack then that is, > > while not ideal, at least tolerable. When the whole system becomes unusable > > that points to problems in the kernel. > > Nope. It wasn't a kernel problem you were encountering - it was a > systemwide resource limit being reached. It's not that there's a _bug_ in > the kernel, it's that the processes file table limits weren't isolated > from each other. The right solution to this is more isolation of > different processes (e.g. resource control). > Another possibility which would work in some resource-depletion situations is the keeping of some kernel-only resources so no matter what happens in user-land the OS is able to carry on and do its work, even if user-land is hosed. I do not believe that would be applicable here, however. > > You can probably figure out which of these I think is the best > solution, but just in case, I'll give you a hint: (c). Not many > operating systems do this these days; see the maybe-about-to-be-released > Flask kernel (NSA/TIS) for an example of a great way to do it. > Agreed. > Of course, the problem is really more interesting than I've let on to so > far: What one _really_ wants to do is start rate-limiting some clients > without affecting the others (e.g. at an OS level, I can easily protect > NFS from SSH, but I want to protect good web clients from the > bad). Two models that I came across several years ago actually might have a solution, although neither were proposed as solutions for security problems - they were intended to handle bursts of data. The first, and this sounded daft at the time, was to employ a "market economy" type of network communication, whereby clients and servers could barter with each other for access to services. A client that "saved" its connection resources either by not sending data, or doing so at a low priority, could then use its banked credits to send high bursts of data or it could negotiate with another client or server to sell its credits. It was claimed that the pattern that emerged allowed most, but not all, clients and servers equal access to resources on an as-needed basis. I must confess I only read a paper on this and can't remember much more. The second approach used a heuristic learning model to look for bursts of activity and throttle back connections until OS resources could be allocated. Such a model would be the basis of today's IDS. john... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?014a01c05e61$944b37d0$fd01a8c0>