Seusers vs ldap

Seusers vs ldap

[Ivan Gyurdiev]

How would we go about implementing LDAP support for seusers in libsemanage?
I asked Joshua about this on IRC, but I think we to plan this on list.

I think the most important question to be decided is whether we'll use 
libldap directly, or execute external programs to work with LDAP? The 
first option makes libsemanage always linked to libldap.

I also don't quite understand the role of the system-wide default 
properties in ldap.conf. Joshua is telling me we'll need a server, 
context, and keys specific to semanage (so we have to write all 
ldap-related things in semanage.conf), but I'm not sure why the context 
and server can't be shared with ldap.conf if necessary - I'm probably 
still not understanding how this works - I have very limited knowledge 
of ldap at this point. If you open up system-config-auth on fedora, they 
seem to share the LDAP config for authentication and user info, if you 
enable both of them.

Also, do we have to write a schema? Does that schema get added to the 
slapd package?

--
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.

Re: Seusers vs ldap

[Daniel J Walsh]

Ivan Gyurdiev wrote:
> How would we go about implementing LDAP support for seusers in 
> libsemanage?
> I asked Joshua about this on IRC, but I think we to plan this on list.
>
> I think the most important question to be decided is whether we'll use 
> libldap directly, or execute external programs to work with LDAP? The 
> first option makes libsemanage always linked to libldap.
Why not loadable module?
>
> I also don't quite understand the role of the system-wide default 
> properties in ldap.conf. Joshua is telling me we'll need a server, 
> context, and keys specific to semanage (so we have to write all 
> ldap-related things in semanage.conf), but I'm not sure why the 
> context and server can't be shared with ldap.conf if necessary - I'm 
> probably still not understanding how this works - I have very limited 
> knowledge of ldap at this point. If you open up system-config-auth on 
> fedora, they seem to share the LDAP config for authentication and user 
> info, if you enable both of them.
>
> Also, do we have to write a schema? Does that schema get added to the 
> slapd package?

We want support for Fedora-Directory also.

--
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.

Re: Seusers vs ldap

[Joshua Brindle]

Daniel J Walsh wrote:
> Ivan Gyurdiev wrote:
> 
>> How would we go about implementing LDAP support for seusers in 
>> libsemanage?
>> I asked Joshua about this on IRC, but I think we to plan this on list.
>>
>> I think the most important question to be decided is whether we'll use 
>> libldap directly, or execute external programs to work with LDAP? The 
>> first option makes libsemanage always linked to libldap.
> 
> Why not loadable module?
> 
it's a possibility. there is no kind of dynamic library loading 
infrastructure in libsemanage though, and we should really figure out 
which is the best way to do it before proceeding on any of these routes.

>>
>> I also don't quite understand the role of the system-wide default 
>> properties in ldap.conf. Joshua is telling me we'll need a server, 
>> context, and keys specific to semanage (so we have to write all 
>> ldap-related things in semanage.conf), but I'm not sure why the 
>> context and server can't be shared with ldap.conf if necessary - I'm 
>> probably still not understanding how this works - I have very limited 
>> knowledge of ldap at this point. If you open up system-config-auth on 
>> fedora, they seem to share the LDAP config for authentication and user 
>> info, if you enable both of them.

the ldap.conf could tell the system authentication server and search 
context, sure. semanage.conf needs a minimal amount of configuration to 
tell libsemanage where to look for each of its components though. Also, 
the libsemanage LDAP backend will need to know how to search for users, 
different directory servers use different keys for user entries, etc.

>>
>> Also, do we have to write a schema? Does that schema get added to the 
>> slapd package?
> 
The schema is installed when the app that uses the schema is installed 
(at least this is how it worked when I used eDirectory). Prepackaging 
them with the directory server makes it inconvenient for us to keep them 
up to date.

> 
> We want support for Fedora-Directory also.
> 

LDAP will support fedora directory server just fine, as well as all 
other modern directory server implementations.

--
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.

Re: Seusers vs ldap

[Ivan Gyurdiev]

>>> How would we go about implementing LDAP support for seusers in 
>>> libsemanage?
>>> I asked Joshua about this on IRC, but I think we to plan this on list.
>>>
>>> I think the most important question to be decided is whether we'll 
>>> use libldap directly, or execute external programs to work with 
>>> LDAP? The first option makes libsemanage always linked to libldap.
>>
>> Why not loadable module?
>>
> it's a possibility. there is no kind of dynamic library loading 
> infrastructure in libsemanage though, and we should really figure out 
> which is the best way to do it before proceeding on any of these routes.
Well, what's your justification for using external programs in 
libsemanage - for verify operations, and for loading the policy (I'm not 
sure if there's any justification for genhomedircon, it should be 
absorbed by libsemanage eventually). I thought there were security 
issues involved - maybe confine the load_policy or verifier program 
differently from the libsemanage client. Are any such issues applicable 
in the ldap case?

