Re: UDF and stacked scanners
Javier Juan Martínez Cabezón <[email protected]> Sat, 26 Dec 2015 16:16:22 +0100
| Newsgroups | gmane.linux.rsbac |
|---|---|
| Message-ID | <[email protected]> |
-----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 [email protected] > 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-----