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-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 >
I think that this is a good explanation or the solaris rbac model. http://www.softpanorama.org/Solaris/Security/solaris_rbac.shtml Regards, Rodney. _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users