[rsbac] DAZ & cache
Amon Ott
ao at rsbac.org
Thu Sep 29 10:25:58 CEST 2005
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
More information about the rsbac
mailing list