2012 – Page 2 – Roo's View

New Phone: Samsung Galaxy S2 LTE

Again I’m feeding my gadget habit by picking up a new to me phone. This time it turns out the phone is effectively brand new, it still had the factory plastic on the screen and came with the box and all new accessories. I’d been watching the local used phone market via kijiji for a while and this one popped up at a great price, I was lucky to be one of the first to respond with a firm offer to buy.

The phone model number is SGH-I727R and is locked to the Rogers network here in Canada. It is basically the same as the AT&T SGH-I727 model, this means there should be reasonable community support for 3rd party firmware (specifically CyanogenMod).

Even prior to purchase I usually do quite a bit of reading up on the potential of the device. While in general the technology upgrade is across the board, a couple stick in my head: 4.5″ AMOLED screen; 1.5GHz dual core; 8MP camera. Apparently this phone has the capability to be flashed over to work on AWS networks such as Wind, I doubt I’ll need this but it’s nice to have such a capable phone.

The first real hurdle I came across was unlocking the phone. I had seen enough material on the XDA Forums indicating that it wasn’t a big deal to unlock this model, but I had hoped it would be as easy as the i9000 was (a simple software patch). In the end I bought an unlock code via eBay, the price was very low and I had some amount of purchase protection through eBay in theory. I found the listing via a post on XDA by a member who’s quite active and has the same phone, this also increased my confidence that it was going work.

I made the eBay purchase at 8pm, there were several (I’m assuming) automated email responses pointing me at the website to submit my IMEI. In less than 6 hours I had an unlock code, I suspect if I had made the purchase at a more convenient time of day it would have been even quicker. Inserting my Fido SIM caused the phone to present the Network Lock Control Key screen, I was able to enter the 8 digit unlock code and unlock my phone. I don’t know, but I suspect that it may have requested the unlock over the mobile network, there was a few on screen messages indicating that it was ‘requesting’ the unlock. The unlock is persistent across firmware upgrades, and appears to be for all SIMs based on my testing.

In the hope that I could help identify a software only unlock, I did a little poking around on the stock firmware. In order to do this poking, it was necessary to gain root. I did this using the zergRush exploit. I was glad that I had a copy of zergRush cached away, as the file linked by the XDA post wasn’t available.

You will need adb installed and setup on your computer and communicating with the phone (you might need to turn on adb support under Menu->Applications->Development->USB debugging), assuming you’ve got that sorted out using zergRush is quite easy:

adb push zergRush /data/local adb shell cd /data/local chmod 755 zergRush

Now when you run zergRush you’ll see something like:

$ ./zergRush
[**] Zerg rush - Android 2.2/2.3 local root [**] (C) 2011 Revolutionary. All rights reserved.
[**] Parts of code from Gingerbreak, (C) 2010-2011 The Android Exploid Crew.
[+] Found a GingerBread ! 0x00000118 [+] Found a Samsung, running Samsung mode [*] Scooting ... [*] Sleeping a bit (~40s)... [*] Waking ! [*] Sending 149 zerglings ... [*] Sleeping a bit (~40s)... [*] Waking ! [*] Sending 189 zerglings ... [+] Zerglings found a way to enter ! 0x18 [+] Overseer found a path ! 0x00030730 [*] Sleeping a bit (~40s)... [*] Waking ! [*] Sending 189 zerglings ... [+] Overseer found a path ! 0x000307f8 [*] Sleeping a bit (~40s)... [*] Waking ! [*] Sending 189 zerglings ... [+] Zerglings caused crash (good news): 0x40322cd4 0x0074 [*] Researching Metabolic Boost ... [+] Speedlings on the go ! 0xafd19b63 0xafd3975f [*] Sleeping a bit (~40s)... [*] Waking ! [*] Sending 181 zerglings ...
[+] Rush did it ! It's a GG, man ! [+] Killing ADB and restarting as root... enjoy!

Now when you connect again with adb you’ll be in a root shell. Now with full access to all of the files, I copied some of them down in the hope of spotting a change to one that controlled the locked state. Exploring the filesystem it seems that the i727 phone doesn’t have a nv_ram.bin file, nor were any of the potential candidates modified by the unlocking process. This was a failed experiment, but still fun to try. I will note that zergRush does leave the phone in a pretty sick state – UI is very, very sluggish – you’ll want to reboot as soon as you’re done messing around.

How To: Jenkins with Apache controlled authentication

For a change of pace, I was working with RHEL6 instead of Ubuntu and setting up a Jenkins CI server. I’ve used Jenkins aka Hudson previously, but this was my first time setting it up.

A lot of this is straight from the Jenkins wiki, which is detailed and helpful but at times cryptic. The default access mode of Jenkins is pretty much wide open, this is very handy for getting things done – but probably not what you want if there are a mix of people on the network, many whom you really don’t want to let do stuff like launch/configure your builds. As I had Apache already running and setting up authentication with Apache is relatively straight-forward, I figured the easy solution would be to hide Jenkins behind Apache.

Since Jenkins is a big wad of Java code that is offering up a web interface, we’ve effectively got two web servers running: Apache, and Jenkins (different ports). The solution we’ll use is a proxy on the Apache side and some firewall rules to prevent direct access to Jenkins, forcing people through the proxy and thus the authentication controlled by Apache.

Let’s start by checking to see if mod proxy is enabled. This is simply a matter of verifying if /etc/httpd/conf/httpd.conf has these two lines:

LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so

In my case it was enabled so no work needed. Now we modify /etc/sysconfig/jenkins, at the end of the file we need to add some args to point at the path we want our Jenkins instance to be hosted at:

