[Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC
Dmitri Pal
dpal at redhat.com
Thu Feb 21 08:53:23 UTC 2013
On 02/20/2013 08:44 AM, Rodney L. Mercer wrote:
>
> On Tue, 2013-02-19 at 21:05 -0500, Dmitri Pal wrote:
>> On 02/19/2013 09:14 AM, Rodney L. Mercer wrote:
>>> On Sun, 2013-02-17 at 13:31 -0500, Dmitri Pal wrote:
>>>> On 02/16/2013 12:14 PM, Mercer, Rodney wrote:
>>>>> ________________________________________
>>>>> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Sigbjorn Lie [sigbjorn at nixtra.com]
>>>>> Sent: Saturday, February 16, 2013 6:29 AM
>>>>> To: freeipa-users at redhat.com
>>>>> Subject: Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC
>>>>>
>>>>> On 02/15/2013 10:31 PM, Dmitri Pal wrote:
>>>>>> On 02/15/2013 09:17 AM, Rodney L. Mercer wrote:
>>>>>>> On Thu, 2013-02-14 at 21:44 +0100, Sigbjorn Lie wrote:
>>>>>>>> I agree with schema support being enough for now. I do not expect the
>>>>>>>> ipa mgmt tools to support Solaris rbac mgmt.
>>>>>>>>
>>>>>>>> The ipa mgmt tools are great, but I already have other data in the ipa
>>>>>>>> ldap that I have to manage manually anyway.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Rgds,
>>>>>>>> Siggi
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Rob Crittenden <rcritten at redhat.com> wrote:
>>>>>>>> Dag Wieers wrote:
>>>>>>>> On Thu, 14 Feb 2013, Rob Crittenden wrote:
>>>>>>>>
>>>>>>>> Sigbjorn Lie wrote:
>>>>>>>> On 02/13/2013 04:10 PM, Rob Crittenden wrote:
>>>>>>>>
>>>>>>>> Also since we also require compatibility with Solaris, and roles
>>>>>>>> (RBAC)
>>>>>>>> is currently used on Solaris, does IPA support RBAC on Solar
>>>>>>>> is ?
>>>>>>>> (We
>>>>>>>> noticed that RBAC mentioned in the IPA web interface only
>>>>>>>> relates to > > IPA
>>>>>>>> management).
>>>>>>>> No, IPA doesn't support RBAC on Solaris.
>>>>>>>>
>>>>>>>> I've come across the same issue. This is just a matter of extending the
>>>>>>>> schema.
>>>>>>>>
>>>>>>>> Would there be any interest for adding the Solaris RBAC schema as a
>>>>>>>> part
>>>>>>>> of the standard IPA distributed LDAP schema?
>>>>>>> Consider the following: What else would have to be put in to support
>>>>>>> this?
>>>>>>> Once the schema is established, can SSSD be extended to use this and
>>>>>>> potentially be referenced in nsswitch.conf as it is implemented on
>>>>>>> Solaris? IE:
>>>>>>> tail -5 /etc/nsswitch.conf
>>>>>>> user_attr: sssd
>>>>>>> auth_attr: sssd
>>>>>>> prof_attr: sssd
>>>>>>> exec_attr: sssd
>>>>>>> project: sssd
>>>>>> Before we define how it is passed/exposed it would nice to understand
>>>>>> who on Linux will be consuming it out of SSSD?
>>>>>>
>>>>> I don't think Linux would consume these attributes. They are specific to
>>>>> the Role Based Access Control solution implemented in Solaris.
>>>>>
>>>>>
>>>>> Rgds,
>>>>> Siggi
>>>>>
>>>>> ----------------------------------
>>>>>
>>>>> Yes, I understand that Linux has no mechanism currently built in to consume these Solaris name server switch attributes. But, If the Solaris RBAC schema is included as
>>>>> part of the standard IPA distributed LDAP schema, My question is how hard would it be to create an extension using SSSD/pam to do so?
>>>>>
>>>>> I agree that it is too much to ask for a full Solaris style RBAC implementation on RHEL.
>>>>>
>>>>> We have an application that currently uses the Solaris RBAC structure to authorize user/role accesses within the application.
>>>>>
>>>>> Our goal is to use existing OS calls or possibly extending SSSD to allow system calls that would give us back an answer to attrbutes placed within the LDAP
>>>>> tree that are composed in like fashion as how they are stored in Solaris. Defining the schema seemed to be well received and I understand that it is intended that it would be there to support Solaris clients.
>>>>> If SSSD could be extended to access these attributes and possibly pam modules to allow Linux clients to take advantage of this RBAC schema, then our application could perform as it does on Solaris. It would also
>>>>> open up the opportunity for other vendors to consider moving their Solaris RBAC applications to RHEL.
>>>>>
>>>>> I think with that as a goal, we could then create users and SELinux roles that are defined within the RBAC based schema much like our current Solaris implementation.
>>>>> We use Solaris nsswitch calls to get yes/no authorization answers for user/role privilege within our application.
>>>>>
>>>>> Since IdM and SSD already support
>>>>> a) HBAC
>>>>> b) SUDO
>>>>> c) SELinux user mapping
>>>>>
>>>>> I believe HBAC as already implemented in IdM will be an additional asset in defining and restricting access that can be used by our customers.
>>>>> We have decided to move away from sudo, but may reconsider some of its uses if it suits the situation.
>>>>> Maybe SSSD can be extended to access the RBAC schema in much the same way that it accesses SUDO or HBAC schema?
>>>>>
>>>>> We have decided to use RHEL as the primary OS platform of choice going forward and we need to create a solution to our application RBAC
>>>>> needs similar to that in which we have accomplished with Solaris. I have been speaking with Dmitri on the side about these possibilities and would like to know
>>>>> what each of your thoughts are. The feasibility of accomplishing this is a bit over my head but is certainly our goal.
>>>>> I believe our management is committed to creating such a solution by involving our software engineers. Helping with adding the Solaris RBAC schema and
>>>>> contributing the GUI to manage the RBAC Schema data would be a goal.
>>>>>
>>>>> Also, since this is not the SSSD development list, I would like to know the list info for SSSD development and see what their thoughts are.
>>>>>
>>>>> Dmitri to answer your questions directly to me:
>>>>> Certainly we can discuss additional security components such as centrally managed SSH keys and host fingerprints. We don't need any interaction within our application to include AD,
>>>>> but our customers may want to take advantage of that at some point.
>>>> The sssd user list is
>>>>
>>>> sssd-users at lists.fedorahosted.org
>>>>
>>>> The devel list is
>>>> sssd-devel at lists.fedorahosted.org
>>>>
>>>>
>>>> But I suggest we continue this conversation here because otherwise the
>>>> conversation might fork and I would be hard to track. Most of the SSSD
>>>> developers read this list too.
>>>>
>>>> Since you have a clearly defined interface your application consumes
>>>> from Solaris the best thing now would be for you to provide a man page
>>>> style description of the calls the application needs and we will see how
>>>> to satisfy them with what we have and identify what needs to be added.
>>>> IMO such interface would be a requirement list. How we deliver it to the
>>>> application is an important but yes an implementation detail that we can
>>>> discuss after we know what requirements are.
>>>>
>>> Dmitri,
>>>
>>> We only use one system call from our application. that is
>>> chkauthattr - get authorization entry
>>> http://www.unix.com/man-page/all/3secdb/chkauthattr/
>>>
>>> we have users and roles defined in the user_attr map
>>> Each user is assigned one or more profiles.
>>>
>>> The profiles are kept in the prof_attr map.
>>> Top level Profiles can and often are mapped to groups of "sub" profiles,
>>> where each of the "sub" profiles are mapped to groups of authorizations.
>>>
>>> The authorizations are stored in the auth_attr map and map to strings
>>> that our application queries to determine if the user/role has mapped
>>> to via the profiles that they have been assigned.
>>>
>>> If the string is contained in the mapping, the chkautattr call returns
>>> an allowed response, if not, it returns a denied response to the system
>>> call.
>>>
>>>
>>> Example: Authorization check
>>>
>>> ruid = getuid();
>>> if ((pwp = getpwuid(ruid)) == NULL)
>>> crabort(INVALIDUSER);
>>>
>>> strcpy(real_login, pwp->pw_name);
>>>
>>> if ((eflag || lflag || rflag) && argc == 1) {
>>> if ((pwp = getpwnam(*argv)) == NULL)
>>> crabort(INVALIDUSER);
>>>
>>> if (!chkauthattr("auth_string", real_login)) {
>>> if (pwp->pw_uid != ruid)
>>> crabort(NOTROOT);
>>> else
>>> pp = getuser(ruid);
>>> } else
>>> pp = *argv++;
>>> } else {
>>>
>>>
>>>
>>> Authorizations
>>> An authorization is a unique string that represents a user’s right to
>>> perform some operation or class
>>> of operations. Authorization definitions are stored in a database called
>>> auth_attr(4). For
>>> programming authorization checks, only the authorization name is
>>> significant.
>>>
>>> CreatingAuthorization Checks
>>>
>>> To check authorizations, use the chkauthattr(3SECDB) library function,
>>> which verifies whether
>>> or not a user has a given authorization. The synopsis is:
>>>
>>> int chkauthattr(const char *authname, const char *username);
>>>
>>> The chkauthattr() function checks the policy.conf(4), user_attr(4), and
>>> prof_attr(4)
>>> databases in order for a match to the given authorization
>>>
>>>
>> OK, this is helpful.
>>
>> It seems that we would have to implement the whole interface anyways for
>> completeness or you think that implementing functions other than
>> chkauthattr() would not be required?
>> How common is this use of the RBAC?
>> Is is this how it is usually done or
>> it is a one off implementation and in general in Solaris world people
>> use RBAC information differently or to the greater extent?
> I can only speak for us, but, I'm fairly certain that we are most likely
> "one off" in our implementation.
We need to understand how limited it will be and what is the cost of
making it applicable to other use cases.
>> I want to
>> understand the scope of the solution. Would that be a one off that would
>> work just for your application's use or RBAC or it would work for most
>> of the Solaris applications that use RBAC.
>>
>> Is this the schema we are talking about:
>> http://docs.oracle.com/cd/E19455-01/806-5580/appendixa-8/index.html
>>
> I think that this goes back to the beginning of this thread where Dag
> Wieers, Rob Crittenden, Simo Sorce and Sigbjorn Lie were discussing an
> Solaris RBAC schema implementation to support Solaris clients.
> https://www.redhat.com/archives/freeipa-users/2013-February/msg00250.html
I did not find the exact reference to the schema in that conversation.
May be I missed it but this is why I asked.
So can someone confirm that the schema here is the right schema?
http://docs.oracle.com/cd/E19455-01/806-5580/appendixa-8/index.html
>
> Certainly the schema would have to be complete to support that
> implementation.
>
> Once the schema is there to support Solaris clients, then it could be
> exploited by linux clients with some effort.
Getting schema there is not a problem. You just drop a schema file into
a directory and restart the DS and the schema will be loaded.
So assume we have done it. Let us move on to the next step.
>
>> The schema uses 4 different object classes but the functions mentioned
>> above seem to deal only with the SolarisUserAttr and SolarisProfAttr
>> object classes. What about other two: SolarisAuthAttr &
>> SolarisExecAttr? Are they used or we do not need these on the server?
>>
> Again, we use user, prof and auth maps. We do not use the exec map.
But we probably should load it too.
> Our application uses chkauthattr calls to authorize commanding internal
> to our application.
The description of the chauthattr function says it uses user and prof maps.
It is unclear how it uses auth map. Other functions do but you do not
seem to use them.
http://docs.oracle.com/cd/E18752_01/html/816-5172/chkauthattr-3secdb.html
Also I did a quick search.
Is there any existing implementation of this functionality in Open Source?
I doubt we can use some of the existing OpenSolaris code because of
licensing.
May we can at least use it for inspiration.
>
>> IMO we have a good starting point to have a design page created by you.
>> Here is the template and here are some guidelines that might be helpful
>> when building a design page.
>> http://www.freeipa.org/page/Feature_template
>> http://www.freeipa.org/page/General_considerations
>>
>> Here is an example of the design that might give you some inspiration
>> (not everything mentioned in those pages ended up being implemented but
>> it gives a good hint of what needs to be covered in the design page) .
>> http://www.freeipa.org/page/V2/DS_Design_Summary_2 (see roles section)
>> http://www.freeipa.org/page/Overall_Design_of_Policy_Related_Components#Roles
>> www.freeipa.org/page/V2/IPA_Client_Design_Overview
>>
>> Good luck!
>>
> Thanks,
> Rodney.
>
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
More information about the Freeipa-users
mailing list