Re: RSBAC documentation

Michal Purzynski <[email protected]>
Newsgroups gmane.linux.rsbac
Organization RSBAC Team
Message-ID <[email protected]>
if that flag is set, user has to authenticate himself to the UM before
switching role.
works with UM only - by design.

On Mon, 12 Jan 2009 16:29:45 +0100, Javier J. Martínez Cabezón
<[email protected]> wrote:
> 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
>>>>
>>>
>>
> _______________________________________________
> rsbac mailing list
> [email protected]
> http://www.rsbac.org/mailman/listinfo/rsbac
-- 
Michal Purzynski
RSBAC Team

_______________________________________________
rsbac mailing list
[email protected]
http://www.rsbac.org/mailman/listinfo/rsbac
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.