JENKINS_ARGS="--prefix=/jenkins"

Restart Jenkins (service jenkins restart) to have the changes picked up. You can test to see if it’s working on localhost:8080/jenkins. I tried, and failed to have this work for a nested path (ie: /path/to/jenkins), I suspect this is a Jenkins limitation but didn’t chase down the actual reason.

Next let’s create an Apache configuration file in /etc/httpd/conf.d/jenkins_proxy.conf with the following contents:

ProxyPass /jenkins http://localhost:8080/jenkins ProxyPassReverse /jenkins http://localhost:8080/jenkins ProxyRequests Off

# Local reverse proxy authorization override # Most unix distribution deny proxy by default (ie /etc/apache2/mods-enabled/proxy.conf in Ubuntu) Order deny,allow Allow from all

We need to restart the web server (service httpd restart) to have these changes picked up. As this is RHEL6 and it is running with SELinux enabled, we also need to allow httpd (Apache) to do proxy connections:

# setsebool -P httpd_can_network_connect true

Now at this point you should be able to visit http://yoursite.com/jenkins, and see that our proxy configuration is working. This is cool, but people can still talk to it via http://yoursite.com:8080/jenkins which will bypass Apache.

We’ll be using iptables to accomplish this. As you can see my system was running iptables, but everything was permitted.

# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT) target prot opt source destination

Chain OUTPUT (policy ACCEPT) target prot opt source destination

Use ifconfig to figure out what your ethernet card is (the one where external packets will come from), in my case it was eth6. So we can simply instruct iptables to drop packets destined to 8080 from that source, allowing only internal traffic (ie: the proxy) to pass.

# iptables -A INPUT -p tcp -i eth6 --dport 8080 -j DROP

That’s it, now users are forced to come in the correct front door (Apache). To make the iptables change permanent:

#service iptables save

So now the Apache web server is seeing traffic to Jenkins and can perform authentication, this is simple enough to add to the Apache configuration file we created that defined the proxy (/etc/httpd/conf.d/jenkins_proxy.conf) – I’ll leave that one up to the reader to sort out.

Makejail – limited SSH account on Ubuntu

Jail Cell in the Rock by hadsie, on Flickr

photo by hadsie

Previous I had covered how to setup scponly as a restricted fileserver environment. While this works well, it is very limited and didn’t allow for rsync to run (without heroics beyond what I was willing to do). Using makejail seems to be a better solution for my needs, and it turns out to be quite easy to setup on Ubuntu 12.04. On the journey here I had also tried out rssh which I also decided wasn’t a good fit.

You’ll of course need sshd installed which I’ll assume you have, and makejail which we can install easily:

$ sudo apt-get install makejail

Now we need to modify our openssh configuration by editing /etc/ssh/sshd_config, there are two changes we need to make. Modify the yes setting for UsePrivilegeSeparation:

# Disable Privilege Separation to allow chroot UsePrivilegeSeparation no
and at the bottom of the configuration file we’ll add:

Match User frank ChrootDirectory /home/frank AllowTCPForwarding no X11Forwarding no PasswordAuthentication no

Of course, for each restricted user you need to specify the username and home directory. You may have noticed that for the restricted users I’ve disabled password authentication, this is because changing the password is broken in the ‘jailed’ environment so we just avoid the issue by insisting on the use of keys (yes, you’ll need the restricted user to send you their public key to install in the .ssh/authorized_keys file of the restricted user).

Next we need to create a simple python script file that we can pass to makejail as a configuration file. I called mine jailconf.py and the contents look like:

chroot = "/home/frank" testCommandsInsideJail = ["bash", "ls", "touch", "rm", "rmdir", "less", "cat", "rsync" ]

Then execute makejail with this configuration file.

$ sudo makejail jailconf.py

For some reason, I needed to run makejail twice initially before it ran without errors – but it is something you can run multiple times with no serious side effects, this is handy if you want to add more commands later.

That’s it, now if you take a peek at the filesystem structure that’s been created – it’s a chroot environment. You’ll probably want to go in and create a /home/frank/stuff directory and assign ownership to the user so they can stick files there.

$ sudo ls -l /home/frank total 36 drwxr-xr-x 2 root root 4096 Sep 19 22:59 bin drwxr-xr-x 2 root root 4096 Sep 19 22:55 dev drwxr-xr-x 3 root root 4096 Sep 19 22:56 etc drwxrwxrwx 4 frank frank 4096 Sep 19 23:28 stuff drwxr-xr-x 4 root root 4096 Sep 19 22:55 lib drwxr-xr-x 2 root root 4096 Sep 19 22:55 root drwxr-xr-x 2 root root 4096 Sep 19 22:59 sbin drwxr-xr-x 2 root root 4096 Dec 5 2009 selinux drwxr-xr-x 5 root root 4096 Sep 19 22:55 usr

Now once you sort out the public key login (and remember to make sure the permissions on the .ssh directory and authorized keys are correct), the user frank will be able to log in and see the directory tree /home/frank as if it were the root of the filesystem. Only commands listed in the configuration file (jailconf.py) will be available to that user. Of course, if the filesystem is writeable (and executable) then they could always upload copies of the commands they want to run – but hopefully these are people you trust to some level.

References: I came to this solution initially through this article. There was a serverfault post that helped with the ssh configuration changes related to disabling password authentication.

In my case this is one component in allowing a friend to use my system as a remote (encrypted) backup site using rsync. I’ll post more details on that in the future.