[rsbac] RSBAC documentation
Javier J. Martínez Cabezón
tazok.id0 at gmail.com
Mon Jan 12 16:29:45 CET 2009
The flag req_reauth is not documented at all, which could be their
use? I think it stands for require_reauthentification, if it's this
when it will be reauthenticated? against UM only?.
2009/1/12 Javier J. Martínez Cabezón <tazok.id0 en gmail.com>:
> Another question I think that the targets of the requests could be
> obsoleted, SEND for example as I saw in the source code affects FD,
> DEV, PROCESS, IPC y NETOBJ targets and not only to DEV and NETOBJ.
> MAP_EXEC isn't chequed in SCD. These are the ones I saw:
> * ACCEPT: FD, PROCESS, IPC, NETOBJ.
> * ACCESS_CONTROL: ALL
> * ADD_TO_KERNEL: FD, DEV SCD ( other).
> * ADMIN: ALL
> * ALTER: IPC.
> * APPEND_OPEN: FD, DEV, IPC
> * ASSIGN: ALL
> * AUTHENTICATE: USER.
> * BIND: NETDEV NETOBJ.
> * CHANGE_AUTHED_OWNER: Same as CHANGE_OWNER
> * CHANGE_OWNER: USER, PROCESS) IPC.
> * CHANGE_GROUP: USER, PROCESS, IPC
> * CHDIR: FD.
> * CHANGE_DAC_EFF_OWNER: PROCESS.
> * CHANGE_DAC_FS_OWNER: PROCESS.
> * CHANGE_DAC_EFF_GROUP: PROCESS.
> * CHANGE_DAC_FS_GROUP: PROCESS.
> * CLONE: PROCESS.
> * CLOSE: FD, IPC, DEV, NETOBJ.
> * CONNECT: IPC, PROCESS, FD NETOBJ.
> * CREATE: FD, USER, PROCESS, CREATE, GROUP, NETOBJ NETTEMP.
> * DELETE: FD, USER, IPC, GROUP, NETTEMP NETOBJ.
> * EXECUTE: FD.
> * GET_PERMISSIONS_DATA: FD, DEV, USER, GROUP, IPC, SCD NETOBJ.
> * GET_STATUS_DATA: FD, DEV, USER, PROCESS, IPC, SCD, GROUP, NETDEV NETOBJ.
> * IOCTL: DEV, FD, IPC NETOBJ.
> * LINK_HARD: FD.
> * LISTEN: FD, IPC NETOBJ.
> * LOCK: FD.
> * MAP_EXEC: FD.
> * MODIFY_AUTH: ALL
> * MODIFY_ACCESS_DATA: FD.
> * MODIFY_ATTRIBUTE: ALL
> * MODIFY_PERMISSIONS_DATA: FD, DEV, USER, IPC, SCD, GROUP and NETOBJ.
> * MODIFY_SYSTEM_DATA: DEV, PROCESS, IPC, SCD, NETDEV and NETOBJ.
> * MOUNT: FD DEV.
> * NET_SHUTDOWN: FD, IPC and NETOBJ.
> * READ: FD, DEV, USER, IPC, GROUP, NETTEMP NETOBJ SCD.
> * READ_ATTRIBUTE: ALL
> * READ_WRITE_OPEN: FD, DEV and IPC.
> * READ_OPEN: FD, DEV IPC.
> * RECEIVE: FD, PROCESS, IPC and NETOBJ.
> * REMOVE_FROM_KERNEL: FD, SCD DEV.
> * RENAME: FD, USER GROUP.
> * SEARCH: FD, USER, GROUP, DEV NETOBJ.
> * SELECT: FD.
> * SEND: FD, DEV, PROCESS, IPC NETOBJ.
> * SEND_SIGNAL: PROCESS.
> * SHUTDOWN: SCD (#only other#).
> * SUPERVISOR:ALL
> * SWITCH_LOG: SCD.
> * SWITCH_MODULE: SCD.
> * TERMINATE: PROCESS.
> * TRACE: PROCESS.
> * TRUNCATE: FD.
> * UMOUNT: DEV FD.
> * WRITE: FD, DEV, USER, IPC, GROUP, NETTEMP, NETOBJ SCD.
> * WRITE_OPEN: FD, DEV e IPC.
>
> 2009/1/12 Javier J. Martínez Cabezón <tazok.id0 en gmail.com>:
>> I'm writting some documentation on myself in spanish to one webpage.
>> If you like I could tell you my opinion. The SELECT right should be
>> explained deeply, I think that in 1.3.7 is useless as it covers only
>> rsbac_rc_select_fd_create_type unless it's related with
>> def_fd_ind_create_type. If this is right it should be documented a
>> bit. I remember one sftf post related with passwd and shadow created
>> type. Could exists more. I will tell you later.
>>
>> 2009/1/12 Amon Ott <ao en rsbac.org>:
>>> Hello again!
>>>
>>> Some of you might have noticed that we have uploaded the 1.4.0 release to the
>>> Webserver. Before we make the big announcement there is still some work to do
>>> for the online documentation.
>>>
>>> Please have a critical look at the RSBAC handbook, which you get through the
>>> Documentation link at rsbac.org. Are the texts consistent? Do they explain
>>> what you want to know about their topics?
>>>
>>> We really want to make RSBAC easier to use with good documentation. So we
>>> always need people who can invest some hours per month on the documentation.
>>>
>>> Amon.
>>> --
>>> http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
>>> _______________________________________________
>>> rsbac mailing list
>>> rsbac en rsbac.org
>>> http://www.rsbac.org/mailman/listinfo/rsbac
>>>
>>
>
More information about the rsbac
mailing list