Setting up LAM Pro with SELinux

Been a while since I had to install LAM Pro and now that I have the new version, I ran into a couple of issues. First there is SELinux, which has saved my butt a couple of times, so I work to always have it enabled. I cringe whenever I see the first step in someone’s howto is to disable it. Its complicated and I do not profess to be anywhere near an expert in it, but I get by. Second is to secure the install, and while SELinux helps in that regard, there are still steps to take.


LAM Pro is the paid version of LAM, LDAP Account Manager. Starting with a fresh install of CentOS 6.4, I downloaded the LAM Pro source and use its install script:

# ./configure --with-httpd-user=apache \
              --with-httpd-group=apache \
# make install

By default it will install everything into /usr/local/lam and use httpd as user/group name. Here I fix that to use the CentOS default of apache as user/group. Also it’s recommend to separate the web interface from the more sensitive parts, like the config files and session information.

SELinux Configuration:

If you were to start up a browser to load up LAM, even with SELinux disabled, there is the issue of writing config files. They are stored in /usr/local/lam/etc, where the web server doesn’t have permission. Also there is the session and tmp directory in var it uses to cache data from ldap. So use chmod to fix that:

# chmod -R apache:apache /usr/local/lam/etc
# chmod -R apache:apache /usr/local/lam/var/sess
# chmod -R apache:apache /usr/local/lam/var/tmp

But with SELinux enabled, apache still doesn’t have permissions to write outside of its own root directory. We need to tell the system the right context to use to allow apache access.

# semanage fcontext -a -t httpd_sys_content_t "/usr/local/lam/var(/.*)?"
# semanage fcontext -a -t httpd_sys_content_t "/usr/local/lam/etc(/.*)?"

Next is to apply these settings to the files themselves:

# restorecon -R /usr/local/lam/var
# restorecon -R /usr/local/lam/etc

Now apache can run LAM with SELinux enable and not run into any issues.

Apache Configuration:

The next part is to secure the installation. LAM comes with htaccess files ready to use to protect the config files and other sensitive files. Its my preference and you can do it differently, but I start with creating /etc/httpd/conf.d/lam.conf to hold these directives.

<Directory /var/www/html/lam>
   AllowOverride All

Now you could just change the server wide setting in httpd.conf, but I like to follow the principle of least privilege.

Next would be to set it up to use SSL to keep prying eyes from grabbing your passwords and user information, but that’s a whole other topic.


Apache, SELinux, WebDAV, and cgi-bin

I had setup webdav access for a user to allow them the ability to upload and edit their web application and as part of that setup, they had their own cgi-bin. Not normally an issue, but as a way to prevent any security issues, I’ve kept SELinux enabled. Turns out this was causing a problem with uploading files into the cgi-bin directory. Sadly there wasn’t an easy boolean value I could set for this but the audit2allow command came in handy.

Now be sure you check the module code before enabling it to ensure nothing shady is there. Simply running audit2allow on all messages in the audit log would build a module that can include permissions to allow potential hacks through. I saw some weird permissions that I knew were not needed to allow webdav access to cgi-bin and removed them from the module file. Here is the module that finally allowed access to the cgi-bin directory:

module webdav-cgi-bin 1.0;

require {
type httpd_t;
type httpd_sys_script_t;
type httpd_sys_script_exec_t;
type httpd_sys_rw_content_t;
class dir { write remove_name create add_name };
class file { write create unlink execute setattr};

#============= httpd_sys_script_t ==============

#!!!! This avc is allowed in the current policy
allow httpd_sys_script_t httpd_sys_rw_content_t:file execute;

#============= httpd_t ==============

#!!!! This avc is allowed in the current policy
allow httpd_t httpd_sys_script_exec_t:dir { write remove_name create add_name };

#!!!! This avc is allowed in the current policy
allow httpd_t httpd_sys_script_exec_t:file { write create unlink setattr };

Now this allows the web server read/write access to cgi-bin, which might be an issue, but I do protect webdav access behind access controls and SSL.

Setting up Git on Apache+SSL+LDAP

I used the following post as a way to get things started.

Setup your repos. Adding the EPEL repo to CentOS will knock out some base packages, so as a rule, its good to setup priorities, but thats not part of this howto and can be found here. Anyways install git.

I decided to place the repository within /var/www/html simply because its my preference, but it could go anywhere.

mkdir -d /var/www/html/git/project

cd /var/www/html/git/project

git —bare init

Then I set the permissions so the webserver has ownership:

chown -R apache:apache /var/www/html/git

Then run update-server-info:

sudo -u apache git update-server-info

Next is to configure apache. Remember to have your SSL certs prepared before hand. Also each distro is different in how it lays out the apache configuration, especially in regards to extra modules like SSL and WebDAV. Consult your documentation.

First I make sure I have the modules I need set to load, such as SSL, WebDAV, and ldap(authz). I want all traffic to be encrypted so I set it to route all http requests to https:

<VirtualHost *:80>
        Redirect permanent /

Also I’m using LDAP with TLS so Apache needs to know the CA cert:

LDAPTrustedGlobalCert CA_BASE64 /path/to/cacert.pem

On a side note, its good to protect your webserver by hiding the version numbers via:

Servertokens ProductOnly
ServerSignature Off

Then I setup ssl, which for my system, its in /etc/httpd/conf/extra/httpd-ssl.conf I then setup the following virtual host:

<VirtualHost _default_:443>

ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log

SSLEngine on
SSLProtocol all -SSLv2
SSLCertificateFile /path/to/server-cert.pem
SSLCertificateKeyFile /path/to/server-key.pem
SSLCACertificateFile /path/to/cacert.pem
<Directory /var/www/html/git/>
        DAV On
        Options ExecCGI FollowSymLinks Indexes
        Deny from all
        AuthType Basic
        AuthName “Git Repository”
        AuthBasicProvider ldap
        AuthzLDAPAuthoritative on
        AuthLDAPURL “ldap://,dc=example,dc=com?uid” TLS
        AuthLDAPBindDN cn=binduser,ou=DSA,dc=example,dc=com
        AuthLDAPBindPassword password
        AuthLDAPGroupAttribute memberUid
        AuthLDAPGroupAttributeIsDN off
        Require valid-user

<Directory /var/www/html/git/project>
        Allow from all
        Order allow,deny
        <Limit GET>
                Require ldap-group cn=groupname,ou=group,dc=example,dc=com
                Require ldap-group cn=groupname,ou=group,dc=example,dc=com

Here authentication is handled by Apache against LDAP, which in our case is very nice as all our user information is in LDAP. Next on the client side you’ll have to set the username and password and the certificates.

To set the username/password for git to use, create a file in your top level home directory called .netrc and add the following:


login username

password password

Then to setup the certificates, download the CA cert and place somewhere, like ~/.certs. Then it must be in the x509 format, this can be down via the following:

openssl x509 -in cacert.pem -out cacert.crt

Then tell git to use this via:

git config —global http.sslcapath .certs/

git config —global http.sslcainfo .certs/cacert.crt

Now you should have a working git repository password protected and encrypted in transit.