[rsbac] Security bugfix for RSBAC for kernels 2.6.35 and later

[Javier Juan Martínez Cabezón]

I didn't get realized about this scenary.

So if the type of files are inherited from parent dir, and READ is granted
to parent dir then this role could read contents of files with independency
of READ_OPEN is granted or not to the file.

In the second scenary (with  READ WRITE interception disabled in kernel) if
I'm not wrong if READ is granted to parent dir then every access would be
answered DON'T CARE since is not checked, and because of this always
granted with or without READ_OPEN priv.

It's clear now, thanks Amon


2011/11/30 Amon Ott <ao en rsbac.org>

> On Wednesday 30 November 2011 wrote Javier Juan Martínez Cabezón:
> > Amon, in which case would this be a security problem?
> >
> > AFAIK, READ_OPEN calls are uneeded because they always require de READ
> one
> > to access de contents of the file.
> >
> > So I have never found a case in which READ_OPEN should be granted and
> READ
> > not.
> >
> > To me READ_OPEN is only userful to restrict scripts interpretation and
> > nothing more.
>
> READ is required to read the content of a dir, so it is quite often
> allowed on
> whole trees or RC types. If READ_OPEN is not denied, then you can read
> content of files, although you should only have access to the dir listing.
>
> Additionally, intercepting READ and WRITE on files is optional, you can
> turn
> it off in RSBAC kernel config. The reason is that you need to open it
> first...
>
> Amon.
> --
> http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
> _______________________________________________
> rsbac mailing list
> rsbac en rsbac.org
> http://www.rsbac.org/mailman/listinfo/rsbac
>