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

On 27/09/13 00:11, Javier Juan Martínez Cabezón wrote:
> 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.
>


In aci_data_structures.c



 322 rsbac_boolean_t rsbac_writable(struct super_block * sb_p)
 323 {
 324 #ifdef CONFIG_RSBAC_NO_WRITE
 325         return FALSE;
 326 #else
 327         if (!sb_p || !sb_p->s_dev)
 328                 return FALSE;
 329         if (rsbac_debug_no_write || (sb_p->s_flags & MS_RDONLY)
 330             || in_interrupt())
 331                 return FALSE;
 332         if (!MAJOR(sb_p->s_dev)
 333 #ifndef CONFIG_RSBAC_MSDOS_WRITE
 334             || (sb_p->s_magic == MSDOS_SUPER_MAGIC)
 335 #endif
 336             || (sb_p->s_magic == SOCKFS_MAGIC)
 337             || (sb_p->s_magic == PIPEFS_MAGIC)
 338             || (sb_p->s_magic == SYSFS_MAGIC)
 339             || (sb_p->s_magic == NFS_SUPER_MAGIC)
 340             || (sb_p->s_magic == CODA_SUPER_MAGIC)
 341             || (sb_p->s_magic == NCP_SUPER_MAGIC)
 342             || (sb_p->s_magic == SMB_SUPER_MAGIC)
 343             || (sb_p->s_magic == ISOFS_SUPER_MAGIC)
 344             || (sb_p->s_magic == OCFS2_SUPER_MAGIC)
 345             || (sb_p->s_magic == FUSE_SUPER_MAGIC)
 346             || (sb_p->s_magic == CEPH_SUPER_MAGIC))
 347                 return FALSE;
 348         else
 349                 return TRUE;
 350 #endif
 351 }
 352


Folks, this means that not attribute neither rsbac.dat is written in a
mounted nfs directory under rsbac isn't?

If I'm correct you will not have rsbac.dat in vm0 and vm1 at any
imported volumes.