Tag Archives: BitTorrent Sync

Android, Chromebook, Linux

Howto: Android Development on Chromebook

18 Comments

Background

One the primary reasons I got the Chromebook was to support a broad range of development options on a Linux platform. The risk is that since it is a Chromebook, it is most definitely not a general purpose Linux environment – and some things may not be practical. Even inside a chroot jail, there are weirdnesses since it inherits the kernel and devices from the platform OS – ChromeOS.

In any case the following is a process I developed to implement an Android application development environment. There are many equally valid solutions, and perhaps better solutions, but this is a working / tested example of how to get from point A to point B.

Approach

Since the base platform I am using is a Chromebook 14 – with a x86 Haswell (64bit), Intel binaries will work fine – making life a quite a bit simpler. Unfortunately, it is not possible to install anything like Eclipse or Debian packages directly to the ChromeOS since the developers have (purposefully) not included most of the traditional shared libraries used in Linux. This minimalist approach to the ChromeOS means that it has a minimal attack surface for malware, but minimal opportunity for us to hack the OS.  As a point of trivia, ChromeOS appears to be based on a Gentoo build model – but it has been scrubbed clean of anything extraneous to the ChromeOS function.

However, since we are lucky enough to have a relatively polished / low pain solution to installing a chroot jail version of Ubuntu – Crouton, our system level approach will be:

  1. Switch the Chromebook to developer mode
  2. Install a Crouton based chroot jail version of Ubuntu on the SD-Card
  3. Install Oracle Java in the chroot jail (along with all of the rest of the pieces)
  4. Install BitTorrent sync to create a shared workspace for Android Studio
  5. Install adb and fastboot and verify operation with an Android device.
  6. Install Android Studio / test with Android device.

Note: All of the instructions below are based on name of my user (joeuser), the name of my SD-Card (chrome-32), and particular versions of the install packages. You will need to modify for your respective names / versions.

Step 1 – Developer Mode

Developer mode is a way to unlock your Chromebook a bit. Of course it is much less secure than the default ChromeOS mode, and setting developer mode means everything on the platform is erased – except the SD-Card . Additionally, switching it back to default mode will also clear everything (again). So any files you want to be persistent should be stored up in the Google drive or on the SD card. After you have mentally prepared yourself for that, take a shot at developer mode – it really is much more interesting than lockdown mode. The details are on my Chromebook Cookbook page. While you are there, spend some time and figure out how to switch between virtual terminals and set the password for ‘chronos’.

Step 2 – Ubuntu on Crouton Chroot

The default Crouton install installs the Crouton tools in /usr/local/bin and the chroot jail in /usr/local/chroots. With a 16GB internal hard drive, it is not practical to risk using most/all of the available local space for a chroot jail – so we should plan to store it off to the SD-Card. There are two basic approaches we can use to accomplish this. The first is to use command line arguments with the Crouton tools to point it at /media/removable/chrome-32 (which happens to be the name of my card). Another option is to symbolically map these directories to corresponding directories on the SD-Card. The first approach means that every time the crouton scripts are used, the command line arguments are needed, and the second approach means it is done one time up front (I recommend the second approach as the less stupid approach).

Open a chrosh (chrome shell – ctl-alt-t), and enter (with corrections for your sd-card name):

shell
cd /media/removable/chrome-32
sudo mkdir bin chroots
cd /usr/opt
sudo ln -s /media/removable/chrome-32/bin/ bin
sudo ln -s /media/removable/chrome-32/chroots/ chroots
ls -al

The last instruction should show the local directories with the symbolic mapping to the sd-card locations. This ensures that both the crouton tools and the chroot jail is installed to the SD-Card enabling a much easier restore if you somehow clear your system (it happens to me at least once a week).

FYI – If that happens, the Crouton install can be restored by recreating the symbolic links above. That’s it.

From here install a crouton chroot jail ubuntu with the following:

sudo sh -e ~/Downloads/crouton -r raring -t unity
sudo startunity

Note that in most cases I recommend Precise due to its stability, but in this case I went with Raring since it has support for ADB and Fastboot in the Ubuntu repository (and Precise does not). From inside the Ubuntu install, open a terminal and enter:

sudo apt-get install ubuntu-standard
sudo apt-get install ubuntu-desktop
sudo apt-get install ia32-libs
sudo apt-get install synaptic

Shutdown the Ubuntu chroot jail. You now have a fairly complete and clean Ubuntu Raring install, and this would be a good point to make a backup. Instructions are on the Crouton Cookbook page. Once again – when the backup is done, move it to Google Drive or the SD-Card for safekeeping.

