One thing I’ve wanted to do for years is to [...]]]> At the end of my talk on Monday about the status of SE Linux [1] I described some of the things that I want to do with SE Linux in Debian (and general SE Linux stuff). Here is a brief summary of some of them:

One thing I’ve wanted to do for years is to get X Access Controls working in Debian. This means that two X applications could have windows on the same desktop but be unable to communicate with each other by any of the X methods (this includes screen capture and clipboard). It seems that the Fedora people are moving to sandbox processes with Xephyr for X access (see Dan Walsh’s blog post about sandbox -X [2]). But XAce will take a lot of work and time is always an issue.

An ongoing problem with SE Linux (and most security systems) is the difficulty in running applications with minimum privilege. One example of this is utility programs which can be run by multiple programs, if a utility is usually run by a process that is privileged then we probably won’t notice that it requires excess privileges until it’s run in a different context. This is a particular problem when trying to restrict programs that may be run as part of a user session. A common example is programs that open files read-write when they only need to read them, if the program then aborts when it can’t open the file in question then we will have a problem when it’s run from a context that doesn’t grant it write access. To deal with such latent problems I am considering ways of analysing the operation of systems to try and determine which programs request more access than they really need.

During my talk I discussed the possibility of using a shared object to log file open/read/write to find such latent problems. A member of the audience suggested static code analysis which seems useful for some languages but doesn’t seem likely to cover all necessary languages. Of course the benefit of static code analysis is that it will catch operations that the program doesn’t perform in a test environment – error handling is one particularly important corner case in this regard.

• [1] http://etbe.coker.com.au/2013/01/28/selinux-status-lca2013/
• [2] http://danwalsh.livejournal.com/31146.html

People were wondering what [...]]]> A member of SAGE-AU [1] found two ATM skimmers [2] and gave me permission to publish his description and analysis of the situation. I’ve lightly edited this from a mailing list post to a blog format with permission from the author. This Courier-Mail article refers to the skimmers in question [3].

People were wondering what gave the skimmers away so here goes, NB this is only about the 2 I discovered.

1. The actual atms in question were the free standing type (but even this doesn’t matter in the scheme of things because they can be on those in a bank of the things).
2. I’d actually conducted transaction and was waiting for my card to come out of the machine – these things looked that good. The colours matched – especially in the 3/4 or less light that you typically have on the fascia’s of such machine. The backing plate grey matched atm fascia as did the green “bubble” where the card goes.
3. WHAT REALLY CAUSED SUSPICION – my card was having difficulty coming out of the atm at end of transaction i.e. card coming out extra slow – then only the end couple of mm, I had to physically grab my card with fingertips to get it out and there was barely perceptible movement of skimmer due to my fingers using the green “bubble” as purchase point, THAT was what made me suspect. I then really had close look and found that I could move the “bubble” with its backing plate – I pulled it off the machine and then looked at the atm next to it and found it to look exactly the same. These things are held on by double sided tape.
4. Grabbed the cleaning lady wandering past showed her the device and asked her to get security. Security and centre operations manager subsequently showed up, while waiting for them I had to stop people from using either machine (everyone amazed at how good these things looked). Centre ops guy went and checked other machines in the centre, I left my details and they called the cops… I went straight to my credit union and reported what had happened and they cancelled my card and ordered a new one on the spot for me.
5. Coincidently (or not) the centre ops and security lady told me that the machines had been serviced (refilled) not too much earlier that day – i.e. I wondered if the bad guys did the “service” or were tracking armaguard servicing types.

Quick side notes:

1. 3 more skimmers have been found since then.
2. Subsequently, I found out these were the type that needed to be picked up for the bad guys to retrieve the data i.e. these weren’t the type that transmitted to some-one sitting near by via Bluetooth/wireless i.e. in this instance I need not have cancelled my card and gotten a new one from my credit union.
   HOWEVER, it is best practice if you discover one and you’ve used that machine to immediately have your financial institution cancel your card and issue you a new one – though getting the new one can take up to a week.
3. As I understand it, These 2 devices (i.e. others could be different) have 2 usb ports one for the reader and the other to a pinhole camera (commercially available type removed from it’s original housing). The magnetic stripe data is held on the audio track associated with the video and there was an 8GB storage card to hold it all i.e. it makes things easier for the bad guys to match PINs to card details.
4. If you do find a skimmer DO NOT touch the insides (non public facing parts) of it – this is where the cops can really try lift dna and prints from; gathering prints from externally is far more fraught as everyone and their dog has probably touched the exterior of the skimmer.
5. In the lead up to Xmas these things or similar are highly likely to become more prevalent as we all go about parting with dosh while gift shopping – SO BE AWARE AND CAREFUL.

