Tuesday, August 28, 2012

New Website Launch and Job Hunting

In case you haven't noticed, the BlakeNet site has been down for quite a while. In it's place comes a much more serious website whose scope is beyond BlakeNet's original experimental sandbox and download repository purposes. My new site, Subnet ROOT (SNR), serves to bring professional contacts, as well as personal and casual ones, all the information they might want to know about me. All content previously provided by BlakeNet will still be available through SNR. If there are any articles here that still link to the defunct BlakeNet, please let me know and I will be happy to provide the working alternative.

In the meantime, did I mention I'm looking for employment opportunities? I just finished up my Bachelor's of Science in Engineering and Information Sciences (Game and Simulation Programming concentration). Now I'm looking to get my foot in the door in the video game industry or other computer programming careers. Find me on LinkedIn (professional inquiries only, please) or contact me through SNR (professional or personal inquiries).

Edit: I'm no longer actively seeking opportunities, though I am always open to professional networking. Feel free to continue reaching out to me!

Thursday, August 02, 2012

VSFTPD "refusing to run with writable root inside chroot" Work-around

Hey there, everyone! I've been very busy lately with a couple different projects, but I thought I'd take the time to share my latest challenge and how I worked around it. The other day, I updated my Ubuntu servers from 10.04 to 12.04. This update brings with it a new version of VSFTPD (Very Secure FTP Daemon) which boasts some security improvements. Unfortunately, one of these improvements is causing a lot of headaches for me and other server maintainers.

VSFTPD has buffed up security pertaining to chroot'ed users. The (brief) reasoning behind it is that users jailed to directories they have write access on may alter scripts in such a way that would allow them to "break out of" the jail. While I acknowledge this as something to take into consideration, I feel the compromise between security and usability currently being forced onto us is unacceptable. Many configurations that worked perfectly fine before the update now throw an error when a chroot'ed user logs in:

500 OOPS: vsftpd: refusing to run with writable root inside chroot ()

A quick Google search turns up some obvious solutions, like stripping write permissions from the user on their home directory, moving files you want the user to have access to into subfolders (where they can have write access), or using the local_root config directive to jail users to the parent directory instead. You can even replace VSFTPD with the vsftpd-ext package, which supports the allow_writeable_chroot config directive. But, these weren't viable solutions for me; I didn't want to remove write access from users on the one place on the system I feel they should be guaranteed full-run over, I didn't want to allow nosey users to see what other files and folders were outside of their own area, and I didn't want to install an alternative package just to fix one simplistic issue. So I came up with my own solution!

My configuration is set up to not jail users by default. This allows accounts like mine and my operating partners to navigate the entire system, while also allowing me to limit what is visible to specific users for simplicity or to keep them out of places they shouldn't be in.

$ nano /etc/vsftpd.conf
...
chroot_local_user=NO
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd.chroot_list
user_config_dir=/etc/vsftpd_user_conf

$ nano /etc/vsftpd.chroot_list
# List of local users to chroot() jail in their home directory when FTPing
foo
bar
foobar

Above, we can see that my config file calls for local users to not be chroot jailed by default, but to jail specific users listed in /etc/vsftpd.chroot_list, and to also find user-specific config files in the /etc/vsftpd_user_conf directory. The list file is pretty straight-forward (one username per line). This next part is where the magic comes in. The objective is to jail the users in such a directory that the only thing they could possibly see in their FTP listing would be their home directory. This directory must not have write access, and it must preserve the existing directory structure. There is a great utility for this sort of thing: links! But therein lies a problem. Directories can only be symlinked/softlinked, and FTP clients typically can't follow symlinks.

Luckily, there is another, much more powerful way to create links to directories. If you are familiar with the mount command, you know that it's used to create links between the filesystem and physical data. Did you know it can also create links between one area of the filesystem and another? The magical command uses the syntax mount --bind originalfile linkname. Now let's put it to work!

This next part will require you to know the superuser password. If you don't know it, but your account is allowed to sudo, skip the su root command and preceed each of the other lines with sudo.

$ nano /etc/vsftpd_user_conf/foo
local_root=/srv/ftp/foo

$ su root
# mkdir /srv/ftp/foo
# chown foo:foo /srv/ftp/foo
# chmod ug-w /srv/ftp/foo
 
# mkdir /srv/ftp/foo/foohome
# mount --bind /home/foo /srv/ftp/foo/foohome

