RBAC on AIX: Why Bother? Part 2

In a previous post, “Role Based Access Control: Why Bother?” I state that a driving reason to adopt RBAC as the primary access control mechanism lies in inherent weaknesses of Discretionary Access Control (DAC). To clarify one point, the core weakness is not that the owner of objects can modify who can access an object. This aspect can be used to establish “data ownership.”

The greater weakness of DAC is the “all or nothing” level of access that’s granted using SUID—set (effective) user ID. When a kernel privilege is needed by a program to start and/or operate, that program must execute as SUID 0, or you must already be EUID 0 when you start it.

Use RBAC to Manage Access Control and Related Privileges

In other words, the key issue is that to do many “regular” things, access to root is required on a legacy UNIX—and RBAC provides a relatively easy way to delegate both access controls and the privileges required with any code-change to (most) applications.

Using RBAC: A Simple Example

An example is perhaps the simplest way to understand the advantage of using RBAC versus relying on procedures that require access to root aka super-user privileges for administration of an application.

HTTPD is a very well known service. The Apache Software Foundation (ASF) version uses a file named httpd.conf as a starting point to configure the server. Some key directives that require root access are the ones to connect to port 80 (port numbers < 1024 require kernel privileges) and to set a non-root user/group ID for data ownership. Other privileges are likely needed as well. ASF also provides a script named apachectl to assist with starting and stopping the httpd service. Since the service is running with a unique ID (i.e., different from the administrator) a kernel privilege is needed to stop the service. Using AIX and RBAC can permit “apache control” without needing access to obtain a super-user level of privileges. Instead, AIX and RBAC permit the configuration of the so-called Least Privilege Principle (LLP).

I am going to skip over some explanation, but you can see the links above for short/detailed explanations. Instead, I am going to give some commands needed to implement a role that can be assigned to a user so that httpd can be controlled (start/stop) by a non-root user.

Steps as Root

In case you’re wondering—“Can this be done without being root?”—the answer is yes. This is one of the details I am passing over for today.

