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-boun...@redhat.com > [freeipa-users-boun...@redhat.com] on behalf of Sigbjorn Lie > [sigbj...@nixtra.com] > >>>>> Sent: Saturday, February 16, 2013 6:29 AM > >>>>> To: freeipa-users@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 <rcrit...@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-us...@lists.fedorahosted.org > >>>> > >>>> The devel list is > >>>> sssd-de...@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@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users