In the first part, we see that we change foo's local root directory to /srv/ftp/foo instead of his typical home directory (in this example, /home/foo, though it could be anywhere). I chose to use the /srv/ftp directory to house these jails, but you can use any directory you'd like as long as it has world read-execute permissions. In the second part, we run a couple commands to create the necessary directories, set the owner and access flags, and finally link the original home directory to the new area.

That's all there is to it! Simply repeat the above process for each jailed user, giving each one their own vsftpd_user_conf entry and /srv/ftp folder. Please note that you will have to execute the mount --bind command again for each user after every system reboot. To avoid this chore, I created a script and referenced it in my /etc/rc.local file. You can find more details about writing scripts and making them execute each time your system starts on plenty of other sites. I hope this has helped!

Saturday, April 21, 2012

SDS Status Report: April 2012

Hello! I have a couple things here to talk about. First off, as I often do, I must apologize for my lack of attention to the SDS project lately. I was involved with my senior project and another project involving Second Life society, the two of them taking up pretty much all of my time. I've since graduated and restarted work on some projects I had abandoned during my educational pursuits, SDS included. So, I have some bad news, good news, and more bad news involving the fate of the project.

The bad news first. To put it bluntly, I discovered that what I was promising the final version of SDS to do is just not possible right now. Looking back on my proposals, I had adopted two mentalities about all of this. They were "this project is absolutely possible. It's just a matter of making things run fast enough to be convenient to the user" and "this shares concepts with GPS technology, and GPS is fairly fast, therefore this project can be made to be as fast as GPS." I found out empirically that it just can't be made to run fast enough (given the tools immediately available to me), and it's very different from GPS. More on the GPS bit later (in a future article). In conclusion, this project will never reach the state I assumed it would, and so I must insist that SixDegreeSteam be retired.

There's good news too. I'm determined to leave this thing in as much of a working state as can be managed. My intention is to abandon the database approach, create an easy-to-follow graphical output, and have it accomplish the original objective I set out to meet, which was to outline connectivity of one user to the rest of the community. I've already gotten a lot of work in on these points in the past couple days. There's a lot more to go, but at this rate, it'll be done before anyone knows it.

Now the final piece of bad news. Parts of the Steam Community API got updated recently, throwing a generously sized monkey wrench into what used to work in SDS. This slows progress down because I now have to go back and rethink what I already had down. In conjunction, I contacted the Valve employee I understand to be the lead developer on the Steam Community to ask for any information pertinent to the project, or some added public API functionality, or anything to help me out. I was met with a shockingly uninterested response I interpretted as "we've made tools available already. We have no more time to spend helping you datamine," which was understandable albeit surprising given Valve's invested interests in other community members and modders. Things have stacked against me and this project's success from the beginning. I was really hoping to catch a second wind from Valve.

To finish off this status report, I'd like to reiterate just how sorry I am to have taken so long with all of this, only to let everyone waiting patiently on it down. I've appreciated the interest, comments, feedback, and time each person has given to SixDegreeSteam. It's with a heavy heart and a shameful disposition that I must break this news to you. SixDegreeSteam will soon be concluded. After this next client release, it'll all be put away until I can acquire better means to meet all my promises. If you want to keep an ear in it so you can be aware of such a day, I suggest subscribing to this blog (for news on SDS and my other projects) or staying a member of the SDS Steam group. Again, sorry.

Thursday, January 05, 2012

56 Days of Second Life

Coming back from a long hiatus (wow, has it really been a year?), I went back to school earlier this week. My new classes have officially started, and boy are they monsters! The good news is this is the last stretch for me before graduation. The bad news is that these classes are going to eat up every ounce of my spare time.

One of the two classes I'm enrolled in now is an Emerging Technologies course. Along with a couple other assignments, we have to work on a project that demonstrates, well, emerging technologies! I've decided to do an 8-week-long project focusing on the social interactions that take place in Second Life. It was between that or a robotics project, and I don't feel confident enough with physical electronics to have my academic success ride upon it. At any rate, this project should be really interesting! If you'd like to follow it, I'm required to maintain a blog detailing my findings and analysis of what I observe. You can find it over here.

On a related note, expect an update on SDS pretty soon. It'll probably upset a lot of people, but it's high time I speak up about it. See you in a day or two!