• [1] http://www.sage-au.org.au/
• [2] http://en.wikipedia.org/wiki/Skimming_(credit_card_fraud)#Skimming
• [3] http://tinyurl.com/aqu9yb6

At the moment I’m preparing an upload of the policy which will support KDE (and probably most desktop environment) logins and many little fixes related to server operations (particularly MTAs). I would like to get another version [...]]]> It’s almost the Wheezy freeze time and I’ve been working frantically to get things working properly.

Policy Status

At the moment I’m preparing an upload of the policy which will support KDE (and probably most desktop environment) logins and many little fixes related to server operations (particularly MTAs). I would like to get another version done before Wheezy is released, but if Wheezy releases with version 2.20110726-6 of the policy that will be OK. It will work well enough for most things that users will be able to use local changes for the things that don’t work.

One significant lack with the current policy is that systemd won’t work. I’ve included most of the policy changes needed, but haven’t done any of the testing and tweaking that is necessary to make it work properly.

I would like to see policy support for systemd in a Wheezy update if I don’t get it done in time for the first release. If I don’t get it done in time for the release and if the release team don’t accept it for an update then I’ll put it in my own repository so anyone who needs it can get it.

/run Labelling

One significant change for Wheezy is to use a tmpfs mounted on /run instead of /var/run. This means that lots of daemon start scripts create subdirectories of /run at boot time which need to have SE Linux labels applied for correct operation. The way things work is that usually the daemon will write to the directory immediately after the init script has created it, so I can’t just have my own script recursively relabel all of /run.

Some packages that need to be patched are x11-common #677831, clamav-daemon #677686, sasl2-bin #677685, dkim-filter #677684, and cups #677580. I am sure that there are others.

[ -x /sbin/restorecon ] && /sbin/restorecon -R $DIR

Generally if you are writing an init script and creating a directory under /run then you need to have some shell code like the above immediately after it’s created. Also the same applies for directories under /tmp and any other significant directories that are created at boot time.

Upgrading

Currently there are some potential problems with the upgrade process, I’m working on them at the moment. Ideally an “apt-get dist-upgrade” would cleanly upgrade everything. But at the moment it seems likely that the upgrade might initially go wrong and then work on the second try. There are some complications such as the selinux-policy-default package owning a config file which is used by mcstransd (which is part of the policycoreutils package), when the config file format changes you get order dependencies for the upgrade.

Kernel Support

My aim when developing a new SE Linux release for Debian is that the policy should work as much as possible with the user-space from the previous release. So if you upgrade from Squeeze to Wheezy you should be able to start the process by upgrading the SE Linux policy (which drags in the utilities and lots of libraries). This means that if you have a server running you don’t have to put it out of action for the entire upgrade, you can get the policy going and then get other things going. I haven’t tested this yet but I don’t expect any problems (apart from all the dependencies).

Also the policy should work with the kernel from the previous release. So if you have a virtual server where it’s not convenient to upgrade the kernel then that shouldn’t stop you from upgrading the user-space and the SE Linux policy. I’ve tested this and found one bug, the sepolgen-ifgen utility that you need to run before audit2allow -R won’t work if the kernel is older than the utilities #677730. I don’t know if it will be possible to get this fixed. Anyway it’s not that important, you can always copy the audit log to another system running the same policy to run audit2allow, it’s not convenient but not THAT difficult either.

The End Result

I think that the result of using SE Linux in Wheezy will be quite good for the people who get the upgrade done and who modify a few init scripts that don’t get the necessary changes in time. I anticipate that someone who doesn’t know much about SE Linux will be able to get a basic workstation or small server installation done in considerably less than an hour if they read the documentation and someone who knows what they are doing will get it done in a matter of minutes (plus download and install time which can be significant on old hardware).

At the moment I’m in the process of upgrading all of my systems to Unstable (currently Testing has versions of some SE Linux packages that are too broken). While doing this I will keep discovering bugs and fix as many of them as possible. But it seems that I’ve already fixed most things that affect common users.

Also BTRFS works well. Not that supporting a new filesystem is a big deal (all that’s needed is XATTR support), but having all the nice new features on one system is a good thing. Now I just need to get systemd working.