Tag Archives: ISO

I land back in Britain jetlagged, wake up from a brief sleep to find the news flooding my phone's news feed that the Linux distro, LinuxMint, had a bad day at the office. ISO images with backdoors and forum / website rooted and modified with some data potentially stolen.

The thing with LinuxMint is that it's a great project with high user figures, easy to run, it's the goto Linux for the user fed up with Windows and even I have a couple of Mint laptops. However, it's never been "security first and foremost" in the minds of the tiny release crew.

This post isn't going to attack the team behind Mint. Mint is a great project, it's default build does a lot of things right that other distros get wrong. In the default install it allows you to use whole of disk encryption and it also allows you to wipe the target disk and encrypt the user home directory which other distros do not by default. Thats a huge win for users. It's only let down by the default state of the build not defaulting to secure itself down using UFW or basic hardening out the box and a better state of repository awareness to ensure that a better security patching infrastructure isn't utilised. Anybody installing Mint who has a clue needs to spend 45 minutes post build tying it down, once achieved your workstation is pretty damn tight with one exception. That exception is underlying assured trust.

The packages for LinuxMint and other Ubuntu derived projects uses so much bleeding edge and community derived not sanitised code that it is very much a suck it and see approach, e.g you wouldn't deploy Mint in a commercial or workplace environment or anywhere where total data security was an issue. It's a lot more secure than Windows 10 so lets set that straight before we jump into the reasons why you shouldn't be using Mint now on an ongoing basis.

Mint, like many Linux distros before it is built on love. It's maintainer is an amazing guy who has put heart and soul into his project and worked miracles to get regular releases out the door. It's regularly hailed by my friend Stephen J Vaughn Nicholls as a great distribution. A great distribution for hobbyists. You can't compare say Fedora and Mint. Fedora is built on engineering and built by major engineering teams in the OSS community meeting at conferences worldwide (but still built on a tiny shoestring budget and goodwill). Mint relies on Ubuntu but ignores some of the basic security doctrines that Ubuntu has built in (e.g root user hardening) and also ignores some of the upstream patching conventions too.  Makes zero sense, but thats where we're at and you'd think in 2016 there would be more common sense approach to understanding user / sudo segregation and risk avoidance.

The issue with the rooting of the website was just daft. Reading the timeline on the website it looks to have been "handled quickly" and in good order but the damage to reputation may now already have been done. As a community project you never utterly control community gifted mirrors but you should have better controls over your portal and your storage of user data.

Already the finger pointing has started. I'm not sure it helps. One thing is for sure this is a bad day at the office for a project that has given a lot of home Linux users a first taste of Linux.  Mint is not a company with infinite resources and engineers, they're trying their best and marching on goodwill. Now is not the time to tar and feather now is the time to just nod your head and realise that it was a bad day at the office but it was a long time in the making.

Nothing wrong with being a hobbyist, thats where so much goodness in the community is derived.

If you want a Cinnamon flavoured workstation, install Fedora, install Fedy post install then install Cinnamon from the command line. Done. Secure and ready to go to work.

Now this was a fun show to record, talking to a realworld cloud architect at one of Hollands leading new technology companies Schuberg Philis who sponsored the Cloud event we've been attending this week.

Funs is one of two of their architecture team tasked with helping companies in Holland in the Schuberg Philis growing portfolio of customers to get to cloud safely, navigating governance and privacy regulation and ensuring their workloads and data are successfully transitioned to cloud.

Hope you enjoy the show more to come later if I still have power and bandwidth to get them out pre my flight back to the UK.

 Download the podcast in MP3 format here - or alternatively browse the RSS.

Those of you who have been reading my stuff for almost a decade or using the security stuff I've been writing and bringing to the market for more than that length of time will know that I have a passion for security as a business as usual accepted practice. That extends from perimeter security through to application level security and the chagrin of being intelligent about your management and change controls around every aspect of your deployment be it on-premise or in a third party hosted datacentre or hybrid/public Cloud.

One of the reasons for finally joining Red Hat is here is a company that has grown in every aspect of it's operation that is relied upon by the largest brands and the institutions we all rely upon to handle our financial transactions, our well being and the processing of our needs as consumers. I can be picky who I work for, I do this for the love, not remotely for the money and whoever I work with has to be able to add to what I bring to the table around the whole security value add. Never more so is that intrinsic to what we do as an industry as in Cloud. There is literally nowhere to hide. Security through obscurity is not a practical approach and a zero day exploit or a badly coded application or a drop in escalation of a privilege level can be the difference between a Cloud environment succeeding or failing and a platform collapsing like a pack of cards.

