Re: rsbac in a network environment (LDAP and NFS)?

Sorry, I'm probably not being clear.  My issue is how rsbac works BETWEEN
servers, not how it works on one server.

I'm not concerned about whether or not rsbac will work with ldap, because
I'm almost positive they work together (other people have reported success
running ldap authentication on a box with rsbac). What I'm concerned about
is rsbac seems to circumvent the whole reason to run an ldap server to
begin with.

Say I have three servers, two diskless vm's, vm0, vm1, and fs0 (the
fileserver + ldap).  Both vm0 and vm1 connect at boot, via NFS, to fs0.
Each server gets private root volume, and use a shared /home volume, all on
fs0.

What I'm worried about is that the roles and ACLs are not synchronized
between the three servers.  I connect to ldap on fs0, and add a group
"newgroup." I configure "newgroup" to have all the permissions I want on
the fileserver.

How do vm0 and vm1 know about the changes to rsbac policies on fs0?  This
is what ldap would achieve if rsbac were not installed; once I install
rsbac, it looks like I'm going to lose the common user environment and
configuration ldap provides across servers.

Further, say I write some sort of script or copying mechanism; that works
well for two servers, but what happens when I take the solution to a live
environment? Our windows environment is ~200 servers in production; there
HAS to be a centralized management tool, which is usually ldap. There are
multiple file servers, multiple domains, all of which have to pull their
authentication and authorization from a central source if it's going to be
manageable.

I could be completely misunderstanding how rsbac stores data, but to my
ignorant eyes it seems like rsbac is storing data a way that is difficult
to scale out to production.


On Thu, Sep 26, 2013 at 3:44 PM, Javier Juan Martínez Cabezón <
[email protected]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 26/09/13 20:04, AJ Rabassa wrote:
> > Thanks for the links, Javier.
> >
> > The concern I have is that all authentication requests are going to
> > use LDAP (and Kerberos); the purpose of using LDAP (in this
> > instance) is to centralize user management and permissions across
> > all servers.  If RSBAC breaks that, I can't use it; every other
> > service services we plan on using has LDAP plugins.
> >
> > A better, more refined question would be: *Without* altering
> > PAM/nsswitch.conf, how can I unify RSBAC's acl and rc policies?
> >
> >
> > On Thu, Sep 26, 2013 at 1:18 PM, Javier Juan Martínez Cabezón <
> > [email protected]> wrote:
> >
> >
> >
> >
>
>
> I don't know what do you want mean with unify policies. In rsbac
> Modules are stacked, that is one request shall be granted by ACL and
> RC, by both to get success.
>
> RC is designed to separation of duties, you can assign and individual
> role to one user/program and define which types (as files, ipc,
> process) could him access, it allows you to create a Process Based
> Access Control.
>
> In ACL you just define which user/role can access to which object and
> how he does. There is not transitions between roles. Is static.
>
> RC does not understand about users, just roles. Every user has a
> rc_default_role assigned and is what he controls and the relevant part
> of the security checkings.
>
> Roles just can be changed after SETUID (i.e login) or after a EXECUTE
> (if rc_initial_role/forced role are define), or if defined as
> compatible role with a syscall.
>
> They are different modules used to different tasks, one to implement
> PBAC and/with separation of duties and the other just acls.
>
> However, if your users does not make a CHANGE_OWNER against PROCESS
> target (so change to a system uid as login, su, sshd...does) you will
> have (at my opinion) hard to make your users change to their default
> assigned role. So is important to know how authentication is done and
> to know if there are real users or not.
>
> With a fast sight I think that pam_ldap.so and pam_krb5.so could be
> compatible with pam_rsbac.so (pam_rsbac.so is a replacement of
> pam_unix.so). ¿Have you thought about this?
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQIcBAEBAgAGBQJSRI6JAAoJEFfmTgt/w77fegQP/AiBrraiHusT4DhJGUWvHL0Q
> JA5A+KP0sc9oKYSISimv21uiDw4bTTxgMPXFR9R3mC9xTOiDnmyz5tbsijQJFa/Z
> QF416RVI4jOSCM4CQwwds7YeqGf4945gRIEXJwJQepylmMa2H+Je5aY3CEMe+dda
> GBU/u8d+rioHJBuLiyofyWSHJ9JqZm6LkrH3des3PdaLSEbQHwQ5Qg6Q6v+8vHll
> y9hXNLogs9j+POmZ4hDD3zVst1BzzEEEMWpRvIQ2ZKERaHkSTHrFZ2HzQBQAjJq/
> x/2jwhBpfNggEJ3iwu/5gPhrTZvMDOBYUu1uZ/soboZqLyFQT2g7c22ptJkLGFws
> T7QMB1ay8QE0XM2EAgwFnEXwDWDwn6I8jVHeS+PPDWrGZ47w9qkrY5vZ9zw4CLRZ
> 0E2NTw4XKq163ZnnH9tljqjqVOpdt2XaWV9z448b14XhGony042pKxr1+RZTPa+P
> /NeMN2Bc09Xx/p2eJylXV7NZ5TRaYRubSJa1PK8da/H2IEBV5GN1exN75rm7rQsf
> e/v3lpp58MXxdy7/JE/XDbEZiS6ddcaFnn6tcHzp8xRcpuHUp2CyUPtIVnHyQzSl
> BiBnAVnDfGw0MU66R5f1OukGAR2894VZDxT+GLPb/O8Oy2ArkjXjYZmkO75b4f9i
> XGaojx3ElHxqtRG2Yn8Z
> =7sZ2
> -----END PGP SIGNATURE-----
> _______________________________________________
> rsbac mailing list
> [email protected]
> http://www.rsbac.org/mailman/listinfo/rsbac
>