Development Talk on changes to apacheconf.h and the security headers

These are really just notes for me, but will just about do as "slides" for the talk.

Overview

Several times in the past, it has been said that we should make things that are no brainers/uncontroversial on the list at:

https://wiki.inf.ed.ac.uk/DICE/SecuringWebServers

the default for all web services. That's what I want to talk about, and set a date for this to become the default.

The proposed changes are on the wiki page:

https://wiki.inf.ed.ac.uk/DICE/ApacheConfSensible

It lists the various changes in behaviour that will become the default, unless people choose to opt-out or configure differently.

The Sensible List

  • Go through list
  • Highlight the ones that have been "problems" for me
    • security - upload limit size, upload false positives
    • framing - plone
    • cosign doesn't cascade - more later

Possible Gotchas

During the transition, ordering may be an consideration for those with their web service in stable headers (www.inf).

eg if you do nothing until after the sensible headers become the default, and you want to SKIP one of the features, then you'll have to #define things in the machine profile before you include your stable service header. Or if your stable header includes a live header at the end of it, then it will be too late for the #defines to take affect, and so you'd have to undo the appropriate settings by hand, eg mREMOVE resources, or again put the #defines in the machine profile.

CosignRequireFactor doesn't cascade down. The current cosign.client_factor resource sets the CosignRequireFactor for the main server config, but VirtualHosts do not inherit this setting. They start with an empty CosignRequireFactor.

Should the _APACHECONF_COSIGN_VHOST macros in apacheconf-cosign.h be changed to set vhostfactor_TAG to the value of <%cosign.client_factor%> ? This will obviously only work for people who choose to use the macros when creating a VirtualHost.

When ?

When should the sensible options become the default for all users of apacheconf.h.

www.inf, homepages, wiki, blog, wcms are already using the sensible headers. Also computing.help by the looks of things.

If I were to change it today, then people would have a week to prepare, but only a couple of days if they needed to get things in stable headers. There are 14 profiles on develop using apacheconf.h, and 91 on stable!

How about I make the change this coming Monday, so people have a week and a bit to do any testing they need?

Other things that came up while I was prepping for this talk

live/apacheconf.h still includes shellshock_workaround.h. Once the sensible stuff is the default, then it is already in the apacheconf-security.h header, so we should remove it from live/apacheconf.h.

Should we make dice/options/apacheconf-2.h and dice/options/apacheconf.h equivalent? Currently they are not, and there are subtle differences for those services that are using just "apacheconf.h". eg some SSL settings are different. I happened to notice that computing.help doesn't use the "-2" version and misses some SSL settings. We could just drop apache 1.3 support altogether, or for those that must use apache 1.3, then they include apacheconf-13.h?

I wasted an hour debugging why something wasn't working as expected, turned out to be because I'd had indented #ifdefs,#defines to try to make things more readable. Removing white space fixed it. More CCP weirdness? My expandlcfg seemed to do the right thing.

This was the problem indentation:

#ifndef DICE_OPTIONS_APACHECONF_SKIP_COSIGNFACTOR
/* this will only have an affect if apacheconf-cosign.h is included later,
   and we don't splat a previously defined value */
  #ifndef  DICE_OPTIONS_COSIGN_FACTORS
    #define DICE_OPTIONS_COSIGN_FACTORS INF.ED.AC.UK
  #endif
#endif /* not def SKIP_COSIGNFACTOR */

-- NeilBrown - 20 Jan 2015

Topic revision: r1 - 20 Jan 2015 - 21:06:57 - NeilBrown
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies