Re: Security bugfix for RSBAC for kernels 2.6.35 and later

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.








2011/11/30 Amon Ott <[email protected]>

> Hello everyone,
>
> unfortunately, there is a severe bug in the code that determines the RSBAC
> request type in sys_open() calls. As a result from this bug, open access
> will
> be decided upon by RSBAC with wrong request type, a read open can happen
> unnoticed. A read() access after opening is intercepted as intended,
> because
> only the open interception is wrong.
>
> Affected are all RSBAC git repos for kernels starting from 2.6.35 and the
> official release 1.4.5 for 2.6.35. RSBAC for kernel 2.6.32 is not affected.
>
> Please update your kernel sources from git or apply the attached patch for
> 2.6.35.y and rebuild to get the bug fixed. I will try to get a new release
> out for kernel 3.1.4 or later as soon as possible. After fixing, your
> system
> might need RSBAC rights adjustments, because the set of accesses changes.
>
> Background: Between 2.6.32 and 2.6.35, the meaning of the flags parameter
> for
> sys_open() helper functions changed from some translated internal value to
> an
> exact copy of the sys_open() flags parameter. When porting RSBAC code from
> 2.6.32, we did not notice that change.
>
> Amon.
> --
> http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
>
> _______________________________________________
> rsbac mailing list
> [email protected]
> http://www.rsbac.org/mailman/listinfo/rsbac
>