Skip to main content

iterm2, tmux and the ever-present security

Being a freelance consultant I worry a lot. I worry that I might lose or misplace my laptop or worse that it falls into the hands of someone with less than honorable intentions. Of course you might also install a trojan, be attacked by a virus through multiple vectors.

As a result my clients' secret sauce falls into the wrong hands; or maybe my family's private information is leaked like credit cards or SSN.

This and far worse is possible. Unfortunately there are no absolutes. Not even if you built your OS and applications from scratch. First of all there is not enough time to code review everything you'd need. You are probably not a programmer and if you are there is only a slim chance that you can code everything from a video device driver to a web server and a word processor. (there are only a few on the planet and I'm certainly not one of them).

So the best way to protect yourself is a layered approach.

  • Pay for your hardware from somewhere reputable; HP, Dell, Apple.

  • Pay for your operating system or at least get it from a source with a profit motive. Red Hat, Fedora, Ubuntu, CentOS, Microsoft or Apple.

  • When you are installing Free software. Look for the profit motive. If you find one then it might be safe. If not then avoid it and look for one to pay for. OpenOffice is a good choice because it was once part of Sun but before that it might have been questionable.

  • The same can be said for websites, RSS feeds, torrents and so on.

  • And have some checks and balances. For example I use little snitch and Apple's firewall software to make sure that applications running on my computer do not have random access to the internet.


The profit motive is a strong magnet. It's what drives the thieves and it's also what will protect you.

So as I sit here playing with iTerm2, which I have been using for a long while, and tmux and I'm starting to get a case of butterflies. I'm confident that these programmers are good and lawful but I don't know them personally. The fact that one of them could put in a key logger and then stream that data to their servers make me sick. (hopefully little snitch will catch it but it's not foolproof.)

Anyway, practice safe computing.

Comments

  1. Thanks for the plug on using a "layered approach". It's easy to put all our eggs in one basket sometimes.

    Let me take this moment to say, "I know you probably know OpenBSD's reputation well", because you list it in your "recent focuses" list on your resume. So, the information below is just included for anyone else who happens across my comment. Also, know that I revere you and your prestigious reputation.(I know, I was certainly never an AIX developer.)

    I feel that your trust in a profit motive may be misplaced. Consider your current fear of "tmux". "tmux is part of the OpenBSD base system".(http://tmux.sourceforge.net/) As a part of the base system, tmux now undergoes a security audit by the OpenBSD security team.(It now gets more security attention than much of the "commercial" software that people use.) OpenBSD is an ideal example of a project that writes secure and open software because they want something to work well, and not because they want to make money or because they want to sneak in malicious code. As a result of their decision to be "number one in the industry for security", OpenBSD is unarguably more secure than popular commercial Operating Systems.

    Also, consider how Linux systems are developed. First, every distribution is made up of packages that are developed by varied organizations or individuals.(Most of which do not have a profit motive.) As an example, most Linux systems are, actually, GNU/Linux systems. Meaning, much of their userland comes from the GNU project.(Like gnucoreutils. -- ls, cd, mv, bash, etc.) GNU does not have a profit motive, but some of their software is in every Linux distribution.(Even RedHat and Ubuntu.) Then, Ubuntu itself is just a modified version of Debian GNU/Linux.(Debian is another project that does not have a profit motive.)

    Finally, we look at some commercial software. Mac OS X uses many pieces of open source software, such as: Bash, postfix, apache, GCC (if you have developer tools installed), python, ruby, perl, dovecot, openssh, sudo, etc. Infact, most of the command-line userland is made up of open source software that they pull in from other sources. (http://www.apple.com/opensource/)

    I agree that we should be cautious about what software we choose to install. Even with open source software we should either verify it is from an organization we trust(GNU, Apache, etc), verify that it has been distributed to us by an organization that we trust (Apple, Ubuntu, Debian, OpenBSD), or admit that we are taking a risk. But, a fear of software without a profit margin appears to be irrational.

    Long statement short, "use tmux with confidence", and "thank you for the interesting blog posts."

    ReplyDelete
  2. Certainly something to think about. Thank you for your opinion.

    ReplyDelete

Post a Comment

Popular posts from this blog

Entry level cost for CoreOS+Tectonic

CoreOS and Tectonic start their pricing at 10 servers. Managed CoreOS starts at $1000 per month for those first 10 servers and Tectonic is $5000 for the same 10 servers. Annualized that is $85K or at least one employee depending on your market. As a single employee company I'd rather hire the employee. Specially since I only have 3 servers.

The pricing is biased toward the largest servers with the largest capacities; my dual core 32GB i5 IntelNuc can never be mistaken for a 96-CPU dual or quad core DELL

If CoreOS does not figure out a different barrier of entry they are going to follow the Borland path to obscurity.

UPDATE 2017-10-30: With gratitude the CoreOS team has provided updated information on their pricing, however, I stand by my conclusion that the effective cost is lower when you deploy monster machines. The cost per node of my 1 CPU Intel NUC is the same as a 96 CPU server when you get beyond 10 nodes. I'll also reiterate that while my pricing notes are not currently…

eGalax touch on default Ubuntu 14.04.2 LTS

I have not had success with the touch drivers as yet.  The touch works and evtest also seems to report events, however, I have noticed that the button click is not working and no matter what I do xinput refuses to configure the buttons correctly.  When I downgraded to ubuntu 10.04 LTS everything sort of worked... there must have been something in the kermel as 10.04 was in the 2.6 kernel and 4.04 is in the 3.x branch.

One thing ... all of the documentation pointed to the wrong website or one in Taiwanese. I was finally able to locate the drivers again: http://www.eeti.com.tw/drivers_Linux.html (it would have been nice if they provided the install instructions in text rather than PDF)
Please open the document "EETI_eGTouch_Programming_Guide" under the Guide directory, and follow the Guidline to install driver.
download the appropriate versionunzip the fileread the programming manual And from that I'm distilling to the following: execute the setup.sh answer all of the questio…

Prometheus vs Bosun

In conclusion... while Bosun(B) is still not the ideal monitoring system neither is Prometheus(P).

TL;DR;

I am running Bosun in a Docker container hosted on CoreOS. Fleet service/unit files keep it running. However in once case I have experienced at least one severe crash as a result of a disk full condition. That it is implemented as part golang, java and python is an annoyance. The MIT license is about the only good thing.

I am trying to integrate Prometheus into my pipeline but losing steam fast. The Prometheus design seems to desire that you integrate your own cache inside your application and then allow the server to scrape the data, however, if the interval between scrapes is shorter than the longest transient session of your application then you need a gateway. A place to shuttle your data that will be a little more persistent.

(1) storing the data in my application might get me started more quickly
(2) getting the server to pull the data might be more secure
(3) using a push g…