[rsbac] DAZ & cache

[Amon Ott]

On Donnerstag 29 September 2005 09:41, Andrea Pasquinucci wrote:
> I am using DAZ and I notice something that I do not like too much, 
even 
> if I do not know what it could be done about it.
> 
> I have done the following tests having created a directory which is 
not 
> scanned by clamd ("ClamukoExcludePath /somedir/NOCHECK/")
> 
> TEST 1
> - try to access a virus in /somedir/CHECK/ => access denied = OK
> - mv /somedir/CHECK/virus /somedir/NOCHECK/   => success = OK
> - less /somedir/NOCHECK/virus  => success = OK
> - mv /somedir/NOCHECK/virus /somedir/CHECK/ => success = OK
> - less /somedir/NOCHECK/virus => success ???? NOT OK!!

This should not work, it must be a bug. Is it with 1.2.5? There was a 
fix for the cache in the pre series.
 
> well I do understand that the cache has tricked me. In accessing the 
> file in the NOCHECK directory, the inode has been marked as CLEAN, 
then 
> I moved the file in the same partition, the inode has not changed, 
so it 
> is still marked as CLEAN. Well my point here is that when DAZ checks 
the 
> file in /somedir/NOCHECK/, clamd should answer "NO CHECK" or 
something 
> similar, now what should be put in cache? My understanding is that 
it is 
> put CLEAN, but why not put "UNKNOWN" in cache? I guess the answer is 
> that in this case every time a file is accessed in the NOCHECK dir 
there 
> will be nothing in the cache and clamd should be called, with a lot 
of 
> extra work of course, but much less security. If I am correct, I 
would 
> propose to introduce a switch at some level (kernel config or admin 
> utils) to let a user decide what should be put in cache if clamd 
answers 
> "not checking in this dir"

This is an example of why name based access control is bad. :/

My suggestion: We also clean the cache entry, if a file gets renamed. 
Please try the attached patches for 2.6 and 2.4 kernels with RSBAC 
1.2.5.
 
> TEST 2
> same as test 1 but instead of  "mv /somedir/NOCHECK/virus 
> /somedir/CHECK/", I do "cp /somedir/NOCHECK/virus /somedir/CHECK/". 
Also 
> the results are the same, but now the inode are different!!! Why? I 
> guess that in creating the new file, the DAZ cache of the parent is 
> copied to it, but this I do not understand really ????????????

> TEST 3 same as test 2 but I move or copy the file to a different 
> partition, nothing changes, still access!!!!

The clean marking for new files in some cases was supposed to be fixed 
in 1.2.5. Are you on 1.2.5 already?

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
-------------- nächster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : rsbac-daz-rename-2.4.diff
Dateityp    : text/x-diff
Dateigr??e  : 6709 bytes
Beschreibung: nicht verf?gbar
URL         : http://rsbac.dyndns.org/pipermail/rsbac/attachments/20050929/925ea2e7/rsbac-daz-rename-2.4.bin
-------------- nächster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : rsbac-daz-rename-2.6.diff
Dateityp    : text/x-diff
Dateigr??e  : 6495 bytes
Beschreibung: nicht verf?gbar
URL         : http://rsbac.dyndns.org/pipermail/rsbac/attachments/20050929/925ea2e7/rsbac-daz-rename-2.6.bin