danwalsh


Dan Walsh's Blog

Got SELinux?


Previous Entry Add to Memories Share Next Entry
SELinux versus pam_securid.so
danwalsh
Seems to be my month for fighting pam modules from third parties.   I have heard that RSA corporation is recommending SELinux be turned off to run their products.  I just love it when a supposed security company recommends that customers turn on a key security component of the Operating System.  Now did RSA ever contact me to work through the problems,? No. 

Come on RSA you can do better then this. 

I am trying to avoid underhanded security comment about using SELinux to protect key assets of the company...

I worked with Joe Lucchesi, to get this pam module to work with SELinux.  Joe was having problems with sshd working with the pam module.  He was getting execstack errors.  Turns out the pam_securid.so file was shipped with the execstack flag turned on.  Execstack is a dangerous protection to allow a domain, since it turns off protection against buffer overflow attacks.  Most app never need this access.

Executing

execstack -c /lib64/security/pam_securid.so

Cleared the flag.  And allowed sshd to get past this AVC.  Whatever is causing this flag to be set, the build procedure or installation needs to be fixed.

The next problems we hit was pam_securid seems to be running netstat under the covers.  I recall we had this problem with the Netscape Certificate libraries. They used to execute netstat in order to generate entropy when using certificates, so I figure this is what is going on here.  I also see the sshd executing ps?  Probably  for the same reason.  

RSA guys please use /dev/urandom and /dev/random. 

We turned off the use of netstat in our libraries years ago.  Using netstat and ps causes me to have to allow login programs to search /sys/net and because of bugs in our kernel add a dontaudit for sys_ptrace.   

Finally secureid uses /var/ace to store its authorization content.  This should probably be under /var/lib/ace, I have added a label for this directory

/var/ace(/.*)?                 gen_context(system_u:object_r:var_auth_t,s0)

This should allow the pam_securid module to use the content in this directory.

Now Joe can run his pam_securid.so on his machine in enforcing mode with a small custom module until we push updates to fix the problem.

Bottom line.  If you are a third party and you are having problems running your tools with SELinux, please, please contact me or Red Hat and lets work through the problems, and give our users a better experience.

Oracle recommended to turn off SELinux for their databases for years - that is the first example that comes to my mind.

And I have been told that they no longer require this.

Also Oracle does not declare itself as a security company, and I am sure they could excuse it away by saying it gets better performance.

I have attempted to open a conversation with RSA to see if we can get this resolved.

The most common advice that I read concerning SELinux is “disable it”. I've never taken that advice, but I perfectly understand it.

When I first tried to deal with an SELinux issue, I went looking for documentation. What I found, exclusively, was stuff that made little sense unless one were already familiar with the topic — peculiar undefined terms, forward references, great lacunæ.

It was the sort of stuff that people write if they're well-versed in a subject yet inexcusably clueless about communication. So long as it is reviewed only by similar creatures, nodding and saying Yes, that's right!, it's basic flaw is never recognized by those generating it.

Someone with a very strong commitment would probably eventually squeeze some understanding out of it, especially with a bit of experimentation, but most people will just push it aside and not return to it.

In the face of this situation, naturally people say turn that sh*t off. It might be a bit surprising that RSA is amongst them, but that should simply tell you how awful the developers have left it to work with SELinux, with such rotten discussion.

At this stage, addressing the problem isn't just a matter of someone writing a better discussion (which may have happened by now); it's a matter of reversing the effects of not offering it earlier, by acknowledging the gravity of the problem, and giving that better discussion away in some very, very public manner.


I must agree on the documentation / learning curve issue

Sven Mueller

2011-12-13 08:13 am (UTC)

I really have to agree with Daniel here: When I last tried to get SELinux to work for me, I already knew about some of the concepts behind SELinux, but still, even after two weeks of my spare time (i.e. about 20 hours) of fiddling with it and trying to understand the documentation, I gave up.
I admit though that I was trying to understand the policies by building a small policy just for a rather simple application from scratch (app reads some stats from /sys and /proc, accepts a tcp connection and writes out the stats to there). I "succeeded" in denying that application alone from doing anything, while allowing anything else to run without SELinux enforced restrictions, but that was it.
Oh well. I would love to really understand SELinux to the degree needed to configure it for custom applications, but I didn't have the time to dig into it for long enough, I guess. Or I didn't find the right howtos and docs.

Re: I must agree on the documentation / learning curve issue

danwalsh

2011-12-13 06:43 pm (UTC)

You might have wanted to look at sandbox.

My goal was not to have third parties write policies to confine their apps, while that would be nice, that is not my goal. My goal is to have them install their apps and work with others so their apps will work without requiring SELinux or any other security measure to be disabled.

By default apps that SELinux does not know about should work as an unconfined domain, but if you have a plugin, you need to understand a little about SELinux to make sure your plugin does not break with SELinux in enforcing mode.

i am afraid RSA JUST DONT CARE AT ALL mate :(

Hi Dan,

I've been tasked with installing the securid pam agent on a few of our RedHat 6.3 servers and your guide is what got me through the selinux hurdle.

However, I was wondering if you could clarify the following for me:

We turned off the use of netstat in our libraries years ago. Using netstat and ps causes me to have to allow login programs to search /sys/net and because of bugs in our kernel add a dontaudit for sys_ptrace.


I am asking because my messages gets flooded every time someone logs in.

thanks!

The nss package specifically libnss3 on Fedora 18 Not sure of the version on RHEL6 used to execute netstat, just to create random data for creating crypto keys. Red Hat version of nss does not do this. It uses /dev/random for its random data.

You are viewing danwalsh