Bypassing RBAC with SU command ?

[evilangel]

Hi all,

I am wondering of protecting an integrity database (tripwire) with RBAC.
The aim is to protect the integrity database, so an attacker wouold not change the integrity database after he changed something on the filesystem of the server he attacked.

So i would configure my database to be modified only by tripwire process.

However, on a Linux, Root is able to switch its identity under the one he likes.
Then, RBAC continament is useless no ?
If root can be who he wants to be...

[cormander]

If you make the tripwire database only readable by the tripwire process, and not anything else under the default role, you should be fine. The RBAC system is designed to disallow even root from doing things you don't want.

[evilangel]

RBAC do not disallow the SU command, right ?

Therefore, root can be the user it needs to be, no ?
If something is only accessible for the user X, then root switch to the identity X.

[cormander]

Here is how you would setup the policy. Under the default role, do:

/path/to/tripwire-binary r

This makes the binary read-only, not even root can modify it. Right under it, do:

/path/to/tripwire/database h

This makes the database hidden, even from root. Then, in the default role, you add a subject:

subject /path/to/tripwire-binary
/path/to/tripwire/database rw

This makes the tripwire database read-write to only the tripwire binary, which root can't modify.

[evilangel]

Thanks Cormander for info.

I think i misunderstood RBAC.

I thought that RBAC "linked" a file to a profile (eg:root, alice, bob,...)
Eg: Only Bob is allowed to modify Bob's file, and no one else (not even Root).

Thus i was wondering of the SU command, allowing root to switch to another profile. (and so breaking RBAC)

However, according what you said, i understood something different.
RBAC "links" a file to another one.
Eg: tripwire binary and tripwire database, who ever is the owner of both files.

Am I right ?

Thanks

[cormander]

In a way, yes. The RBAC system is based on a policy file, which is one large access control list. You define what processes do what that other files; ie read, write, and execute (among other things).