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

I must agree on the documentation / learning curve issue

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

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.

  • 1

Log in

No account? Create an account