Re: RSBAC documentation

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 <[email protected]>:
> 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 <[email protected]>:
>> 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 <[email protected]>:
>>> 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
>>> [email protected]
>>> http://www.rsbac.org/mailman/listinfo/rsbac
>>>
>>
>