Step 3 – Install Oracle Java

From the ChromeOS interface (VT1), you can download the  Java 7 JDK for 64 bit Linux – grab the tar.gz package from Oracle (not the RPM). It will download into the Downloads directory, which incidentally is mapped to the Downloads directory inside the Crouton chroot jail.

After the download is complete, switch over the Ubuntu interface on VT3, open a file manager and copy the Java 7 tar.gz package from Downloads to the home directory. Right click and extract. It should create a directory name something like ‘jdk1.7.0_45’ in the home directory. Open an editor and open ‘.bashrc’ and append the following:

PATH=${PATH}:/home/joeuser/jdk1.7.0_45/bin
JAVA_HOME=/home/joeuser/jdk1.7.0_45

This will make it easier for *some* apps to find the JDK. The JDK tar.gz file in the homedir can safely be deleted after this is done.

Step 4 – BitTorrent Sync

On the ChromeOS interface (VT1) download the Linux/64bit install package for BitTorrent Sync from http://www.bittorrent.com/sync/downloads. Open a terminal with <ctrl-alt-T> and enter:

cd /media/removable/chrome-32
sudu mkdir btsync
sudo chmod 777 btsync
cd btsync
mkdir android-studio

This creates a target sync directory that is readable / writable / executable to everybody for syncing. We will use it later.

When the download is complete, copy the tgz file to the user home directory(from the Ubuntu interface) . Extract the files in the home directory. This will create a directory that looks like ‘~/btsync_glibc23_x65’. On the Unity Desktop, click on the gear in the upper right corner and select ‘Startup Applications’. Under Command, browse to the btsync directory and select the ‘btsync’ app. The will configure the app to startup when the chroot is started – similar enough to a service for our purposes. After this is done, the tgz file in the homedir can also be deleted.

Start the app by double clicking from the file manager or reboot the chroot jail to force the app startup (and validate that it is configured correctly). On either the ChromeOS or Ubuntu interface, open a browser with URL ‘localhost:8888/gui’ to confirm that Bit Torrent sync is running. Configure according to directions – using the ‘bysync’ directory (on the SD-Card) we created above as the target. You will also want to create another endpoint to this share on a desktop, server, or other laptop to ensure your data is offloaded from your Chromebook.

Step 5 – ADB and Fastboot

ADB and Fastboot are really a make or break part of effectively using the Chromebook for Android development. Note that in Precise, the adb and fastboot packages need to be retrieved manually from the Debian repository. For details refer to the Ubuntu Cookbook page. In Raring, we can use the easier method shown below.

From the chroot Ubuntu interface on VT3, and open a terminal. Enter the following:

sudo apt-get install android-tools-adb
sudo apt-get install android-tools-fastboot
adb version
fastboot help

The last two lines confirm that both adb and fastboot are operational. The true test is to now plug in an Android test device and enter (this may take a couple of tries):

adb devices

If everything if functional the adb server should start and the attached device will be identified. Note that if the Android device is reasonably current, it will require onscreen approval before it connects to adb.

Step 6 – Android Studio

The last piece in this puzzle is Android Studio. From the ChromeOS interface, download the Linux/64bit install package from http://developer.android.com/sdk/installing/studio.html.

From the chroot jail (VT3) open a file manager and copy the Android Studio tgz file to the user home directory. Right click on the file and extract the files in the home directory. This will create a directory that looks like ‘~/android-studio’ with an ‘bin’ subdirectory. Once again, after this is complete the tgz file in the homedir can be deleted.

In order to make the launch script easier to find, we will put it on the PATH system variable. In the user home directory, edit ‘.bashrc’ and append the following:

PATH=${PATH}:/home/joeuser/android-studio/bin

In some cases, I discovered that the launch script did not seem to be picking up on the .bashrc updates, so it was necessary to define the JDK_HOME more explicitly. Use your favorite editor to open ‘~/andoid-studio/bin/studio.sh’. Right below the ‘#!/bin/sh’ line add the following:

JAVA_HOME=/home/joeuser/jdk1.7.0_45″

Open a terminal and enter ‘studio.sh’ to confirm that Android Studio was found and executed. If / when prompted, select the directory for the Oracle Java JDK. Android Studio should launch.

As a test we are going to create a new project (mostly with the defaults), except for project location. For the location, navigate to ‘media/removable/chrome-32/btsync/android-studio’. This will put the project files in the sync directory, which will then synchronize the project to your others systems on share. This is all part of that concept that everything should be stored in some “cloud” or at least off device.

