Planning Questions

What we want from a secure web server

We need to be aware of the distinction and any discrepancies between general web-browsing access and filesystem access. What, if anything, do we want to change or fix?

We can use generic "apache" ID access to serve public files, and user-specific access for restricted files, where:

  • public access is via AFS apache ID (as currently for system:groupwebserver or system:afswebservers, which contain afsweb.hostname IDs)
  • restricted access via minimal AFS user ID ( apache assumes this ID when public access is not sufficient, but full user access is not required. This may need to be triggered by URL, as access requirements may vary).

Create/configure new server (real or VM?)

  • physically separate AFS server, firewall protected? (This might prevent unwarranted physical and administrative access to the server, but would not have a significant impact on the AFS structure.)

Install/configure apache

  • do we require user-run CGI or PHP scripts?
  • we could disable arbitrary user-run scripts (a script should not be able to subvert any explicit restrictions by abusing the AFS apache ID privileges, scripts should run as user).

Identify disk storage space/location

  • how much would we need and where would it be? Local disk/SAN?

Define our volume naming scheme

Volume allocation would be per user, and on-demand (rather than automatically by default), administered by appropriate capability upon request.

AFS web space could be provided as a separate volume, web.NAME for example, either mounted or linked as the old public_html used to be, or accessible via a separate path such as /afs/inf.ed.ac.uk/web/user or somesuch (to avoid conflict with home directory access constraints imposed or required by the user).

Providing web data storage on separate AFS volumes has the advantage of:

  • fine grain access control
  • fine grain quota control
  • the ability to access the data files with any AFS client from anywhere
  • the ability to remove volumes as part of the account lifecycle mechanism

Consider the apache start mechanism (keeping it authenticated)

...using k5start

  • intra-PAG
  • extra-PAG (if the web server is started by hand, the web server will lose its credentials)

This approach allows one AFS id for the entire website, but no finer granularity. It is obviated by the use of CoSign/waklog (see below).

Decide on the apache file-access mechanism

(so that web-server can access requested files on behalf of users)

Any server that needs authenticated access to AFS will need its own service principal. Each machine which requires web access to AFS space should have an AFS/web service principal mapping to a corresponding AFS id.

All requests could use same ID (but any compromise or calamity could potentially affect all users), OR requests could use a unique user/web ID.

Access permissions would need to be isolated so that there's no general access to, for example, CGI scripts - a user's script shouldn't (because it might need to run as the generic webserver ID) be able to access or affect anything that the user can't. This will probably mean separate/additional AFS user identities (the minimal AFS user ID mentioned above).

...the upshot of which is strong support for the use of mod_waklog in conjunction with CoSign. We can use a single ID by specifying a WaklogDefaultPrincipal to give us public access, or per-user CoSign authentication for finer control - something like:

 
<Location /webstuff>
  CosignProtected    On
  AuthType               Cosign
  Require                  Valid-user

  CosignGetKerberosTickets    On
  CosignKerberosSetupGss    On
  WaklogUseUserTokens     On
 </Location>
With respect to URL-triggered credential change referred to above, different credentials might be used for different locations via the WaklogLocationPrincipal directive.

Note that the future of mod_waklog is uncertain. Any reliance we place on it may mean that might have to become involved in supporting it - either locally or publically.

Apache needs to be able to authenticate against our KDC, and to obtain AFS tokens for the principal it's authenticated as. The AFS ACLs need to be configured accordingly to provide access to the required files. (And should, ideally, be so configured that access via web is logically distinct from access via filesystem... and might even be exclusively so - only the full user credentials having access to web-viewed files from the file-system.)

-- RogerBurroughes - 06 May 2014

Topic revision: r4 - 07 May 2014 - 08:25:53 - RogerBurroughes
 
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