Go to content Go to navigation Go to search

sudo 1.6.9 interactions with PAM and libpam_afs_session

2007-11-22 15:01 -

For those using libpam_afs_session or any other PAM session modules on Debian Lenny or Sid:

sudo 1.6.9p6-1, which migrated into testing on 2007-11-04, introduced a change in which pam_open_session and pam_close_session are now called before and after command execution.

Previously, in the 1.6.8 branch of sudo, these calls were not made, and therefore there were no references to session modules in /etc/pam.d/sudo. The new calls resulted in the session entries being read from /etc/pam.d/other (the default PAM stack file); in Debian, this defaults to reading /etc/pam.d/common-session, etc. However, the Debian way is to explicitly @include PAM common-* files in files instead of just letting things fall through; it’s a bug that sudo now calls the session stack but doesn’t mention it in its PAM file (one reason it was so difficult for me to track this down).

Since we were invoking pam_afs_session.so and pam_unix.so in common-session, a new PAG was being created on every sudo, and the Unix logging of sessions was also being triggered unnecessarily. The creation of new PAG on sudo meant that we couldn’t read files in our own home directories after sudoing, so trying a dpkg -i ~/package_1.0.0-1_i386.deb, running nano (due to accesses to ~/.nano_history), etc. were all triggering all sort of nasty warnings.

For us, the fix was to add the entries from common-session to /etc/pam.d/sudo except for the pam_afs_session.so entry, causing the default common-session entries to not be invoked since there are now session entries in /etc/pam.d/sudo. However, I don’t see an easy default way for Debian to do things – using pam_permit might be a sensible default (and wouldn’t cause any /new/ behavior compared to 1.6.8), but the common-* defaults exist for a reason…

I’ve filed Debian Bug #452457 about this issue.

Words? [1]

AFS, Apache, and pseudo-SuExec

2007-09-22 03:45 -

It’s been an exceptionally busy week for me on the UGCS front, despite my being on vacation and traveling.

On Monday morning, we migrated everyone’s mail over to our nice new shiny 8-core Xeon server (hermes) and forced everyone into using our new Kerberos infrastructure to authenticate against IMAP and POP. There have been quite a large number of problems we discovered after the migration which we didn’t quite catch during initial testing, but as of Thursday we had everyone’s legacy mail converted and mail delivery was finally stable. I’ll blog separately about that when I have working configs to post should someone attempt to do an effort similar to UGCS in the future (I’m currently debugging an issue with mail forwarding at the moment). In short, we’ve set up delivery to maildirs on AFS, postfix, dovecot, GSSAPI auth (Kerberos), LDAP mail delivery settings and nss info, mailman, amavisd, clamd, and spamassassin all happily playing with each other now.

We also ended up moving over web services to the new ‘service’ machine (poseidon) on Thursday because the old webservers had finally had it and were timing out and refusing to function.

Inspired by this post by Todd Lewis from the University of North Carolina, but lacking his source code, I endeavored to create an equivalent for SuEXEC for our users. The problem is that Apache does not run with the Kerberos tokens of users, so it cannot execute sensitive read or write operations on user data, only read the data in ~/public/www. Many of our users rely on using CGI to manipulate flat file databases, etc., so this was somewhat of a priority to get them some level of control over their data using CGI without opening them up to cross-user scripting vulnerabilities from malicious users.

http://www.ugcs.caltech.edu/~elizabeth/cgi-wrapper is the result of my efforts – it’s meant to be run setuid as root and executable only by Apache when Apache matches “ScriptAliasMatch ^/~(.+)/cgi-bin/(.*) /usr/local/sbin/cgi-wrapper”. $10 security bug bounty, payable via Paypal to the first person who finds a security hole in it. The script was largely written according to Todd’s spec, and essentially pulls the tokens for a user from a root-only file, sets environment variables so the wrapped script won’t notice the aliasing, and then changes uid/gid to the user and creates a new PAG context with the tokens for that user’s cgi subuser. The cgi subuser can be assigned very limited permissions using AFS acl’s so a vulnerable cgi script can’t wipe out one’s homedir or mail (unless of course given permission to do so).