At the project screen, create a new project and when it comes up on the screen, click the green arrow button at the top of the screen. The connected Android device should show up as an option, select it and go. Alternatively, you can create an emulator and use it. The app should install, run and show ‘Hello World’ on the interface.

Version Note: As part of my testing, I noticed that my initial version of Android Studio had functioning menu drop downs, but after I updated to the current version (0.32) the menus would no longer drop down. I confirmed this with both Precise and Raring on Unity. It may be worth testing Gnome as some point, or it may be fixed in some upcoming update to Android Studio. Overall – it did not prevent me from doing most activities since the control bar was fully functional.

Lastly – go to another node on your BitTorrent Sync share and confirm that the project was created and migrated to that system.

Wrapup / Notes

Overall the Android Studio IDE is fairly functional and well structured. I was able to test on both an external device and the emulator without any issues.  From a practical perspective, I am actually surprised at how easily this came together on a Chromebook. As far as the menu issues, this appears to be an Android Studio / Unity issue which could be resolved by using Eclipse/Android ADT tools or switching to a different window manager.

In Summary – This Chromebook Android Environment provides me with a very slick and portable Android Development environment without a lot of compromises.

Internet Security, Security

Howto: Share Files Securely/Privately

Leave a comment

Background

The joint concepts of Secure and Private are relative and subjective. Relative in that there are very few absolutes, but there are an infinite number of variations that may be better or worse. Qualifying “better or worse” is where the subjective comes into play. It is subjective in terms of who / what you are trying protect your files from. Is it your family, co-workers, your neighbors, the Internet, some large corporation trying to characterize you (in order to better sell to you), or the government? Depending on how good of a solution and who you are trying to protect your privacy from, we can look at a few easy (and practical) solutions.

Off the Shelf

There are off the shelf solutions that provide file sharing options. Dropbox, Box and Google Drive are three popular examples or cloud storage solutions – meaning your files are on their servers. Each one of these provides some degree of privacy / security. Each of these services use a username / password to restrict access, and additionally Google and Dropbox support two factor authentication using Google Authenticator. Each of these services uses SSL/TLS to provide a secure channel from the client to their servers. What they do not provide is any explicit privacy or security from the respective services or anybody with a NSL.

Fundamentally these services are not particularly private, secure, but they do provide some degree of security / privacy. If you use them and Two Factor Authentication is an option – use it.

A Better Option(s)

If the convenience of these services is appealing, but you have some real need for something more secure, we have a better solution. TrueCrypt is an disk encryption tool that can create secure containers for files. Specifically, Truecrypt can be used to create a secure file container in your GDrive/Dropbox/Box sync directory on your client system. This container can be opened by Truecrypt, files placed inside, and then be closed – at which point the service will sync the file up to their servers. They services will have access to the file, but its contents will be completely hidden from all except the keyholder. Note – a large container will hold lots of files, but the entire file will need to be synced even if there is a minor change – so consider wisely how large / small this container should be.

Another tool is Keepass, a secure password locker that is similar – but only for password / account information. Both of these tools are also cross platform and open source.

An Even Better Option

One of the core flaws with each of these cloud storage solutions identified above (as examples) is that ultimately all of your data resides on their servers within the providers data centers. BitTorrent Sync is a solution that breaks that paradigm by distributing files using the bittorrent protocols in a peer to peer (P2P) fashion. The result is that files can be distributed and shared between multiple users / platforms, but they do not exist on any cloud server – greatly reducing the risk of compromise-ever. BitTorrent Sync is easy to setup and use. Specifically, the app is installed and then you can create a share – and then generate a key – initiating a share. If you are connecting to an existing share, you create a share and provide the key for that share, and it will automagically be synced from the other clients on that share.

The most significant upside (other than P2P architecture) is that there are no storage or transfer limits – the only limitation being your local capacity.

The only significant downside to BitTorrent Sync is that synchronizations must be synchronous – since there is no cloud storage server, it requires that at least two members be online to synchronize.

For the truly insecure, TrueCrypt can be used on top of BitTorrent Sync.

Bottom Line

These are a few examples of how to secure / privatize file sharing on the Internet using relatively non-private services coupled with a few open source applications. However, it is very important to understand key management – since this security / privacy is only as secure as the keys you use to contain it. The applications themselves are fairly mature, well reviewed and generally accepted as secure.

Internet Security

How to Secure Dropbox (and others) – Part 1

Leave a comment

Personal security and privacy on the Internet are often seen as lost dreams – something we sacrificed in back in the 90s without a clue. In this blog, I cannot give this back to you, but my hope is to help you take back at least some parts of your personal online security / privacy piece by piece.