With regard to loadable module - what kind of infrastructure is needed - 
do we use dlopen()?
What resources are there to learn about this kind of thing...
Can you think of other uses of loadable modules in libsemanage?
Stephen, do you have an opinion on what should be done?

--
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.

LDAP vs Dbase semantics

[Ivan Gyurdiev]

I am looking at LDAP, and I don't like it so far...

Apparently it doesn't support transactions, one of the things expected 
and assumed of a semanage dbase backend. According to the OpenLDAP 
roadmap, they will support LDAPv3 extensions, including "LDAP 
transactions" in 2006 Q1. Please correct me if this is wrong, and I've 
missed transactions somewhere...

So.... that creates lots of problems. How do we handle modifications?
We can fetch all the data in a local copy, work on it, then send it back 
(ignoring the fact that the flush() operation might fail in an 
irreversable way). That seems like a bad idea, because it eliminates our 
ability to use the LDAP read optimizations. We're replacing a server 
with some dumb local-store solution, like the linked list thing, which 
is the worst data structure possible.

Alternatively we can store deltas (user requests for change), and then 
on flush() we can try to apply them all. That creates its own set of 
problems, because current semantics are that semanage changes are 
immediately visible in the dbase they're applied to (not so in the case 
of storing deltas, not unless we apply them on every read request). 
Furthermore, this increases the possibility of failure, since the client 
can easily generate an invalid sequence of requests, and none of them 
will get verified until flush(), not even something simple like "does 
the user exist"). I.E. rquests 1-55 passed, 56 failed, because the 
client did something wrong, now we have to _try_ to reverse the other 55 
(if we have enough info to do so).

Hmm....


--
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.

Re: LDAP vs Dbase semantics

[Ivan Gyurdiev]

> So.... that creates lots of problems. How do we handle modifications?
> We can fetch all the data in a local copy, work on it, then send it 
> back (ignoring the fact that the flush() operation might fail in an 
> irreversable way). That seems like a bad idea, because it eliminates 
> our ability to use the LDAP read optimizations. We're replacing a 
> server with some dumb local-store solution, like the linked list 
> thing, which is the worst data structure possible.
...but then again, do we care? This is a management library, not to be 
queried 100 times a second.
Maybe I should just put all the users in a linked list and be done with 
it...

Still doesn't solve the problem of what to do when flush() fails...


--
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.

Re: Seusers vs ldap

[Joshua Brindle]

Ivan Gyurdiev wrote:
> 
>>>> How would we go about implementing LDAP support for seusers in 
>>>> libsemanage?
>>>> I asked Joshua about this on IRC, but I think we to plan this on list.
>>>>
>>>> I think the most important question to be decided is whether we'll 
>>>> use libldap directly, or execute external programs to work with 
>>>> LDAP? The first option makes libsemanage always linked to libldap.
>>>
>>>
>>> Why not loadable module?
>>>
>> it's a possibility. there is no kind of dynamic library loading 
>> infrastructure in libsemanage though, and we should really figure out 
>> which is the best way to do it before proceeding on any of these routes.
> 
> Well, what's your justification for using external programs in 
> libsemanage - for verify operations, and for loading the policy (I'm not 
> sure if there's any justification for genhomedircon, it should be 
> absorbed by libsemanage eventually). I thought there were security 
> issues involved - maybe confine the load_policy or verifier program 
> differently from the libsemanage client. Are any such issues applicable 
> in the ldap case?

privilege separation primarily. While verifier programs are trusted to 
give us a good answer regarding whether a policy is ok to load it 
shouldn't be trusted with write access to the policy. Same with 
genhomedircon, it can write file context files but not the policy or 
anything in the module store (granted that it can do a whole lot of 
potential damage by writing incorrect file contexts).
> 
> With regard to loadable module - what kind of infrastructure is needed - 
> do we use dlopen()?
> What resources are there to learn about this kind of thing...
> Can you think of other uses of loadable modules in libsemanage?
> Stephen, do you have an opinion on what should be done?
> 

well, infrastructure meaning some way of configuring which modules get 
loaded, passing options to them, an api between libsemanage and the 
dynamic modules. It isn't as simple as just calling dlopen().

Now that I think of it loading a random network module into the memory 
space of semanage is a bad idea, we should be limiting the amount of 
trust we put in the alternate (esp networked) backends

--
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.

Re: Seusers vs ldap

[Ivan Gyurdiev]

>
> Now that I think of it loading a random network module into the memory 
> space of semanage is a bad idea, we should be limiting the amount of 
> trust we put in the alternate (esp networked) backends
Does that mean there will be no networked policy server backend?
I don't trust the pserver very much at the moment :)



--
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.