I just came across the new boston video tutorial series. I’ve watched 20 of the PHP videos and am hooked. The production quality is great, and the content is really, really good! Once I finish the 200 PHP videos I plan to watch their MySQL and HTML5 videos. Can’t recommend these videos enough, and the fact that they’re free makes them even better! Nice!
A couple of weeks back I attempted to migrate a pair of clustered Solaris 10 servers to a new disk storage array. After rebooting into single user mode to pick up the new devices, I went to add the new quorum disk with clquorum. This resulted in both nodes panicking with the following panic string:
panic[cpu3]/thread=fffffe800125bc60: Reservation Conflict Disk: /scsi_vhci/disk@g6000d310002c6700000000000000003e fffffe800125ba40 fffffffff7959e39 () fffffe800125ba70 sd:sd_pkt_status_reservation_conflict+c8 () fffffe800125bab0 sd:sdintr+431 () fffffe800125bb50 scsi_vhci:vhci_intr+3da () fffffe800125bb70 fcp:ssfcp_post_callback+4a () fffffe800125bba0 fcp:ssfcp_cmd_callback+4c () fffffe800125bc00 qlc:ql_task_thread+756 () fffffe800125bc40 qlc:ql_task_daemon+94 () fffffe800125bc50 unix:thread_start+8 ()
At first I thought I was doing something wrong, but after a lot of research I figured out that there were a couple of Solaris-related bugs in the version of the storage array firmware we were using. One of the bugs was triggering the panic above, and after the array was patched everything worked as expected. Keeping up to date with firmware is just as important as keeping up to date with OS patches. It’s amazing how many firmware bugs there are, and they bite you in the oddest ways.
A number of applications (e.g., custom chroot jails, openssh, vsftp, apache) support the ability to chroot themselves. To find out if a process called chroot() at startup, you can check the /proc/<pid>/root entry for the process. For non-chrooted processes this entry will point to /:
$ ps auxwww | grep [s]endmail
root 3643 0.0 0.1 69032 2344 ? Ss 2011 0:01 sendmail: accepting connections smmsp 3651 0.0 0.0 59784 1780 ? Ss 2011 0:01 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
$ cd /proc/3643
$ ls -lad root
lrwxrwxrwx 1 root root 0 Jan 22 10:23 root -> /
For a chrooted process the root directory will point to the directory passed to the chroot() system call:
$ ps auxwww | grep [n]amed
named 18298 0.0 2.3 243632 49084 ? Ssl 2011 15:16 /usr/sbin/named -u named -t /var/named/chroot
$ cd /proc/18298
$ ls -lad root
lrwxrwxrwx 1 named named 0 Jan 22 10:19 root -> /var/named/chroot
Chroot environments can be made secure, especially if you follow the coding practices discussed in Building Secure Software and Using Chroot Securely. These are must reads for anyone who plans to use chroot()!
I’ve been trying to expand my Python knowledge and recently came across Nick Parlante’s 6-part learn Python series on Youtube. I’ve watched several of the videos, and I am impressed with Nick’s teaching ability. Here are links to the 6-part series:
Day 1 part 1: Introduction and Strings
Day 1 part 2: Lists, Sorting and Tuples
Day 2 part 1: Regular Expressions
Day 2 part 3: URLs, HTTP and Exceptions
If you are looking to learn Python this is a great place to start!
I previously discussed the OpenSSH Match directive, and how it can be used to chroot SSH and SFTP users. Over the past couple of months I’ve encountered some gotchas with the chroot implementation in OpenSSH. Since I had to figure these items out myself, I figured I would share my findings here so folks wouldn’t need to spend hours looking at source code (if you want to geek out and see how this works, check out session.c in the OpenSSH source code).
The first gotcha occurs when the users home directory doesn’t have the correct permissions. The directory the user is chroot()’ed into needs to be root owned, and in order for the user to see the contents of the top level directory the group permissions need to be read/execute. A user that is going to be chroot()’ed into /chroot/user will need the following permissions:
$ mkdir /chroot/user
$ chmod 750 /chroot/user
$ chown root:user /chroot/user
If the permissions aren’t set 100% correctly you will be immediately disconnected:
$ sftp -o Port=222 user@192.168.1.25
Connecting to 192.168.1.25…
user@192.168.1.25′s password:
Read from remote host 192.168.1.25: Connection reset by peer
Connection closed
And the following error will be written to your system logs:
Apr 23 14:06:27 vern sshd[13714]: fatal: bad ownership or modes for chroot directory “/chroot/user”
There is also an issue with directory write-ability. Users will not be able to write to the top-level directory of the chroot() due to the strong permissions that are required. If you want your user to be able to create files and directories they will need to change into a directory off of “/” prior to doing so. If you want to place the user into this directory you can replace the home directory field in /etc/passwd with this directory:
$ grep user /etc/passwd
user:x:502:502::/home:/bin/bash
In this example user will be chroot’ed into /chroot/user, then a chdir() will occur and the user will be placed into the directory home:
$ sftp -o Port=222 user@192.168.1.25
Connecting to 192.168.1.25…
user@192.168.1.25′s password:
sftp> pwd
Remote working directory: /home
With a little understanding the OpenSSH chroot() implementation can definitely be made quite usable.
If you are using SSH key-based authentication you should be encrypting your private key. This ensures that if someone breaks into your server and steals your keys, they won’t be able to utilize them to access other systems. If your private key isn’t encrypted you can use the ssh-keygen utilities “-p” option to do so:
$ ssh-keygen -p -f id_dsa
Enter old passphrase:
Key has comment ‘id_dsa’
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.
This option can be used to change the password used to encrypt a private key, and to add a password to an existing private key. Viva la OpenSSH!
