Plans with RSBAC


From: ao@morpork.shnet.org (A. Ott)
Subject: Plans with RSBAC
Date: 07 Oct 1999 14:43:00 +0200

Next Article (by Date): Maint / non-maint dependency in ACL ao@morpork.shnet.org (A. Ott)
Previous Article (by Date): Re: Usage of RSBAC ? ao@morpork.shnet.org (A. Ott)
Next in Thread: Re: Plans with RSBAC Vadim Kogan
Articles sorted by: [Date] [Author] [Subject]


Hi all!

I'd like to discuss my current RSBAC wishlist with interested people like  
you. Please give comments and new wishes, if you need something else -  
this is another planning phase to keep me busy for a while... ;)

I currently plan to add or change the following (in time order):

- Add ACL groups:
  - Every user can define personal as well as global groups of users.
  - Groups have a group id (u_long), a name (16 chars), an owner (a uid)
    and a type (global or personal).
  - Every user can use every global, but only her own personal groups.
  - Every user can manage only groups owned by herself.
  - Group ownership can be changed (not sure yet), default is creator.
  - There is no overall group admin, because every user can do the job,
    e.g. secoff
  - One admin tool acl_group for all these functions.

- Do we need ACL menu tools, or are the command line tools sufficient?

- Enhance control of sysctrl access to prevent system configuration
  attacks

- Change RSBAC socket identification and access control:
  - Current socket id is hardly usable outside kernel
  - Currently only the use of local sockets is checked, regardless of
    destination
  - New socket ID contains IP (0.0.0.0 for all), port, protocol
  - Target IDs for IPC/socket contain two IDs: local and remote
  - RSBAC Socket objects become persistent, they won't be deleted when the
    socket is destroyed.
  - When a socket is derived from another (e.g. accepting a connection),
    attributes are inherited (decision module dependent, in adf_set_attr()
    call as usual)
  - CREATE and *_OPEN requests are still used for local socket creation
    and address binding, but not for connections and sending/receiving
  - Three new requests are used for the latter:
    - CONNECT, target IPC/socket with local and remote ID, connection to/
      from remote
    - SENDTO, target IPC/socket with local and remote ID, sending packets
      without connection
    - RECEIVE_FROM, target IPC/socket with local and remote ID, receiving
      packets without connection
  - Local loopback connections are treated like remote connections.
  - With this new structure, we get real access control for network
    communication, though still based on (rather insecure) IP and port.
    Difference to firewall packet filter: User, program and process state
    dependent.

- Based on the new socket scheme: Add socket attribute transfer on
  connection/packet sending with IP options

--
## CrossPoint v3.11 ##
-
To unsubscribe from the rsbac list, send a mail to
majordomo@morpork.shnet.org with
unsubscribe rsbac
as single line in the body.

Next Article (by Date): Maint / non-maint dependency in ACL ao@morpork.shnet.org (A. Ott)
Previous Article (by Date): Re: Usage of RSBAC ? ao@morpork.shnet.org (A. Ott)
Next in Thread: Re: Plans with RSBAC Vadim Kogan
Articles sorted by: [Date] [Author] [Subject]


Go to Compuniverse LWGate Home Page.