[Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC
Mercer, Rodney
rmercer at harris.com
Mon Feb 25 18:48:58 UTC 2013
On Thu, 2013-02-21 at 03:53 -0500, Dmitri Pal wrote:
> 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
>
----------------
Yes, this looks to be the correct schema as the defined oids match the
RBAC oids in the iPlanet Directory Server Setup.
http://docs.oracle.com/cd/E19455-01/806-5580/6jej518pn/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
----------------
Yes, it does state:
The authorization name matches exactly any authorization assigned in the
user_attr or prof_attr databases (authorization names are
case-sensitive).
It is my understanding that authorizations are defined in the auth_attr
map and referenced via the prof_attr and/or user_attr.
users/roles defined in user_attr can be assigned authorizations or
profiles (groups of authorizations/profiles).
profiles are groups of authorizations and they are defined in prof_attr.
Also a profile can instead reference groups of other profiles which in
turn would each reference a group of authorizations.
The authorization are defined in auth_attr.
Again this my understanding, but I am in no way an expert.
----------------
> 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/
Thanks and regards,
Rodney.
More information about the Freeipa-users
mailing list