Blog
SecuringAIX

« What Good Are Intentions? | Main | Securing AIX Has Moved, Please Update Your Bookmarks »

July 14, 2014

Comments

Hello Michael,

as you probably already know we tested RBAC and now implemented it now on our first rolled out AIX 7.1 test systems. We have now 3 roles in place for us as administrator’s. next part will be implement more roles for application users.
Yes they meet our expectations. But keeps things going together with the audit subsystem is a struggle, most likely for a bug here.

Greetings Christian.

The problems with RBAC are:

1. So few people understand what it is (like Cloud).
2. The AIX RBAC is totally different than Linux and so it is difficult for customers to create a single standard.
3. Many backup utilities such as tar can strip-off file labels etc, and this causes problems.

Most customers just want LDAP Sudo because it is easy to understand and maintain.

I do use seLinux occasionally but find that you have to disable it, install and test your software, and then re-enable it so you can then find out if anything breaks.

Hi Andrew,

Thanks for your comment.

1. When I talk with customers about RBAC - I try to get the message across that what we should be talking about is simply "AC" - Access Control. Role Based is simply an approach, as is SUDO. Ease of use is certainly important - but more important - or at least growing in importance is: does "it" get the job done?
2. Linux claims to be "Linux", but this weekend I was trying to do something real simple and build a small BIND (DNS) server on "Linux". Had to learn about apparmor and forget about sysconfig. Every Linux approaches system administration differently. (I have no problem with that - UNIX (AIX, HPUX, Solaris, etc. also approach that all differently). My complaint is that they put so many controls to applications in "other places" - so even though you have a valid configuration, in application terms - it still does not work.
p.s. congradulations on actually "activating" SELinux. Everyone else I know has it "turned on" (yes, we use it!) but in passive/monitoring mode only.
IMHO: a single-standard is a "pipe-dream" - largely because technology is on the move faster than we can standardize administration. I think the focus should be on getting an executive-level risk assessment established and then implementing the best solution for the indivdual application or task. (Noone expects to handle all their business with a single (standard) database (application).)
3. I have no idea what is favored in Linux these days - but as far back as I can remember (1979) the only way to really keep system information is to use the OS backup/restore utilities - as they are built to capture the OS specifics that tar, cpio, etc. cannot. (Do not forgot, tar was a program to "improve" ar that could only write to files and a specific mini-tape-drive back in PDP-11 days! - where tar was written with a different storage format to backup large(r) amounts of data.

Many thanks for your comments!

Michael

Hi Christian,

Thanks for sharing.

Would love to know more about what is working! Likewise, I would like to know what is not working - maybe I can help (in the background).

Michael

I evaluated AIX RBAC a 2 or 3 years ago and at that time I've decided not to use for the follwoing reasons:
- Not granular, we could allow a user to run an specific command but not the flags associated with that command;
- not centrally managed, I would have to produce the rules in one server coy it to another server and then apply them; When you have a few server that would be fine but for big implementation that would be a challenge;
- No clear startegy from IBM on what regards high privileged command management. I've reached IBM at that time to ask what were their strategy and it was none.
So, until I can simply replace my sudo rules by RBAC I would not adopt it.

Thank you for your comments Jackson.

Not granular. As far as command options goes, I suppose that is still true. And if you comment about strategy is about command arguments you may still be correct there as well. However, if you mean something else, please comment again. MAYBE I can chase someone down who is responsible for that.

As far as not centrally managed that is a no and a yes. There has always been the ability to distribute RBAC policies via LDAP. The default activity is to update policies every 5 minutes from a master (so even if the get changed locally, they are rolled back to the master view). However, if you are not able to use the AIX LDAP server (as it's schemes are needed for this) then it is more difficult.

Some time back I was not familiar enough with SDS (was ITDS aka Tivoli Directory Server) to know that it "could be" done - using the AIX LDAP client to connect to one LDAP server for user authentification based on rfc2307 while also connecting to an "AIX only" LDAP server for RBAC and TE settings. Why two servers? 1) Many customers already have a directory solution for Windows (and growing Linux based on rfc2307) for user related information - and these either cannot support, or the vendor has stated they will stop supporting if there LDAP server scheme gets updated.
So, back again re: not centrally managed - I have to say no - the ability has always been there; but yes - too many have chosen to not use LDAP for anything more than user identification and authentication.
However, we are nearly 7 years further down the road in using LDAP for system administration. Maybe the time is coming that more poeple that it is possible.

Michael

Michael,
There are some interesting comments here and they show that RBAC is not only a complicated concept, but there is no simple way to implement it in AIX.
I also agree that you can place rules in LDAP, however LDAP simply stores anything you ask it to. There is no sanity checking or validation so if you create a "bad" rule, it is simply replicated across your estate.
I speak regularly with customers that wish to implement RBAC but just don't know where to start. In my opinion it is only "Role-based" when a role is an object e.g. "can enter the building", or can "access the canteen". You build a personal role by combining the roles e.g. all contractors can enter the building but not use the canteen, so to make a staff role, you add "can enter" + "can use the canteen". This then means if you changed the passcode or key for the building, everyone with the "can enter" role would be automatically informed/updated, because that object was part of their role.

Hello again.
I can only agree that comprehensive access control is difficult.
RBAC however, is not synonymous for AIX. RBAC for AIX is simply the current state of an RBAC approach.
A brief step back in time - just like ACL's the difficulty of configuring access control is/was compounded in that each OS has it's own implementation. NFSv4 ACL's offered some relief, but a not a comprehensive solution. In short, there is no easy answer - nor do I expect one (soon).
Re: where to start. The most important advice is to start. Where is less important. My advice for AIX would depend on a reply to a series of questions about where the most pain is. In the absence of any dialogue: As far as RBAC for AIX is concerned, start with the second set of roles provided. The first roles, imho, were not good models. A role like isso is needed in any case. (FYI: this second set of roles were engineered to be similar to like-named roles in other RBAC systems (HP-UX and Solaris are other names I heard). Sadly, I cannot verify how similar or dissimilar they are (maybe you can!).
"The start" will probably not be perfect - but that is why they are a starting point. Do not let fear of an imperfection prevent taking any action!

In a word, get experience. And then - learn from your experience. And when something is not working do not throw the baby out with the bath water - delve into what is not working and apply what you have learned. Also, rather always, keep asking: "What are my 'access control' requirements?"

Perhaps, rather than start from the system administration perspective - with the roles provided - look at what needs to be controlled from an application management perception and design your own application access control hierarchy (access model) aka authentications and assign access requirements to programs and/or files, devices, etc.).

As a (relatively) simple start I wrote up the basic steps - How to integrate applications into AIX RBAC - http://www.ibmsystemsmag.com/aix/administrator/security/rbac_applications/) that could be used to provide more security for an application such as Apache httpd.
As a second example (Using RBAC with scripts: http://ibmsystemsmag.blogs.com/securingaix/2012/11/using-rbac-with-scripts.html) I showed, perhaps in the wrong way because it was doing something as root, that a ksh script can be brought under RBAC managed elevation.

Lastly - Roles implemented as OO.
I do not disagree - that could be a way. However, RBAC for AIX not being OO should not be an excuse for not using it. In a person to person discussion I would want to discuss the chicken versus the egg dilemma.

When I first started toying with RBAC I was disappointed because I thought and acted as if it was about having the right roles. I feel I have corrected a beginners error. Creating roles is easy - once you have the correct "can do" classes defined. Under RBAC for AIX the objects are not the Roles, but the files, devices, programs themselves. And, as an object they can assigned "access requirements" that enable another identity (aka object, e.g., the user) to access, or prevent access - based on having, or not having the required attribute.
Within RBAC documentation they do not use the OO model - instead they use the key-ring model - where the role is a collection of keys and the secured objects have locks that can be opened and, depending on the lock opened additional privileges may be activated.

So, getting back to the start - access control, whether it is role-based, SELinux, AppArmor, sudo, etc. is never going to be simple. If it was - through any mechanism - we would not be having this discussion :-)

The comments to this entry are closed.