From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzdrum.ncsc.mil (zombie.ncsc.mil [144.51.88.131]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id l16NN9ZF021132 for ; Tue, 6 Feb 2007 18:23:09 -0500 Received: from elasmtp-curtail.atl.sa.earthlink.net (jazzdrum.ncsc.mil [144.51.5.7]) by jazzdrum.ncsc.mil (8.12.10/8.12.10) with ESMTP id l16NOGbD006400 for ; Tue, 6 Feb 2007 23:24:16 GMT Message-ID: <003401c74a45$eb837bd0$24c60c0a@EMAIL> From: "Robert Adams" To: "Karl MacMillan" Cc: "SELinux Mail List\"" References: <45C23E5F.5050503@mentalrootkit.com> <1170688132.12293.245.camel@moss-spartans.epoch.ncsc.mil> <45C8E749.4000606@mentalrootkit.com> Subject: Re: [RFC] new libsepol policy representation Date: Tue, 6 Feb 2007 15:24:15 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C74A02.DCA63AA0" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C74A02.DCA63AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello: I a new kid on the block; just subscribed today. I am a consultant in Sun Valley, Ca. with 40+ years experience. I = specialize in the development and test of "error-free" software and have developed some developed some open-source = development and test tools for this goal. I invite you to visit my web-site, www.whatifwe.com, and = download as appropriate. Perhaps I can help in some small way. Hope to Hear from you Soon Thank You Robert Adams =20 ----- Original Message -----=20 From: "Karl MacMillan" To: "Stephen Smalley" Cc: "SELinux Mail List" Sent: Tuesday, February 06, 2007 12:38 PM Subject: Re: [RFC] new libsepol policy representation > Stephen Smalley wrote: >>=20 >> I'm not fundamentally opposed; we have in the past called for an >> appropriate IR for policy as a common basis for tools and >> infrastructure. >>=20 >> In skimming through the patch set, I'm unclear as to which aspects = are >> intended to be part of the shared library interface vs. the static >> library interface. In the current libsepol, include/sepol/policydb/ >> contains private state that is only made available to shared library >> users, while the top-level header files in include/sepol define the >> shared library interface. >=20 > I'm currently undecided about this, so I'm creating APIs that are=20 > appropriate for export and not planning on exporting them intially. >=20 > Of course, libsepol.map is the authoritative >> definition of the shared library interface. If you intend to export >> things like hashtabs to shared library users, then we naturally need >> proper encapsulation and namespacing of them. >>=20 >> As a nit, there is a name collision between the existing sepol_node >> struct (for node aka host records) and your new sepol_node struct for >> the tree.=20 >>=20 >=20 > Good catch - thanks. >=20 >> Similarly, you would need to reconcile your sepol_security_context* >> functions with the existing sepol_context* record functions. There = may >> be other points of duplication/overlap; I haven't yet looked = thoroughly. >>=20 >=20 > I'm planning to reconcile these at a future point - my plan is that = the=20 > records and the new policy structures will be fully merged at the end = of=20 > this. >=20 > Karl >=20 > -- > This message was distributed to subscribers of the selinux mailing = list. > If you no longer wish to subscribe, send mail to = majordomo@tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. > ------=_NextPart_000_0031_01C74A02.DCA63AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello:

I a new kid on the block; just = subscribed=20 today.

I am a consultant in Sun = Valley, Ca. =20 with 40+ years experience. I specialize in the development and test = of

"error-free" software and = have developed some developed some = open-source=20 development and test tools

for this goal. I invite = you=20 to visit my = web-site, www.whatifwe.com, and download = as=20 appropriate.

Perhaps I can help in some = small=20 way.

Hope to Hear from you = Soon

Thank You

Robert Adams

----- Original Message -----

From: "Karl MacMillan" <kmacmillan@mentalrootkit.com>

To: "Stephen Smalley" <sds@tycho.nsa.gov>

Cc: "SELinux Mail List" <selinux@tycho.nsa.gov>

Sent: Tuesday, February 06, 2007 12:38=20 PM

Subject: Re: [RFC] new libsepol policy=20 representation

> Stephen Smalley wrote:
>>
>> I'm not=20 fundamentally opposed; we have in the past called for an
>> = appropriate=20 IR for policy as a common basis for tools and
>>=20 infrastructure.
>>
>> In skimming through the patch = set, I'm=20 unclear as to which aspects are
>> intended to be part of the = shared=20 library interface vs. the static
>> library interface. In = the=20 current libsepol, include/sepol/policydb/
>> contains private = state=20 that is only made available to shared library
>> users, while = the=20 top-level header files in include/sepol define the
>> shared = library=20 interface.
>
> I'm currently undecided about this, so I'm = creating=20 APIs that are
> appropriate for export and not planning on = exporting them=20 intially.
>
> Of course, libsepol.map is the=20 authoritative
>> definition of the shared library = interface. If=20 you intend to export
>> things like hashtabs to shared library = users,=20 then we naturally need
>> proper encapsulation and namespacing = of=20 them.
>>
>> As a nit, there is a name collision = between the=20 existing sepol_node
>> struct (for node aka host records) and = your new=20 sepol_node struct for
>> the tree.
>>
> =
> Good=20 catch - thanks.
>
>> Similarly, you would need to = reconcile your=20 sepol_security_context*
>> functions with the existing = sepol_context*=20 record functions. There may
>> be other points of=20 duplication/overlap; I haven't yet looked thoroughly.
>> =
>=20
> I'm planning to reconcile these at a future point - my plan is = that the=20
> records and the new policy structures will be fully merged at = the end=20 of
> this.
>
> Karl
>
> --
> This = message=20 was distributed to subscribers of the selinux mailing list.
> If = you no=20 longer wish to subscribe, send mail to majordomo@tycho.nsa.gov = with
>=20 the words "unsubscribe selinux" without quotes as the=20 message.
> ------=_NextPart_000_0031_01C74A02.DCA63AA0-- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.