Javier J. Martínez Cabezón
tazok.id0 at gmail.com
Tue Feb 3 16:42:37 CET 2009
Well, this doesn't work as expected, I had to switch AUTH_ROLE to
secoff to make it work.
Didn''t suppose that it's granted to auditor role too?
2009/1/31 Javier J. Martínez Cabezón <tazok.id0 en gmail.com>:
> It get's solved with: marking audit user with AUTH ROLE auditor and
> rc_def_role syslog role, granted to this rol FS_MASK CAP min set, and
> marking syslog-ng binary as SETUID audit:root owner of syslog-ng.
> 2009/1/31 Javier J. Martínez Cabezón <tazok.id0 en gmail.com>:
>> Well, seems that this is controlled by "AUTH Role" for USER, I think
>> it would be useful to put this flag in roles too and not only in
>> users. I have for example one force role that makes all logging
>> granted to syslog-ng. If I'm not wrong AUTH search if this flag is
>> switched to secoff or auditor to grant the access to rsbac_log. It
>> depend of the existance of a user with this switch. Adding it to roles
>> instead users would be better in my opinion.
>> 2009/1/31 Javier J. Martínez Cabezón <tazok.id0 en gmail.com>:
>>> Hi, I have seen in the logs that access to GET_STATUS_DATA to SCD
>>> target rsbac_log is denied by AUTH. As seen in the source code in
>>> auth_main.c is hardcoded that only the roles of auditor or secoff has
>>> this rights granted. I think it would be useful to have a switch in
>>> the kernel that we could select the auditor role "number" (as the
>>> secoff uid in .config) and not depend on name at first (if someone
>>> create one role with the same name I think it could be dangerous). Now
>>> I can make an rc_copy_rol from my syslog role (8) to auditor one (3)
>>> but I think that other solution could be more proper.
More information about the rsbac