• Install httpd (I have a recent version pre-packaged for AIX at http://dl.aixtools.net/httpd. You will need four packages: ASF.httpd, ASF.apr, ASF.apu and aixtools.pcre. The download links also include version numbers.)
• Make user and group httpd.
• Edit /etc/httpd/httpd.conf to use user/group httpd (rather than daemon).
• chown -R httpd:httpd /var/httpd
• Create an httpd_op user.
• ln -s /opt/httpd/sbin/apachectl /usr/sbin/apachectl # for ease of use – optional.
• Start/stop httpd to test it works when started as root.

As httpd_op:

• Log in.
• Try to start apachectl—it will fail.
• Echo $$ # this is your PID—process ID number, you need an increase in authority to trace privileges.

Back as root:

• Elevate httpd_op shell to root level—assume PID is 6357222

# setsecattr -p iprivs=PV_ROOT 6357222.

Back as httpd_op:

• Use command tracepriv to start/stop /opt/httpd/sbin/httpd.

Back as root:

• Make authorizations: mkauth aixtools; mkauth aixtools.httpd; mkauth aixtools.httpd.opr.
• Set authorization and related privileges to /opt/httpd/sbin/httpd.

# setsecattr -c \ authprivs=aixtools.httpd.opr=PV_DAC_R+PV_DAC_W+PV_DAC_X+PV_DAC_O+PV_KER_RAC+PV_NET_CNTL+PV_NET_PORT+PV_PROC_SIG \
/opt/httpd/sbin/httpd

• Make the apachectl role

# mkrole authorizations=aixtools.httpd.opr dfltmsg=”Apache HTTPD Operator”

• Assign the role to user httpd_op

# chuser roles=apachectl httpd_op

Back as httpd_op:

• Logout and login again to drop super-user shell and get access to new role.
• apachectl start—will fail this time
• swrole apachectl
• apachectl start—succeeds
• Verify success.

$ netstat -tn | grep 80 | grep LISTEN

There's more, obviously, and it shall come either in articles on rootvg.net and/or my blog on IBM developerWorks. However, I hope the key reason for looking at RBAC is clear: You need neither root access nor super-user privileges on AIX when an application is integrated with AIX RBAC.

Comments

[Ste Jones]

I'd like to use RBAC to provide read access to say everything under /myapp/*. Is there a way to do this? I can only see a way to list every file and in this case there are thousands so it's not an option.

[Rydekull]

Answer to previous post:
You do that best with file access control lists(ACLs).

See for example: http://www.aixmind.com/?p=472

[Michael A.M. Felt]

Rydekull:

A file access control (ACL) could be used—but I would try to stay away from ACL for this unless it is meant to be only for one person—and again, set the ACL at the directory "entry point," or you still have to "aclput" 1000's of files and directories.

Why avoid ACL? Because they are an enhancement of legacy DAC, not a "evolutionary" step as RBAC can be (can be because it does require work to get it right, and works better with TE (Trusted Executition) enabled.

Please note: over time ALL of this will be covered—but it is too much for one blog.

Keep commenting because your comments steer my priorities in what I write, or finish writing, for the next blog.

FYI: The next blog will probably revisit syslog and audit—now looking at basic configurations.

[Michael A.M. Felt]

Ste Jones:

This is why there is nothing wrong with "world/other" access rights. I would make sure the group rights are all cleared, and set world read rights to read-only.

And the "entry point" I would set a RBAC setting to permit "accessing" the directory .../myapp/

And, in this case I would probably use a feature I did not mention in the BLOG—RBAC Domains (setsecattr -o option)

Domains are great because they function separate of authorizations or roles (in fact, they are intended as a means to control the scope (aka domain) of an RBAC authorization.

Thanks for the comment!

[Michael A.M. Felt]

Extra footnote: IF I was going to use ACL's I would definitely consider the EAv2 over v1 as the article in aixmind recommends. But in all things, test that they do not break things. I recall there were concerns about compatibility. More to the point, as far as ACL technologies go—ACL mechanisms are generally incompatible. EAv2 and NFSv4 ACLs are the exception—as EAv2 was designed to be compatible with NFSv4 ACL.

[Rydekull]

Michael:
NFS4 ACLs gives you inheritance of access rights which is the most important part other then the granular control.

I agree that the drawback of ACLs is the initial configuration on already existing filetree. However, this can easily be sorted with tools like find.

[Michael Felt]

Inheritance is good! AND there are more attributes than just rwx. AND they will be useful in many situations. BUT, they will never help with LPP (least priv. principle) or remove SUID/SGID.

I firmly agree that effective security management is not applying "a" mechanism, but the right mix.

By itself, RBAC does not solve anything. Done wrong it can make things worse - as can any mechanism.

In short, I am not trying to disagree with you. I am sure there will be situations where EAv2/NFS4 ACL's may be a better solution; however, right now I am on a soapbox touting the benefits (as opposed to features) of RBAC. At least, I hope I am :)

[chris dove]

If possible how would you setup a superuser role to manage a specific group of users?? Effectively root for just that group and its users
The role would need the ability to chown or chmod files, Kill processes...etc for any user in the group.

[Michael Felt]

By default, an authorization is effective system wide. Your question was a common concern/problem for actions such as chown/chgrp that act on "filesystem objects". To solve this problem an additional qualifier known as "RBAC DOMAINS" can be used.
Domains are used to specify where authorizations are permitted (only in the domain) or denied (everywhere but this domain).
A combination of the two (deny domain within a permitted domain.) is also possible, but I recommend against the added complexity.
There is no "domain" limitation for processes once activated - so kill() would be permissible for any process euid.
In summary, authorizations that act on file system objects has a fairly straight forward solution. Just define a role, perhaps using new authorizations as in the example above; create a domain; move user files into domain.
(I always discuss using a deny domain instead/additionally as a means to simplify administration.)
Managing user accounts and processes - not being tied into domains - will be more difficult/complex.
You may want two roles: one for changes made to account information in /etc/security and killing processes, etc. and for all users (i.e. including so-called admin accounts).

[Michael Felt]

Chris's question is more intriguing than I could have hoped for - read, not as simple as I first thought/hoped.

I have some ideas I am working on and will be exchanging ideas at TechU in Dublin next week.

Hope to see you there!

[Michael Felt]

Back from Dublin. Was an interesting experience.
Got some help with debugging my article http://www.ibmsystemsmag.com/aix/administrator/security/rbac_applications/ (How-to Integrate Applications Into AIX RBAC)
The typos are corrected.
Note the chsec command to change the list shells (add /bin/false) is meant to be a single line. Do not get too many additional spaces in your string or mkuser command will fail all the time!

Hint: If you follow the article as the example, and you have questions and/or comments - just add them here. They are related!

[Ryan]

One issue I have with RBAC is back tracing the authorizations.
Using your httpd example, lets say a x months transpired. How would you know that user X has permission to run httpd? lsrole, lsauth may show what authorizations a user has, but that doesnt clearly show what those authorizations can execute.
It's real simple to see that in sudo.

[Michael Felt]

Thank you for your comment - and question. I have been trying to pick a good subject for my overdue blog.

The command you need to look at is:

rolerpt -c role
rolerpt -f role
rolerpt -u role

role can also be "ALL"

The command "authrpt" is similar.

[Ryan]

using your example above, it seems assumed that userA and userB would need to su - apache_op then use swrole apachectl role.
setuid aside, I dont see the benefit of doing this vs userA and userB just run 'sudo apachectl start'

Otherwise if you give userA and userB access to the same role, if userA starts http using the RBAC role, userB will not be able to stop it using the same RBAC role. This seems to be a design "feature" that is lacking.

[Michael Felt]

Hi Ryan,

Thanks again for your comment. I apologize for any misunderstanding caused by my using su (from root) to become httpd_op. Laziness in an example got the better of me again.
1) httpd_op is just an account. The name could also be userA, userB, michael, ryan, etc. Just assign the role to the user, and the user can swrole to the role and with that role, start/stop httpd (from this example).
2) In many ways using a role based system is similar to sudo, or vice versa. The difference is that sudo is always elevating to "PV_ROOT" like privileges while a role based system should be elevating only the minimum privileges needed to accomplish a task.
3) all users with the role can start/stop without concern of the status of the other users with the role. (If this is not the case I made a mistake and need to correct it!)
4) I am curious why you think that if userA starts a process userB cannot stop it (using the same role). Understanding this will help me write my next article better.

