Re: rsbac_auditor_rol
Javier J. Martínez Cabezón <[email protected]>
| Newsgroups | gmane.linux.rsbac |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]>: > 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 <[email protected]>: >> 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 <[email protected]>: >>> 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. >>> >> >