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

-----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-----