Previous Entry Share Next Entry
SELinux versus
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 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.


execstack -c /lib64/security/

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

  • 1

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.

  • 1

Log in