[rsbac] UDF and stacked scanners

[Javier Juan Martínez Cabezón]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


PD: Amon if this is your plan for the future it could be useful to
trap the return codes and asociate them to one AEF answer (as DONT
CARE, DENIED etc) to each scanner, I think adding attributes to each
scanner to reflect this (something like AUTH ones) and associate them
with rc_types or everything else would allow a fine grained access
control (for example tripwire send a 2 error code if the file has been
added. In this scenario AEF for example could return DONT_CARE if
rc_type is usrshare_t but return DENIED if error code is 8 (file changed
)

What do you think?


On 26/12/15 15:39, Javier Juan Martínez Cabezón wrote:
> 
> 
> Hi folks. after reading a bit UDF source code, is feasible having
> 2 scanners at the same time?,. Have you tested with this? Are they
>  stacked? for example marking clamavd as a scanner and set tripwire
>  as another one. With this approach You could make for example to 
> only allow access to a file if sha256sum is correct forbiding 
> access if none (tripwire returns code 8 if I remember correctly so
>  it would be seen as denied by UDF).
> 
> I think there could be multiple scenarios interesting to this 
> approach, as it could be in NAS scenarios or just as an integrity 
> "model" as BIBA :P or why not spamasassing ones :)
> 
> Maybe UDF could be a user space REG model :)
> 
> Have any of you hacked with this?
> 
> What do you think? _______________________________________________ 
> rsbac mailing list rsbac at rsbac.org 
> http://www.rsbac.org/mailman/listinfo/rsbac
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWfq9DAAoJEFfmTgt/w77fxY8QAJXRNMd4rvHWCF4eLYPfWpzY
Onq6YKmaaZfU9ojTcv3mIcFEzLtfzqoh4ZiSThvxoyHqe/awlJvFd0BYUQ6Ab7rs
lylms5lgI9R2iAgeadBW3/xkPLaFf+efsk4wAMDF8hM/Kl6H0cv2wgkMn2guTJ0R
p0+2ZJDT0WdAEbwlTLTbkCKepsC+ofYfeS5eeDiIPIUXuPoruFXCrSiFduu+aTwL
tRYS1RH8dIfTRp99dlDSD3KgMFX2vgAw2ateZbhVkqNULFgRLLZnVzKU+phMfoZ2
fsGWZkwbX9LnjHgqEOcU2pj/ZQtYiLgD0GSlQ75nksk0Z26m1AZ1yFdorklRRozj
97VMxpHgxjBOPttqiYcMZrD58ZS0jhZWfmcil+TajeeGOg+BVrWv1J2a4Jv7YAPy
dOnbWQB8w14GI3ofz0E1Bii4oS9zj3z4RsdHPUUpm9LbWMSOYEYpe4iDu8p66oEC
zhaBbYLoBzW+qmkU3L8Tb8rlLl9IXoOfdj72Alu9IY3H47mNVYJHjK+zPwXzkm4I
4gX5CAPlG4rip8c9d7XGZTvu9qdlSTKNI91QORGblKMUoI/ysz70TDn532DoSPyY
LlWntBQii4sis1yqd8sMOucQaC8MZ/JRruK1FiwdoJM54yXqzahU0PB6dcG7fyP8
iBAz/03bdBJ2iQtKc1X8
=FvvE
-----END PGP SIGNATURE-----