Browse Prior Art Database

System and method for Relation based command execution

IP.com Disclosure Number: IPCOM000186029D
Original Publication Date: 2009-Aug-06
Included in the Prior Art Database: 2009-Aug-06
Document File: 5 page(s) / 121K

Publishing Venue

IBM

Abstract

The system and method for relation based command execution introduces new database file named as /etc/security/relationships which defines the relationship between commands for each privileged command listed in /etc/security/privcommands to avoid security violation by executing subcommands from super command. This method avoids the execution of subcommand having more than required priviliges to run it.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 50% of the total text.

Page 1 of 5

System and method for Relation based command execution

Role Based Access Control (RBAC)

provides for a mechanism in the operating system through

which the root/system super user specific system functions can also be managed through regular users using the roles assigned to them. Privileged commands are those which can be run by authorized users by virtue of authorizations/roles assigned to them. In AIX, the privileged commands are listed in the /etc/security/

privcmds database.

The Problem:

All the subcommands called from a super command get all subcommand priviliges rather than

just the specific priviliges required by that particular subcommand. For example, command

"CmdSuper" calls subcommands sub

_command1, sub

_command2, and sub

_command3. Assume

sub

_command2 requires privileges p1 and p2; sub

_command2 requires p2 and p3; and D

requires p4. With the current approach, sub

_command2 gets all of the privileges p1,

p2,

p3,

p4

instead of just p1 and p2. sub

_command2 and sub

_command3 also get all the subcommand

privileges. This leads to a problem of subcommands getting the more than the minimum

privileges.

In AIX, Assume a command CmdSuper which executes several subcommands sub

_command1,sub

_command2,sub

_command3

CmdSuper: accessauths = auth1 innateprivs= innate

_

p

             riv1,.... inheritprivs =

p1,

p2,

p3,

p4,

p5

sub

_command1:

accessauths=inherit

             auth1 innateprivs=

p1,

p2

_

sub

_command1 needs p1,

p2

sub

_command2 needs p3 ,

p4

sub

_command3 needs just p5

It would be required to give accessauth (Authorization required to execute privilige command) of CmdSuper and give PV

_AZ

_ROOT (Special privilege which by passes all access checks for

subcommands) as innateprivs so that this command would by pass access checks and give all the required inheritprivs which would enable to execute other commands in the privcmds DB.

This would lead to a scenario where the subcommands sub

_command1, sub

_command2,

sub

_command3 would get more than their desired set of privileges i.e. all the commands

sub

_command1,sub

_command2 and sub

_command3 would get all the privileged priv1,

p

riv2,

p

riv3,

p

riv4,

p

riv5.

1

Page 2 of 5

Existing solution:

To solve this problem, AIX people proposed a different approach. This introduced Authorized Authorization Sets (AAS). Assume that Authorized Authorization Sets exist in /etc/security/

privcmds as follows:

_

_auth1, intherit

If it is present the subcommand would get its innateprivs from /etc/security/

proceed with execution. Otherwise it fails

Problem With existing Solution:

Even this scenario has a flaw in that one authorization can map to N subcommands. Let's say inherit

_auth1 has commands sub

_auth1 the command can execute more than the desired command i.e all the n commands

which could lead to a security shortcoming.

Example:

A command mkdev calls lsvg, lspv but not lslv or say for auth...