From owner-freebsd-arch Sun Apr 29 21:44:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 8747837B422; Sun, 29 Apr 2001 21:44:29 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3U4Zaf23859; Mon, 30 Apr 2001 00:35:36 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 30 Apr 2001 00:35:36 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jon Keating Cc: tmm@FreeBSD.org, Eivind Eklund , arch@FreeBSD.org, trustedbsd-discuss@TrustedBSD.org Subject: Re: suser security In-Reply-To: <01042920384400.01077@dsl254-020-111.sea1.dsl.speakeasy.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 29 Apr 2001, Jon Keating wrote: > I have a simple question about POSIX.1e I saw the link to download the > withdrawn draft. Is there actually a standard from IEEE that was > accepted regarding this? Nope -- draft 17 was the final draft, and after that apparently the committee decided not to go ahead with it. Some sections of the draft are quite useful, and other parts less so. > > I suspect that Thomas has caught most of the remaining uid calls, > > but once he publishes the next version of the capability patch, we'd > > welcome your work on it to catch remaining instances, and to comment > > on correctness. > > I'm assuming this will be posted on the TrustedBSD mailing list, correct? Generally speaking, major patchsets and commits are announced on the discussion list, with occasional CC's to appropriate FreeBSD lists. So far, we've not had the opportunity to use the -announce list much, but probably should so so more (such as the ACL stuff recently). > > Andrew Reiter has been preparing an auditing subsystem requirements > > document, as well as descriptions of implementations on other platforms > > so that we can go through a more informed design process. Having > > partially implemented auditing on FreeBSD twice in the past, I can > > comment both on the complexity of correct implemetation, and the need > > to be sensitive to issues of simplicity, maintainability, and > > performance. Taking a fairly deep look into other implementations will > > be important to developing an audit implementation that can be accepted > > by the FreeBSD community. This is certainly an area where both your > > contributions in the form of ideas and implementation would be most > > welcome. > > Yes, I would be very interesting in assisting with this as soon as the > framework is set up to build upon. Do you know of any time-frame on > this though? Summer is coming up in a few weeks for me and I wanted to > get going on a personal project and working on FreeBSD, but TrustedBSD > seems to be the area that I should focus on by reviewing the > documentation I've seen about it. I look forward to contributing to > this, and would enjoy starting on anything that you guys need help with. > Well, starting in two weeks from now. > Just let me know how I can contribute most effectively at this moment. Your help would be much appreciated -- there's always more work to do :-). Propelling the auditing work forward some more to get an initial design done would be useful, as would work to help Chris get userland applications adapted to use ACLs (he recently committed changes to cp and mv, but there are plenty left). As I mentioned before, once the capabilities kernel code gets a little bit more mature, there will be lots of work necessary to understand its impact on the userland codebase; Thomas should be able to provide us with some direction on what work to look at there. And now that I've finished up my USENIX paper, I hope to forge ahead more on the MAC code--one thing I haven't had time to look at, but would be nice to do, is to implement Type Enforcement (TE) using the MAC framework. I don't know how up you are on various access control technologies, but TE is the policy mechanism used in SELinux, and developed in part at Secure Computing. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message