Re: [RFC] new libsepol policy representation

["Robert Adams" <whatifwe@ix.netcom.com>]

[-- Attachment #1: Type: text/plain, Size: 2578 bytes --]

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


 
----- 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 PM
Subject: Re: [RFC] new libsepol policy representation


> Stephen Smalley wrote:
>> 
>> 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.
>> 
>> 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.
> 
> I'm currently undecided about this, so I'm creating APIs that are 
> appropriate for export and not planning on exporting them intially.
> 
>   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.
>> 
>> 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. 
>> 
> 
> Good catch - thanks.
> 
>> 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.
>> 
> 
> I'm planning to reconcile these at a future point - my plan is that the 
> records and the new policy structures will be fully merged at the end of 
> this.
> 
> Karl
> 
> --
> 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.
>

[-- Attachment #2: Type: text/html, Size: 5088 bytes --]