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

Each real filesystem would have one rsbac.dat directory with ACI data.

If you have one filesystem, you get one rsbac.dat

Lets suppose that your fs0 directory tree is something like this

/
/nfs/root1
/nfs/root2
/nfs/home (that is shared by both "vms")

in fs0 / you would have rsbac.dat, only one, any change or decision made
would be against this. I think any access to any file inside nfs/root1
and 2 from vm0 and vm1 are made against rsbac as it would be locally,
that is, if you deny some access to /nfs/home/mydir from fs0 it would be
shared by both since them are under the control of rsbac as it would be
local.

Despite about what vm1 and vm0 knows, take note about what fs0 allows.
If you forbid something in fs0 neither vm0 neither vm1 could access to
it from the moment you deny it. Because any syscall done against fs0
would be intercepted by rsbac, checked and resolved as it would be local.

Until my known, consider that all mounted filesystems gets a rsbac.dat
directory. If vm0 and vm1 runs a rsbac kernel, then /nfs/root1 and
/nfs/root2 and /home would get their own rsbac.dat that would contain
data concerning vm0 and vm1 roles/types defined but they unknown the
decisions/data made by fs0. The real decision is done in the fs0 using
/rsbac.dat.

I think more tricky would be /home in the case you have rsbac kernels in
vm0 and vm1. I think you will have syncronization troubles there BUT
they will not affect decisions made in fs0.

So in resume, if you have rsbac in vm0 and in fs0, to get a request
granted you need first allow it in fs0, and at last in vm0, would be
stacked. Since vm0 and vm1 /home are not individual filesystems UNDER
fs0 the main kernel will not write rsbac.dat and as consequence will not
write rsbac.dat there neither read.


Maybe someone with more knowledge about nfs would give you better
information, this is what I suppose. I expect would be useful for you.


On 26/09/13 22:31, AJ Rabassa wrote:
> 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:
> 
> 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?
> 
> 
> 
>> _______________________________________________
>> rsbac mailing list
>> [email protected]
>> http://www.rsbac.org/mailman/listinfo/rsbac
>>
> _______________________________________________
> rsbac mailing list
> [email protected]
> http://www.rsbac.org/mailman/listinfo/rsbac