[Ryan]

Add userA and UserB to the apachectl role. Have userA start httpd. Try to have userB to stop httpd (swrole assumed on both). This will fail by design according to IBM. I opened a PMR and sited your example. They were able to reproduce the issue.
Their 'working' example was using startsrc/stopsrc where userA runs startsrc and userB can successfully stopsrc. I believe they cheated as they mentioned that both of their example users needed to be in the system group for it to work.

[Michael Felt]

I do not have my example loaded so I cannot test adding the apachctl role to userA and userB and start/stop as you suggest.
That said, I disagree emphatically with whoever stated that this is by design (that userB cannot stop what userA has started). If that is true, then, imho, the design is broken.
If my example is broken - I think you for pointing that out - I shall fix it asap and report the results; steps needed.
Phase one will be to create two roles: apache start, and apache stop. The whole idea of privileges is that they work "both" directions, without regard to real user ID (RUID) values.
At least, that would be MY "design" principle.

[Michael Felt]

:blush:
Thde error is mine!, as I had tested userA/userB while prepping the article, but did not test the article text well enough - just userA/userA

Thanks Ryan, for pointing this out!

The setsecattr command needs one more privilege: PV_PROC_SIG so the command for the example should be:

# setsecattr -c authprivs=aixtools.httpd.operate=PV_DAC_R+PV_DAC_W+PV_DAC_X+PV_DAC_O+PV_KER_RAC+PV_NET_CNTL+PV_NET_PORT+PV_PROC_SIG
accessauths=aixtools.httpd.operate secflags=FSF_EPS /opt/httpd/sbin/httpd

be careful of formatting mishaps with the text here!

[Ryan]

Issue resolved! Turns out that i missed running 'setkst' sometime after appending PV_PROC_SIG. IBM missed it too, so i don't feel too bad. Thanks again for the help!

I did notice that apache seems to ignore the 'User/Group' stanza in the httpd.conf file that it's supposed to fork off as this user/group. This still needs further investigation.

[jim]

Hello,
I'm working on implementing RBAC to replace direct root access for administrators.

Initial tests of an unprivileged user have had success with me assigning auths and such to enable that user to run privileged commands and also use pvi to edit files like /etc/hosts and /etc/inittab.

My questions come with the following problems:
1) When wanting to edit /etc/inittab, my new admin user would like to make a copy before editing the file. The role doesn't seem to allow the roled up user to create the new file. How can I enable that type of functionality?

2) We have a few hundred servers and use a home-grown script to administer all machines with a single command line entry. That process uses ssh and root keys on all the machines. Initial tests are having problems making this kind of "remote" administration work. Any suggestions there?

[Michael Felt]

dear jim,

I see I owe you an apology as I have not replied.

re: your first question, read/write authentifications are difficult - actually, only pvi seems to respond to these. normal commands such as cp do not recognize RBAC authentifications.

For your scripting, I will need at least more time - off to catch a plane atm. But I shall be looking into it - even if only to come back with question.

Michael