Lower Merion School District Spying Report Issued

The findings of an independent consulting company (Ballard Spahr, LLP) were released recently regarding the remote monitoring of student laptop computers by the Lower Merion School District. Already it spurs an outpouring of vitriol in comments from the smart masses who think they understand anything that is going on here. Personally I think there's a huge disconnect between the peanut gallery and their perceived intelligence.

The report, an approximately 70 page outline of everything that was leaking into the press and then some, basically said what I originally thought. The school district has a lot of idiots running it. Not in so many words and perhaps not for the reasons people would think, but they did some pretty spectacularly stupid things.

The biggest problem, of course, was the IT department hiding the presence of the tracking software. It wasn't so much that I can't relate to their desire to hide it from people in case they try to circumvent the protection; I work in IT. I know people could do that. But anyone with half a brain in IT knows that security through obscurity won't work well. The laptops, if stolen, could easily be wiped and reinstalled with a clean OS image, and the tracking software would be useless. They not only hid it was there, but apparently they tried to obscure the fact that the software was there even when rumors were swirling about its existence. That is a blatant lack of respect for the students and faculty. Whether you regard them as little vengeful monsters or not they still deserve not to be lied to.

A very close second (okay, maybe it's a tie) was the lack of an updated usage policy for taking technology home. There were no documents to disclose modified acceptable use policies for using the laptops at home versus on the school network nor was there disclosure about potential security and privacy issues in the documentation given to parents.

Everything else in the report seems to nick the school for lax and ill-codified policies, and not being fully forthright with administrators and board members.

As someone who has to work in IT, I think the two biggest sins were the lack of properly documented procedures and the hiding of the ability to monitor the laptops. The fact that administrators and board members didn't know about these things, or didn't understand it, were not the IT department's fault, unless they went out of their way to hide it.

Really...there is a point where someone needs to take responsibility for themselves. The board didn't know about it because they didn't care. Neither did the administrators. They all had a vague idea of this ability, if they've seen evidence from the "anti theft" systems. What the hell did they think it did? That this stuff runs on unicorn farts and fairy dust?

I deal with users all the time. They care about how and why their systems work about as much as you care about how your car engine works. The IT department didn't explain it to them because it was a waste of time to do so! I've dealt with users to whom I've explained a simple (to me) concept several times and they simply don't listen. I can repeat it until I'm blue in the face and it doesn't matter. So why and how would this IT department telling their school board about activating timed snapshots from a webcam and screen capture utility while logging the remote system's IP address to a central server make any fucking difference to them?

And lack of following formal policies? In most smaller businesses and schools and, I'd venture, government agencies, following strict, codified policies is a luxury. We always hold up best practices as an ideal but more often than not they're aspired to, not followed. Departments like those in public schools are under immense pressures from the powers that be to just get a task done, and if it's held together with duct tape and broken pencils then so be it. Doing it "right" takes money and time. They don't want it done right. They want it done now.

While some would say that's an excuse, it's more of an explanation for the culture that this attitude has fostered. More often than not if something works, then it's good enough, and it saves money. If it's actually bad enough to bite you in the ass later then it will be fixed then. Otherwise, good enough is good enough.

What I find interesting is that lack of citing personal responsibility by the peanut gallery. These kids were using school property and apparently treated it like their own property. It wasn't. I was floored when this story broke and people were raving about how they'd format the computers if their kid had brought one of them home; yeah, right. You can't. It's not yours. The school was extending it as part of an experiment in technology-based curriculum. And it's their computer. Not yours. Not a handout. Not your property.

I'd have trusted the laptop about as far as I could throw it. Any organization that "lends" you a thousand dollar piece of equipment, would surely have the right to inspect it for activity; porn surfing, games, inappropriate use, anything of that nature. What universe would you live in where you go to school, can't browse the web the way you want, can't play the games you want, but expect them to just hand over a thousand dollar laptop so you could surf porn at home on their dime?

Use your damn brain!

There was one report of a girl who had taken the laptop into the bathroom to listen to music while she showered, and the parent was furious because the school may have seen his little high school princess naked. Huh?!

Damp, humid room...thousand dollar laptop...electronics...water. What the hell was it doing in that environment to begin with?!

To me, there were a number of failures here. From hiding the fact that this software existed to lack of formal CYA policies to cover proper usage of the laptops at home to a lack of common sense from the students and parents, there was a systematic failure that happened here.

The sadder part in my view is the ignorance of the peanut gallery. It's simply too easy to blame the evil school district and portray them as completely at fault while completely forgetting that there was also a bit of an attitude of entitlement, that reality has slammed down hard on the community realizing that these free toys weren't free. 

Encrypting your Laptop: Summary Thoughts

The issue of encrypting your data is far more complicated that I'd like it to be. After doing this on my work laptop running OS X and my personal netbook that I'm using as a "portable computing experiment," I can say there is significant difference in the experience.

I used the "default" methods for encrypting these systems. There are many options if you research online; Truecrypt is popular and cross-platform, EncFS can be used on Linux and OS X but takes some Terminal Fu to accomplish, dm_crypt on Linux,...options abound.

But here's why I chose the "Default" methods; they work. They're supported (in this case by Apple and Canonical). When you upgrade the operating system, there's a far better chance that the encryption isn't going to break the new installation.

The problem is that these encryption techniques are still with trade-offs, partially because of the way these encryption techniques are implemented.

Both FileVault and EcryptFS as implemented here encrypt just the home directory. This means that anything in the temporary directory or in the log files are accessible, as is the swap partition, which can hold data that was in memory and could have sensitive information tucked among the crud. The good news is that odds are very good, since Linux and OS X are "UNIX-based" in design, that your personal data is contained within the home directory.

When you log in, the encrypted volumes are mounted so you can access the data. This means that when you're logged in malicious software can access your unencrypted data. In other words, encryption isn't a cure-all for security.

EcryptFS on Ubuntu stores your files as files on top of the filesystem. This means that if I were to look at my username's files when that username is logged off, say, by logging in as root, the files look like gobbledeygook. Each "real" file appears as a string of nonsense. There's a one to one correspondence...the encrypted file will still allow a nosebag to see when I created the file or last accessed the file, the approximate size of the file, basically they can get a lot of metadata without seeing the actual content or name of the file. This means that it's a lot easier to back up the files to another media.

FileVault is implemented using a "filesystem within a file". If I log in as my secondary user (more on that shortly) I see a huge number of files that comprise a sparse disk image. When I log in as my normal user, OS X takes the image files and combines them into one big container, and my files are contained within that container file. (To be more accurate, the many files are contained in a bundle, so within Finder you only see the top level bundle).

The reason the FileVault image was broken into many smaller files was because of an issue with Time Machine. Originally the encrypted volume was one giant file. If the user was logged in and then a backup was run, the backup will see that giant file has changed whenever even a tiny change was made in your home directory (since your home directory was actually contained in that giant container file). Apparently users got irritated at backups that took hours to complete when only a couple of documents changed.

Later versions of OS X changed the single giant volume into a number of smaller files. That way one small change doesn't trigger a backup of an entire multi-gigabyte file repeatedly but rather a single chunk of the volume.

In contrast, the EcryptFS method of using a one-to-one file encryption means that backups are simpler and faster. You alter one document, that file is the only one that changed and thus the nonsense-i-tized file will be backed up to your storage media.

It's also because of the OS X "container" approach that when using a utility like Carbon Copy Cloner for making images and backups of your computer that Bombich Software recommends you make sure you're logged out of any FileVaulted accounts. On the OS X system I had to create a second administrative user to do backups from.

Neither solution gives full-drive encryption, arguably the most secure. It is possible to configure a new Ubuntu system to encrypt an entire volume at installation time, but to do so means installing from the alternate installation CD. Not exactly user-friendly. So you balance security and convenience, accepting that anything in the temporary caches outside the home directory or anything in swap area could be recovered. On the other hand this means less of a performance penalty for accessing routine system files, since any encryption means having the CPU jump through more hurdles to decrypt information before you can access it.

Encryption adds a layer of security in case your notebook is stolen. The price is that it also adds a layer of complexity. Recovering your data in the event of drive corruption is far more difficult, and in the case of FileVault, if part of that container file is damaged you will most likely lose everything in your home directory. This makes having a backup even more important. Encryption adds processor overhead, so it slows the computer.

One last point I have is that these only encrypt the home directory. Since I'm using a netbook, my expansion storage area on the SD Card or USB drive is not encrypted. If I have that with my netbook case and they're both stolen, anything on those secondary drives is open to theft. I'm sure I could find a way to encrypt the data on those drives, but then if I needed to share data with another computer or use the drives with another computer, they couldn't use it since that system probably doesn't have the same encryption scheme installed. I also make heavy use of external drives at home for expanded space and backups, and they are not encrypted.

I do think that while FileVault has detractors...there are many on the Internet claiming that it will eventually destroy your data, and they decry the shortcomings of only encrypting the home directory...Apple has made the process braindead simple. When it comes to something like encryption, options are definitely a bad thing for end users. People want to accomplish a task. They don't want to have to weigh options and choose the "correct" answer among a sea of possibilities. With the Snow Leopard version, they get protection for the home directory, the protection is implemented in-place so they don't need to move their files around to a special encrypted directory or temporary holding area, the slack space can be securely wiped after the change is made, and they don't need to play with configuration files or the command line to set up details like automatically mounting the home directory, and since it's a standard OS X feature, chances are that new versions of OS X aren't going to render your home directory inaccessible.

The EcryptFS doesn't necessarily have detractors, but for a reason that is itself a criticism...it's not widely used. Linux has a small base of users compared to Windows (or Mac OS X), and an even smaller percent of those users are even aware of the existence of encrypted home directories. It's a feature that's probably not widely implemented in the wild.

I didn't talk about Windows encryption because I don't use it. Windows has had encryption support for some time now and third-party support is, predictably, even more mature (for example, TrueCrypt supports full-disk encryption for Windows, but not for Linux or OS X). But Windows is what I work with in my day job. And it drives me nuts. And one thing encryption will not protect you from is spying when you're already logged in with access to your encrypted volume, and the market for malware on Windows is more mature than the malware market for Linux and OS X as well.

What does that mean? It means that if spyware gets installed while you're logged in, the disk encryption can't prevent that spyware from uploading your documents or opening the machine to remote access to an attacker. The encryption only guards you from having your data stolen if your laptop is stolen; the attacker looks at your hard drive and finds nonsense instead of your banking information if they don't have your password.

It's all a balancing act. The two operating systems I am implementing encryption on stay true to their roots. OS X made it simple and painless. Linux makes it a hidden feature for people who dig under the surface to find the Easter eggs. Neither one is a panacea but are instead an added layer of security.

Encrypting Your Laptop: EEE PC (Ubuntu Netbook Remix) Edition

Continuing from my previous post regarding encrypting my employer-issued Mac, here I describe the experience of encrypting my netbook running, as the title says, Ubuntu Netbook Remix.

OS X includes FileVault for encrypting your home directory and is braindead simple to implement. It allows for live home directory encryption; that is, if you have the space available on your laptop and turn on FileVault, you don't have to do anything to your directory that involves copying or manipulating your files in order to get protection. Most of the time was spent just sitting and waiting while the laptop went ahead and started altering my home directory for me.

Ubuntu...not quite so much.

It's not fair to say that Linux makes it completely difficult to implement encrypted home directories. The latest versions of Ubuntu supports eCryptfs, the encrypted filesystem. This is built on the FUSE filesystem which allows users to mount "plugin"-supported filesystems (FUSE is a topic all of its own; I can use FUSE to do neat things like mount a SSHFS filesystem, a mount over secure shell. I used to do this to gain access to my home computer's files as if they were mounted locally on my work computer's directory tree.)

The main problem I ran into was that Ubuntu's supported home directory encryption was meant for implementation when users are newly created or when the system is being set up. There is no "live migration" as of Ubuntu 9.10.

There were instructions that were supposed to support a manual move to an encrypted home directory. I had a second computer, so I logged off of my netbook and secure shelled into the system from another system (you can't have files being accessed while you're trying to move them from your home directory, and part of the instructions tells you to log off the graphical interface to minimize the risk of corruption.) I tried those directions twice, and both times failed miserably.

What I ended up doing was first disabling the automatic login to my administrative user by going to system->login screen and telling it to "show the screen for choosing who will log in".

Next I set about the task of creating a new user using the "adduser --encrypt-home tempusername" command, giving that user full sudo privileges by adding him to the admin group, then logging in as the new user. Next I synced my original user's files with the new user's directory (from secure shell, not the graphical login) using the command "sudo rsync -aP --exlude=.Private --exclude=Private --exclude=.ecryptfs /home/username/ /home/tempusername". This copied all the files from the original unencrypted directory to the encrypted new user's subdirectory.

Next I changed ownership to the new user. Probably unnecessary, but I did it for testing purposes; "sudo chown -R tempusername:tempusername *" from the new user's home directory. Then to copy the hidden files, "sudo chown -R tempusername:tempusername .*"

A quick "ls -al" told me that I had caught all the files in the new user's home directory in the net of ownership to the temporary user. I then logged in as the new user on the netbook and lo and behold, my customized color scheme, icons, configuration...all of it...popped up. I checked that my files were intact and happily found that they were.

Next I deleted the old home directory by changing to /home and running "sudo rm -fr username" as well as removing the user from the user management GUI (which just disables the user; home directory is left intact.)


Then I went back to the command line and ran "adduser --encrypt-home username" to create that username again. I verified that /home/.encryptfs now had a home directory for that user then reversed my sync of directories; "sudo rsync -aP --exclude=.Private --exclude=Private --exclude=.ecryptfs /home/tempusername/ /home/username", followed by a "sudo chown -R username:username *" and "sudo chown -R username:username .*" from within username's home directory.
 
Once the sync was complete I logged in on the netbook again and my desktop once again popped up to greet me! Yay!

I then deleted the tempusername from the Users and Groups utility and deleted the subdirectory for TempUsername from /home and /home/.encryptfs; the last one is the actual home directory, where the encrypted files are kept. The "home" directory directly under /home is a mountpoint.

To sum it up, what I ended up doing was creating a new user with an encrypted home directory, copying my data there, then deleting my username and username's home directory and rebuilding it by creating a new user with my old username's name and copying my home directory contents *back* over to the newer username that I just created.

Now when I log in it's using eCryptFS to protect my home directory. Is it particularly user friendly? Not in my opinion. No end user is going to want to sit down and create a "temporary user" to hold data, delete then recreate their username so it will be encrypted.

There was also no built-in way to scrub slack space; my files were deleted, but they're still recoverable to disk utilities. In order to truly delete that old data you need to overwrite the "cleared" space a few times with nonsense data. Over time those files will be naturally erased as I use the computer and other data is added and removed, and without a special utility I'll have to rely on that.

A second problem is that the EEE PC uses a form of flash for storage, like an internal USB thumb drive. From what I understand the cells used to hold the information have a limited "write" lifecycle. The more you write to them, the sooner they'll fail, so controllers use algorithms to write to random spots on the drive to minimise wear on the cells. Running a scrub operation to overwrite the disk spots (and thus make my old data irretrievable) can wear more on the drive and there's no guarantee it's going to actually write where it needs to write to hide old data. Then again, I'm not a storage technology expert, so I don't know if there's a different mechanism at work here or not.

Overall the netbook encryption was more manual and difficult a process than it was on the Mac. If it weren't for my own experience in using Linux, I'd not have been able to easily do it. Even the encrypted home directory feature is not fully advertised in the Ubuntu installer; it's more of a stealth feature being tested internally and by advanced users worried about privacy. This is evident in the fact that to even create the encrypted home directory you have to add the user via the command line since the GUI user manager doesn't have the option. No doubt the feature will appear in a later version of Ubuntu. It'll be interesting to see what the next netbook remix version will bring in options for data protection should my netbook get stolen...

Encrypting Your Laptop: Mac Edition

Here's another chapter in my ongoing experiment with the mobile lifestyle.

Periodically a story crops up about some poor sap having his or her laptop pilfered. The news I get has all sorts of cringe-worthy details...doctors losing their laptops with patient information, accountants, business people...even my own employer has departments with sensitive information going between work and home.

Every time I see the story and the concern of personal data being ripped from the drive and used for identity theft, I laugh and think, "You dolt! Why would  you carry sensitive information on a portable computer without encrypting it?!"

Then I stopped and remembered that I never got around to securing my own work laptop (or the EEE PC). It was always one of those things I "meant" to do but just hadn't bothered, and every time I thought of it I knew it was a bad thing because not only would my equipment be missing but they could get passwords, cached emails, etc. on the system. I'd make yet another mental note to take care of it and promptly procrastinate again.

Well, no longer.

My employer lets me use a MacBook. Here I'll outline how I used the default form of protection, called FileVault.

How do you use it? Open the security preference pane. Go to FileVault. Set the "master password" and turn on FileVault for your account. I strongly advise setting the "Secure delete" to wipe the drive of your unencrypted data after your directory is moved to the encrypted volume.

And that's about it.

FileVault creates an invisible encrypted disk file that is mounted as your home directory; it's a sparse image file that grows as you add more files. When you log in with your password, OS X mounts the image file to your home directory. Everything you save or alter goes into that file. When you log out, it's unmounted.

You can see this if you create another user and try viewing the home directory of your filevaulted user. It's just a bundle of encrypted files.

The secure delete takes care of another issue with deletion and security; when you delete a file, it's just removing a reference to the file. The disk still has the data on it so data recovery utilities will be able to retrieve the data you're trying to encrypt (well, the remnants of your previously unencrypted home directory would be recoverable until it is overwritten with other files in the course of just using the computer.)

The process of secure deleting the slack space of the drive and the moving of your data to the FileVault volume can take quite a bit of time; in my case, a couple hours. On the plus side, I put the computer to sleep when I had to leave the office, and as soon as I woke the computer back up it continued with the secure delete task.

There are some issues with encryption (why must everything be a pain in some way?) Apple has tried to address some of the issues, but it's never simple.

Time machine apparently doesn't like the FileVault. See, attempts to back up the system sees the volume files plus your mounted volume as separate files, confusing the backup system. Plus, since you have those files mounted, they show up as being constantly altered, so time machine will keep trying to copy the sparseimage files, which as soon as your home directory changes triggers a change on the image files which triggers confusion for the backup system again...meaning a simple differential backup can easily be corrupted or take hours when it should have taken minutes.

Apple tried to address this by turning the FileVault image into many smaller images. From what I found online, this helps, but still leaves room for complaints. Fortunately I don't use Time Machine so this didn't affect me.

What does affect me, though, is the use of Carbon Copy Cloner. This is one of the best (free!) utilities I've found for creating backup images of your Mac. The problem is that you confuse the @#$% out of it if you're FileVaulted and logged in. It's trying to copy your drive while you're altering the image files.

The solution is to have an administrative user that isn't FileVaulted, made just for administrative work, then image the drive. That way the FileVault image files are unmounted and untouched and you won't need to worry about corrupting your home directory.

I also need to remember to log off or turn off the laptop if I want data secured. When you're logged in, the volumes are mounted, and so anyone else logged into the computer can read your files. Only when you are logged off and the images are disconnected from the home directory mount point are the files "secured."

The only other complaint I've really run into is that logging off takes longer. Because FileVault uses a disk image, the image can't "shrink" just because you delete files. When you log off OS X will try to shrink slack space in the image and thus recover some space on the drive. If you deleted a lot of data, like gigs of photos, then log off it can take quite a while for the shrinking process to complete.

Overall Apple made it extremely simple to encrypt your home directory. It's all graphical, it's simple, and Apple takes the burden off the end user to figure out the technical workings of encryption. A few clicks, a few passwords, and the rest is largely invisible and "just works". The process took an hour and a half...but an hour and 25 minutes of it was just waiting for it to finish the background copy and scrub of data. OS X let me continue working as if nothing was happening (well, it slowed a little since the drive was given a workout, but I could keep working without issue.)

I can say that barring issues like having the image files become corrupt due to disk or power problems, encrypting your home directory on the Mac has been painless. I've been using it for a week or so without issues with any of my software, including virtualizing Windows in a Virtualbox session.

Next, I tackle encrypting my EEE PC with Ubuntu...