trying out older (read-only, noexec, mount) security methods

[James Wilkinson]

I wrote:
> A read-only /usr sounds like more trouble than it's worth: it *will*
> break yum updates. So you'll have to regularly remount it read-write
> (while the system's on-line) to update the machine.

Tim replied:
> Yes, that had been on my mind.  I don't know if anything else writes to
> it. 

If it does, it's not compliant with the FHS (Filesystem Hierarchy
Standard) to which most Linux distributions aim:
http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
says:
    /usr is shareable, read-only data. That means that /usr should be
    shareable between various FHS-compliant hosts and must not be
    written to.

Except for stuff like yum, apt, rpm and make install, if it writes to
/usr, it's a bug (or possibly an installation error if it isn't
installed through RPM).

> Well, I've found my first problem:  Mounting /var with "noexec" means
> that CGI scripts won't run for the web server.  Took me a few minutes of
> headscratching to realise what had gone wrong, as is the way when the
> problem happens some time after a change.  I've temporarily removed
> "noexec" while I consider if I should move the /var/www/cgi-bin/
> directory out of /var.

Well, that explains why I haven't found the problem...

FHS suggests /srv instead of /var:
http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
says
    /srv contains site-specific data which is served by this system. ...
    so that services which require a single tree for readonly data,
    writable data and scripts (such as cgi scripts) can be reasonably
    placed.

I don't know if SELinux has rules for it yet.

Hope this helps,

James.

-- 
E-mail address: james | My friend, you would not tell with such high zest
@westexe.demon.co.uk  | To children ardent for some desperate glory,
                      | The old Lie: Dulce et decorum est
                      | Pro patria mori.    -- Wilfred Owen