« Are You Sure About Your AIX Security? | Main | How to FAIL a Security Audit »

September 04, 2012


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.

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

See for example:


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.

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!

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.

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.

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 :)

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.

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).

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!

Back from Dublin. Was an interesting experience.
Got some help with debugging my article (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!

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.

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.

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.

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.

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.

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.

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!

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.

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?

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.


The comments to this entry are closed.