[Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC
Mercer, Rodney
rmercer at harris.com
Mon Feb 25 19:29:07 UTC 2013
On Mon, 2013-02-25 at 18:48 +0000, Mercer, Rodney wrote:
>
>
> 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.
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
I think that this is a good explanation or the solaris rbac model.
http://www.softpanorama.org/Solaris/Security/solaris_rbac.shtml
Regards,
Rodney.
More information about the Freeipa-users
mailing list