[rsbac] Restricting only one program

[Amon Ott]

On Friday 12 September 2003 07:07, Samuli Kärkkäinen wrote:
> Thank you for this suggestion, it's a good one. I went and did this, and I'm
> having a small problem. When I start or stop apache, I get about 20 syslog
> messages like this:
> 
> rsbac_adf_request(): request CLOSE, pid 7438, ppid 7437, prog_name httpd,
> uid 0, target_type FIFO, tid Device 00:05 Inode 88593 Path pipe:/[88593],
> attr , value 0, result NOT_GRANTED by ACL
> 
> The only differing thing in the messages is the pipe inode. If I turn off
> softmode and start apache, then after first error like above, I get also a
> syslog message:
> 
> filp_close() [sys_close]: ADF-call returned NOT_GRANTED
> 
> If I give FD :DEFAULT: right CLOSE, these errors go away. However if I give
> the same right to FD /, the errors stay. Does this mean :DEFAULT: includes
> the FIFO target type, while FD / includes only DIR and FILE types? What
> would be the right way to get rid of these errors?

All unnamed pipes are kept in pipefs, which does not get mounted inside the 
usual tree. This means that inheritance from / does not work for pipefs, so 
it reverts to :DEFAULT: instead - which has been introduced exactly for such 
cases. For the same reason, pipefs files will always have RC type 0.

You can see that pipefs has no parent fs mount point in 
/proc/rsbac-info/devices.

BTW, allowing to CLOSE anything does not harm you - CLOSE is only used to 
notify registered models, but a denial is not enforced. It makes no sense to 
really deny a close, because most programs do not check the close return 
code, and files are automatically closed on process exit.

> I think it would be a good idea to make AUTH capabilities inheritable. That
> would
> 
> - fit well within the way other modules work
> - provide good flexibility (fe. "allow SUIDs under /usr only")
> - be easier to use than compile time option
> 
> While security must obviously be the highest priority in things like this,
> the ease of use is also very important. Security tools such as RSBAC aren't
> used very widely because they are lacking in power, but because they are
> quite difficult to use. Therefore, I believe that making RSBAC easier to use
> does more to increase the effective security of real world systems than does
> increasing its already high degree of achieveable security.
> 
> Also if a distribution makes RSBAC part of its kernels, any user who wants
> to stick to distribution kernels won't have the option of changing any
> compile time options.

Agreed. I will change the system to inherit caps sets, if they have not been 
set explicitely, and allow setting caps at dirs. It will be an option at 
config time, which is on by default, so the old behaviour can still be chosen.

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22