Sunday, April 04, 2004

RBAC and U . . . RPID

Fun with Security

I'm bored again. Putting my filesystem aside, ANLFS aside, my P2P design aside, everything aside, I'm working on something bigger.

http://usrbac.sf.net is the homepage of USRBAC, an implimentation of the RBAC standard developed by NIST (particularly, Rick Kuhn). USRBAC is a three part project. The first two parts, KURBAC and rbacd, work together to allow the kernel to use a userspace daemon as an access control system, with the goal being full RBAC compliance in the rbacd. The third part is what I'm most interested in, and starts only after rbacd is finished.

The third part is called URPID, or User-Role Profiling for Intruder Detection. It gathers data about a user during a session and profiles the user with it, then uses this data to sort of fingerprint the user. The goal is to anylize many aspects of the user and set off a security fault if the user appears to not be the owner of the account.

The very first URPID module is going to be urpid_hitmiss. A "Hit" here is defined as attempting a permissible operation, i.e. performing an operation on an object when you are allowed to perform that operation on that object. A "Miss" here is defined as attempting a nonpermissable operation, i.e. performing an operation on an object when this permission is not granted to you by any active role. The Hit/Miss analysis takes three pieces of data into account:

- A Base Tolerance: How many times can the user "miss" before we question his identity?
- A Hard Tolerance: What percent of the user's activity can be "misses" when he's suspect of being an account hijacker?
- Permission Checking: How many times has the user hit, versus how many times he hit?

The basic concept is that until the session has [Base Tolerance] misses, hits and misses are just counted without any concern. Once the [Base Tolerance] is reached, each miss results in a computation of the percentage of misses out of all tallied operations. If during any of these computations the percentage falls above [Hard Tolerance], a security fault is raised.

When a security fault is raised under URPID, the user's session is locked (all processes are frozen/paused). The user's console is watched for the CTRL+C control to be passed, and if it is passed, the user's session is killed. We call willful killing of one's own session during a security fault "Submission."

To resolve a security fault without submission, a given number N of users from a given role R must assert that the user in session S is in fact the given user. If any users in role R cast doubt (vote no), the session remains frozen until those users remove their doubt. If N users in role R assert that the session is not hijacked, and nobody casts doubt, the session is marked as being known to be posessed by the user, or "Clean," and no further security faults are raised for the session (except for modules that may raise faults in known clean sessions, such as those that would halt dangerous/destructive operations and call for authorization). However, if N users in role R assert that they do NOT believe this is the user, the session is terminated. If both sides reach N votes from role R, the session remains in deadlock until the user submits. If N votes from role R say the session is not clean, and less than N say the session is clean, the session is terminated.

When a session is terminated, by submission or by force, all gathered profiling data is discarded; no use profiling the user based on a hijacker's actions.

Hit/Miss tracking is theoretically effective if and only if the hijacker has little data about the user. In cases where the account is fully hijacked (all roles known, all passwords known, little to no security misess raised), this would be ineffective. Other modules must be designed to profile the users' activities and attempt to discover hijackers.

The URPID project is far off; I have to get KURBAC and rbacd working first. It will be a fun and interesting project for me.

This page is powered by Blogger. Isn't yours?