A conversation I often have with friends in the Security space is one of understanding risks. Mark Cox who runs the Security Response team at Red Hat is someone I've known for over a decade and who I talk to very regularly. He runs a blog outside Red Hat which is crammed full of illustrations around the maturity of security controls in the Red Hat release and engineering space (see this report from December around the vulnerabilities and advisories and our responses as a vendor for RHEL). Mark's team work very closely with the engineering teams in Westford and globally to ensure that our appetite for risk (given we're the platform people rely on to go to work) is entirely focused around visible responses in lightning fast windows.

So why is the title of this article talking about Aasholes, what is an aashole ?

For starters I'd have loved to have coined the description, to be the one adding this to the Cloud vernacular but unfortunately I can't take the praise for it. Fred Pinkett the popular blogger came up with it and it's the perfect word to describe a potential or actual security hole in a PaaS, SaaS or IaaS environment. I point you with genuine admiration to his article from June 2011 as a primer on the very basic needs and structures as you build your own Aashole Protection System (let's just refer to it going forward as an APS).

An APS can take many formats but one thing that I start to try and get across to people, and those of you who have sat and listened to me at conferences or across a table will hear me bang on about controls and mindset to deployment and beyond. I have long been a major fanbois for the Cloud Security Alliance and I work closely with their founder Jim Reavis (watch for an upcoming announcement soon from the CSA about working with Red Hat). Since 2009 I've been responsible for signing off and accrediting some of the largest Linux deployments in the most dangerous and critical parts of national and international infrastructure and in the defence sector (or defense for the majority of you reading this article appreciating you already think I spelt datacentre wrong earlier in this article). I would not have been able to do so without being able to take often badly written and badly managed higher level design documents and to cross reference them against the freely developed and distributed Cloud Security Alliance control matrixes or CCM's. I cannot stress heavily enough or place enough emphasis on why these are uber critical towards getting on your personal radars if you don't already know what I am talking about.

Here are some pointers why you should already be aware or using them !

1) These controls are free !!! If you haven't got a copy - get a copy.
2) If you read them and you build and deploy with them in mind you are going to have a very boring life but you'll be able to rely on your own deployed controls to avoid an Aashole incident.
3) They are a living, breathing document that changes over time - make sure you check for updates as the CSA community have more strength in depth than any blue chip consultancy security company / pen testing organisation / managed services organisation.
4) Working with them when designing your Cloud and working out which apps you can and can't move to a Cloudy environment and how you fit into legislative governance requirements and audit needs (PCI-DSS/ISO 27001/2/SAS 70/HIPAA etc) will save your organisations tens of thousands of dollars.
5) Using the CSA CCM matrixes alongside proven segregation controls such as sVirt and SELinux templates in RHEL / RHEV deployments will give you the strongest industry controls that you can find. Belt and braces.

So you have the Cloud Security Alliance freely propogating and educating more than any other body in the world around standards adoption and building security as a cornerstone of your application and provisioning environment and you have a healthy fear of a pink slip / P45 / being able to work again because you're an Aashat (I am claiming this one Fred - sorry) and more than anything you take a pride in what you do as an individual in your team or as a solo warrior in your Cloud efforts within your organisation.

Now if you didn't read Tim Kramer's article I posted last week on Security in the Cloud please go read it now.  We're all about playing safe and being sensible. Nobody wants to be the Aashat who didn't go the extra mile.

Last but not least we hope to have an interview in Podcast form with Jim Reavis from the CSA that we've been trying to get in the can for three weeks but we keep missing diaries / travel schedules. If you're in Germany and you want to go and hear him speak he's at the CSA conference in Frankfurt next week, details here.

You can also listen to a podcast I recently recorded with Gordon Haff and Ellen Newlands when I was in Boston around the whole Cloud Security piece in MP3 and OGG formats by following those links.

The Red Hat Security Knowledgebase

Mark Cox has asked me to point out that we have a Security Knowledgebase that is now for the first time publically available from access.redhat.com containing a depth of information that aligned with the CSA controls give you as a practitioner / administrator security in depth and able to work with us to move to Cloud even more securely. Alongside the cookbooks that are available on request (please feel free to ask me for more info) we hope that you find these massively useful.

Just in case anyone reading this has a sight impairment and uses a text to speech / Festival type converter I hope you didn't have a heart attack listening to the transcription of this article. Sometimes to get a very serious critical point across you have to bow to the influence of others and Fred Pinkett wrote the book on this.