Now that our webservices are up, I’ve migrated the UGCS development wiki over to poseidon, but it currently requires a Kerberos login to view (sorry, guys). I used mod_auth_krb plus Extension:AutomaticREMOTE_USER to make it work.

All in all, a very productive week on my side project :) – we’re definitely going to make the September 29th switchover date to shut down the old cluster and convert old cluster’s servers into shell machines in the new cluster.

Words? [1]

UGCS 4.0 buildout

2007-08-22 05:11 -

I spent Friday through Monday back at Caltech with the other sysadmins participating in the full push to get the next iteration of UGCS finished. SURFs ended this past week, so the other three sysadmins were leaving after the weekend, and the next time we’d all be in one place would be after school starts in October. So, it was a choice of getting it done now, or waiting until Thanksgiving break to get it done. Ideally, my goal is to have things substantially ready by the first week or two of school so that we can push UGCS usage to the new freshmen and encourage a much higher cluster adoption rate among the undergraduate population.

Things went fairly well, although we had some snafus with regard to getting our hardware delivered; regardless, we made substantial progress towards having the cluster up and running. We came into the weekend with only two finished servers, each with 6 750gb hard disks in RAID 5, that had been configured to run AFS, LDAP, and a Kerebros KDC. We had an early setback when we discovered one of the hard disks had failed and that the machine would need to be taken down to prevent any additional failures that would result in data loss. I got very little sleep over the weekend and was so focused and engaged that I neglected certain bodily needs.

We finished up with three Cisco switches (2× 2950, 1× 2970) configured as a cluster, segregation of servers by VLAN and automatic VLAN assignment based on MAC address, transparent bridging, firewalling, intrusion detection, and filtering on a new bridge machine, a temporary mailserver with Postfix, Dovecot, Spamassassin, and Mailman running and delivering to AFS Maildir folders with the help of some very small patches to Postfix, working DNS and DHCP/Netboot, a partially set up new Kerberos/LDAP isolation machine, and a much better understanding of what is left to be done. With luck, we’ll be able to get to the stage of performing the actual switch-over the weekend before classes start.

I’m intending to write up what we’ve done after the build-out is complete so that others building similar clusters will benefit from the pitfalls we fell into and extricated ourselves from – I definitely found other blogs and HOWTOs extremely instructive throughout the entire process and want to reciprocate.

Words?

Cleaning up UGCS

2006-01-29 14:06 -

I’m now, among way too many things, a sysadmin at UGCS – a unix cluster run entirely by students, and operated without funding from the administration (our current stash of money comes from the Moore-Hofstadter fund, which contributes to Caltech student organizations to benefit student life). The problem with the lab as it is right now is threefold:

  1. Our hardware is at minimum 3 years old, mostly castoffs from other departments, or from a large grant of computers Intel gave us a few years ago.
  2. Nobody uses the lab, because the Caltech-funded ITS labs across campus have much nicer hardware.
  3. The lab has gotten cluttered and dusty, because nobody but sysadmins use the lab any more, and there are chairs/spare parts/unplugged in monitors all over the place.
  4. Return to step 2, since the lab is cluttered and unusable (only 3 working shell logins available to users at last count, and only one machine with working X).

The solution to break the vicious cycle? Clean up the lab. I’ve been working on this my first day as sysadmin (who knew that being sysadmin would involve lugging lots of heavy computer hardware around and scraping myself on things?). We’ve taken the armrests off the chairs, so they can be tucked under the desks, so that the aisles will be walkable; we’re hooking up all our systems to monitors and keyboards, and removing the rat’s nest of wires. Next week, optimistically, we’ll redecorate – put the LED net up on the ceiling, and buy some lamps so that the place doesn’t look so dingy. We can probably budget some money for some new systems, as well, and return UGCS to a state where a large number of undergraduates come to the lab in person to work. Yarr.

Hopefully this project will be completed within a month or so, and then we can possibly invite people to some kind of grand-reopening.

Words? [2]