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

Am Freitag, den 27.09.2013, 00:54 +0200 schrieb Javier Juan Martínez
Cabezón:
> 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?

No, what I can see, on every partition that mounted a rsbac.dat
directory is created. 
I newer try to setup any rules on a nfs share lets try tomorrow to see
if an other client is affected.


> If I'm correct you will not have rsbac.dat in vm0 and vm1 at any
> imported volumes.
> _______________________________________________
> rsbac mailing list
> [email protected]
> http://www.rsbac.org/mailman/listinfo/rsbac


_______________________________________________
rsbac mailing list
[email protected]
http://www.rsbac.org/mailman/listinfo/rsbac