capabilities impletementation?

[Dingo]

Well it appears that both you and I are game to bring these modules back
up to current. Id pretty much also be willing to migrate cap into SeBSD
as robert mentioned, or break it off into a cap2 cause its dated. As of
now, it seems we are on the same page, They need help, we are willing.
Robert mentioned about possibly having Scott Long provide the required
guidance. So it could be a good overall project to bring SeBSD back up
to a model framework. Robert also mentioned about merging cap into
SeBSD, or forking it to cap2. either way. So Id say we are ready, there
is also a third person who he mentioned could also be interested. Its
seriously time to get to work and round the project out so it can filter
backwards to FreeBSD.

On Tue, 2005-11-29 at 14:17 +0800, Joey Try wrote:
> I think so, while I looking into trustedbsd-cap, I found some issues that 
> puzzled me, not only in impletementation, but also configuration. 
> 
> If under some guide-lines, cap will not be so hard to be added into FreeBSD, 
> so will it be between diferent source versions.
> 
> 
> >Im game, cause its falling behind, I know we all have jobs, but if we
> >can tackle both with some guidance from scott Id be more then happy to
> >help get them up to date. The SeBSD branch in its current state, well to
> >say the least is buildable anyway. Ive been poking thru this code base
> >for a couple weeks, getting more familiar with the changes and looking
> >at nmount/mount issues as discussed earlier. sure, get me setup with
> >perforce and ill start to pound on this harder. If the others wish to
> >partake, the more the merrier. If there is a way to branch a cap2 off
> >and move forward there also, so be it.  If scott can provide some
> >guidance for us, im for it. At least itll be a beginning. 
> >
> >On Mon, 2005-11-28 at 14:01 +0000, Robert Watson wrote:
> >> On Fri, 25 Nov 2005, Dingo wrote:
> >> 
> >> > Robert , Scott ?? You guys want to give a bit of insight see if we can 
> >> > co-ordinate this between me and Joey, I think we are willing to pitch in 
> >> > more. I know Ive been pounding SeBSD into submission, where can we merge 
> >> > and bring forth the efforts faster?? And yes.. Scott a diff drop point 
> >> > would be good for me
> >> 
> >> So an interesting question is -- if we want to move forward with the 
> >> POSIX.1e privilege/capability implementation, do we want to attempt to 
> >> make it a MAC module, or do we want to keep the implementation separate. 
> >> Right now, the trustedbsd_cap branch is quite dated, but probably isn't 
> >> all that hard to update.  It does depend on changes that are also present 
> >> in the SEBSD branch, so there is the potential to combine efforts.  On the 
> >> other hand, there are lots of changes required for both that are 
> >> dependencies of only one -- for example, the type enforcement related 
> >> changes in user space aren't required for the capability implementation. 
> >> My leaning would be to keep them in different work areas, but to share as 
> >> much of the implementation as possible.
> >> 
> >> If it would make it easier, it's pretty straight forward to arrange 
> >> perforce accounts for both of you so you can get to and work on the 
> >> TrustedBSD branches in Perforce.  If you could coordinate with Scott on 
> >> SEBSD though, this would be great.  I know that Yanjun Wu is also quite 
> >> interested in the SEBSD work, and has had his hands in some local 
> >> implementation work relating to SEBSD.  Yanjun is also already set up with 
> >> Perforce access.
> >> 
> >> The most recent integration dates for the various branches are currently:
> >> 
> >> trustedbsd base		20051110
> >>    trustedbsd audit3	20050926
> >>    trustedbsd mac	20051110
> >>    trustedbsd sebsd	20050710
> >> 
> >> The CAP branch may well last have been integrated in 2001.  For that, it 
> >> might be worth starting with a cap2 branch integrated from 
> >> trustedbsd_base, and then propagating specific changes to it from the 
> >> SEBSD and CAP branches.
> >> 
> >> Robert N M Watson
> >> 
> >> 
> >> >
> >> > On Fri, 2005-11-25 at 16:44 +0800, Joey Try wrote:
> >> >> Yes, I wish to join you.
> >> >>
> >> >> I have studied the mail you forward to me, maybe Watson plan to merge CAP
> >> >> into MAC Framework. I also studied a little of MAC Framework in FreeBSD6.0,
> >> >> and found that there are not any cap_check entries, although there is also
> >> >> capability.h in sys/ directory! I do not know how Robert Watson plans for
> >> >> this.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>> ----Dingo----
> >> >>> Well per a previous conversation! Not sure how related it is to CAP but
> >> >>> as stated below pertaining to SeBSD as a whole. Im trying to pitch in to
> >> >>> bring the SeBSD to a more current 6.0 version. If you want to pitch in
> >> >>> someplace I think the help would be appreciated.
> >> >>>
> >> >>> ----SNIP--------
> >> >>>> So now that 6.0 is cut and RELEASE are there any plans to run a SeBSD
> >> >>>> snapshot ? Its would be nice to see something more current as even the
> >> >>>> previous snapshot was based on a dated early version of 6.). Any plans
> >> >>>> in the works, I see the base is current, but seBSD tree is still dated
> >> >>>
> >> >>> I'm in the process of updating the TrustedBSD base branch to a recent
> >> >>> 7.x, and hope to finish that in the next few days.  I have plans to then
> >> >>> merge those changes towards the MAC branch, although that will take some
> >> >>> time to merge due to some conflicting changes between the base FreeBSD
> >> >>> tree and MAC branch.  Once those prerequisites are in place, it should
> >> >>> be possible to begin work on updating SEBSD to a post 6.0-RELEASE state.
> >> >>> One of the conflicts introduced in earlier work was that FreeBSD has
> >> >>> made further moves towards using nmount(), which generated conflicts
> >> >>> with the introduction of a labeled mount system call in the SEBSD
> >> >>> branch.  With the movement towards nmount(), a special system call for a
> >> >>> labeled mount is no longer required, as the label can simply become an
> >> >>> additional nmount() argument.  However, some further tweaking and
> >> >>> merging of that conversion is required.  In short: currently, no ETA,
> >> >>> but hopefully in the next month or so.
> >> >>>
> >> >>> More hands are certainly welcome :-).  The code in the SEBSD branch
> >> >>> right now needs to have its update to a slightly older 6.x finished as a
> >> >>> first step, which basically involves fixing up any continuing disruption
> >> >>> from the nmount change.
> >> >>>
> >> >>> Robert N M Watson
> >> >>> ------SNIP-------------
> >> >>>
> >> >>> On Fri, 2005-11-25 at 15:57 +0800, Joey Try wrote:
> >> >>>> hi all, I am researching the POSIX.1e capabilities impletementation in TrustedBSD
> >> >>>>
> >> >>>> I only get the trustedbsd-cap source derived from FreeBSD5.0, since FreeBSD has release its 6.0 version, I want to know whether there is any updated source?  whether there is anyone I can discuss with?
> >> >>>>
> >> >>>> To Unsubscribe: send mail to majordomo at trustedbsd.org
> >> >>>> with "unsubscribe trustedbsd-discuss" in the body of the message
> >> >>>
> >> >>> To Unsubscribe: send mail to majordomo at trustedbsd.org
> >> >>> with "unsubscribe trustedbsd-discuss" in the body of the message
> >> >>>
> >> >>
> >> >>
> >> >> To Unsubscribe: send mail to majordomo at trustedbsd.org
> >> >> with "unsubscribe trustedbsd-discuss" in the body of the message
> >> >
> >> > To Unsubscribe: send mail to majordomo at trustedbsd.org
> >> > with "unsubscribe trustedbsd-discuss" in the body of the message
> >> >
> >
> >To Unsubscribe: send mail to majordomo at trustedbsd.org
> >with "unsubscribe trustedbsd-discuss" in the body of the message
> >
> 
> 
> To Unsubscribe: send mail to majordomo at trustedbsd.org
> with "unsubscribe trustedbsd-discuss" in the body of the message

To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message