Background

One of the most interesting transformations in how people use the Internet is personal data convergence. In this model, a user may have a phone, a laptop, a tablet and a desktop system. Or another particular type of user would “roost” at different computers that were convenient. Personal data convergence is where that user has some mechanism or function to access and update a personal datastore from each one of these devices – fairly transparently. This is a big deal because (when done correctly) this process renders the platform or device transparent – enabling people to more effectively do what they do.

For example – at one time everybody had a home telephone, and each one had the same basic capabilities, and the primary value of having a telephone had very little to do with the actual telephone, and everything about the function and service – how it enabled the user. This personal data convergence means that each user can have their cloud of resources follow anywhere they go, and this has resulted in a proliferation of services that offer something like this. Examples include:

  • Dropbox – a basic client / server / cloud service that provides some gigabytes of data that can be synchronized between Windows, iOS, Android, Linux, OSX and others. Premium service offers more space. Free format allows any file type. Storage is at 2GB to 5GB, depending on their promotions.
  • Box – Similar to Dropbox with fewer client types supported, but more space (with the free service), which is at 10GB at this time.
  • GDrive – The Google spin on a user-centric filestore. This was originally an extension of their online office suite, and only supports specific file types.
  • Chrome – This is not a general filestore, but a specialized synchronization where all of the personal features of Chrome are stored in the Google Cloud. This includes favorites, cached usernames / passwords, cookies, history and configuration.
  • iCloud – The Apple spin of online backup / synchronization. It synchronizes and backs up the entire Apple universe of devices, but like most things Apple, there is more left unsaid than should be. We can guess that it is better than average, but no better than it has to be. But it will work well with Apple devices and it will look good the whole time.

The Issue

Each one of these has their value add / differentiator to appeal to some specific use case, but each one of these also has a significant structural security issue. In each of these services, data is essentially unsecured within the service provider. Seriously – although several (if not all) of these service providers will make strong statements about the level of encryption they use on their SSL/TLS connections and how data is encrypted on servers with some form of disk encryption, however if the keys are held by the same service provider – it means nearly nothing. In any case, this class of service is not going away – and will only increase in size and capability – but from a basic privacy and security perspective, it is one (big) step up from public storage on the Internet.

For example, right now, today – passwords for nearly every WiFi router (that is paired with a Android device – worldwide) is stored in Google servers. As part of the account backup process, Google has been backing up WiFi settings for the last several Android versions – which means hundreds of millions of WiFi passwords worldwide. Recall that Google Streetview got into some trouble over harvesting WiFi passwords, but now they build it into the Android ecosystem – and they get the passwords with no muss or fuss.

From a personal viewpoint – I see this consolidation of my online footprint, particularly private elements like usernames, passwords, and network access as something to be very uncomfortable with.

Security Theater in the Cloud

The following articles provide an entertaining juxtaposition between real security and security theater. Both are technically correct, but have very different messages.

With that perspective, now take a look at this post from Google regarding G-Drive encryption.

Yeah. As a security guy, i have to ask the question – Google and Apple have smart guys working there, lots of them. So if this is supposed to be real security, clue me in who the threat is? Based on the fact that in both cases they control the encryption and they control the keys, so it is not protected from these vendors, insider threats, anybody who could compromise their keystores, or National Security Letters. My cynical nature whispers to me and says it is security theater.

Is there a “fix” ?

For these service providers, there is no “fix” since the unsecured nature of their services is a key part of their business model. With this level of access to your personal data and files, they can build an incredibly detailed demographic profile of you as a consumer, you as a citizen, you as a security threat, and you as a future employee for any firm willing to get / buy the data. I don’t think it comes as any surprise that even if you pay for a service, a very subtle and implicit part of the cost is giving up any claim to privacy and security for the data stored in the service. This is very much a case of broken by design (and intent).  So any talk of a privacy / security “fix” is purely subjective and and not likely to be supported by the service providers. Depending on the service provider, they may consider it a violation of their terms of service. Caveat Emptor.

We have Options

If retaining your privacy and securing your personal data matter, we basically have three options.

1) Air Gap : Don’t put private / personal data in these services. It may sound excessive – but air-gapping your personal data from the Internet is the most robust privacy control you can use.

2) File Level Encryption: Use encrypted containers on the cloud sync service. Examples include Trucrypt and Keepass.

3) Private Cloud synchronization: Drop these services for something where you – the user, controls the encryption keys. Examples include BitTorrent Sync and SharePlan.

In any case, this is only part 1, and in part 2 I will expand on the options to better secure these synchronization services.