Blog

  • Securing WordPress with AppArmor

    WordPress is a very popular CMS. According to one report, 30% of websites use WordPress, which is an impressive feat.

    Despite this popularity, WordPress is built upon PHP which is often lacking in the security department. Add to this that the user that runs the webserver often has a fair bit of access and there is no distinguishing between the webserver code and the WordPress code and you set yourself up for troubles.

    So, let’s introduce something that not only can tell the difference between Apache running and WordPress running under it, but also limit what WordPress can access.

    As the AppArmor wiki says “AppArmor is Mandatory Access Control (MAC) like security system for Linux. AppArmor confines individual programs to a set of files, capabilities, network access and rlimits…”.  AppArmor also has this concept of hats, so your webserver code (e.g. apache) can be one hat with one policy but the WordPress PHP code has another hat and therefore another policy. For some reason, AppArmor calls a policy a profile, so wherever you see profile translate that to policy.

    The idea here is to limit what WordPress can access down to the files and directories it needs, and nothing more. What follows is how I have setup my system but you may need to tweak it, especially for some plugins.

    (more…)
  • WordPress 4.9.1

    After a much longer than expected break due to moving and the resulting lack of Internet, plus WordPress releasing a package with a non-free file, the Debian package for WordPress 4.9.1 has been uploaded!

    WordPress 4.9 has a number of improvements, especially around the customiser components so that looked pretty slick. The editor for the customiser now has a series of linters what will warn if you write something bad, which is a very good thing! Unfortunately the Javascript linter is jshint which uses a non-free license which that team is attempting to fix.  I have also reported the problem to WordPress upstream to have a look at.

    While this was all going on, there were 4 security issues found in WordPress which resulted in the 4.9.1 release.

    Finally I got the time to look into the jshint problem and Internet to actually download the upstream files and upload the Debian packages. So version 4.9.1-1 of the packages have now been uploaded and should be in the mirrors soon.  I’ll start looking at the 4.9.1 patches to see what is relevant for Stretch and Jessie.

  • Back Online

    I now have Internet back! Which means I can try to get the Debian WordPress packages bashed into shape. Unfortunately they still have the problem with the json horrible “no evil” license which causes so many problems all over the place.

    I’m hoping there is a simple way of just removing that component and going from there.

  • Short Delay with WordPress 4.9

    You may have heard WordPress 4.9 is out. While this seems a good improvement over 4.8, it has a new editor that uses codemirror.  So what’s the problem? Well, inside codemirror is jshint and this has that idiotic no evil license. I think this was added in by WordPress, not codemirror itself.

    So basically WordPress 4.9 has a file, or actually a tiny part of a file that is non-free.  I’ll now have to delay the update of WordPress to hack that piece out, which probably means removing the javascript linter. Not ideal but that’s the way things go.

     

  • psmisc 23.0

    I had to go check but it has been over 3 years since the last psmisc release back in February 2014. I really didn’t think it had been that long ago.  Anyhow, with no further delay, psmisc version 23.0 has been released today!

    Update: 23.1 is out now, removed some debug line out of killall and shipped two missing documents.

    (more…)

  • The sudo tty bug and procps

    There have been recent reports of a security bug in sudo (CVE-2017-1000367) where you can fool sudo into thinking what controlling terminal it is running on to bypass its security checks.  One of the first things I thought of was, is procps vulnerable to the same bug? Sure, it wouldn’t be a security bypass, but it would be a normal sort of bug. A lot of programs  in procps have a concept of a controlling terminal, or the TTY field for either viewing or filtering, could they be fooled into thinking the process had a different controlling terminal?

    Was I going to be in the same pickle as the sudo maintainers? The meat between the stat parsing sandwich? Can I find any more puns related somehow to the XKCD comic?

    TLDR: No.

    (more…)
  • WordPress 4.7.2

    When WordPress originally announced their latest security update, there were three security fixes. While all security updates can be serious, they didn’t seem too bad. Shortly after, they updated their announcement with a fourth and more serious security problem.

    I have looked after the Debian WordPress package for a while. This is the first time I have heard people actually having their sites hacked almost as soon as this vulnerability was announced.

    If you are running WordPress 4.7 or 4.7.1, your website is vulnerable and there are bots out there looking for it. You should immediately upgrade to 4.7.2 (or, if there is a later 4.7.x version to that).  There is now updated Debian wordpress version 4.7.2 packages for unstable, testing and stable backports.

    For stable, you are on a patched version 4.1 which doesn’t have this specific vulnerability (it was introduced in 4.7) but you should be using 4.1+dfsg-1+deb8u12 which has the fixes found in 4.7.1 ported back to 4.1 code.

  • axdigi resurrected

    Seems funny to talk about 20 year old code that was a stop-gap measure to provide a bridging function the kernel had not (as yet) got, but here it is, my old bridge code.

    When I first started getting involved in Free Software, I was also involved with hamradio. In 1994 I release my first Free Software, or Open Source program called axdigi.  This program allowed you to “digipeat”. This was effectively source route bridging across hamradio packet networks. The code I used for this was originally network sniffer code to debug my PackeTwin kernel driver but  got frustrated at there being no digipeating function within Linux, so I wrote axdigi which is about 200 lines.

    The funny thing is, back then I thought it would be a temporary solution until digipeating got put into the kernel, which it temporarily did then got removed.

    Recently some people asked me about axdigi and where there is an “official” place where the code lives. The answer is really the last axdigi was 0.02 written in July 1995. It seems strange to resurrect 20 year old code but it is still in use; though it does show its age.  I’ve done some quick work on getting rid of the compiler warnings but there is more to do.

    So now axdigi has a nice shiny new home on GitHub, at https://github.com/csmall/axdigi

  • procps 3.3.12

    The procps developers are happy to announce that version 3.3.12 of procps was released today. This version has a mixture of bug fixes and enhancements. This unfortunately means another API bump but we are hoping this will be fixed with the new library API coming soon.

    procps is developed on gitlab and the new version of procps can be found at https://gitlab.com/procps-ng/procps/tree/newlib

    procps 3.3.12 can be found at https://gitlab.com/procps-ng/procps/tags/v3.3.12

    (more…)

  • Displaying Linux Memory

    Memory management is hard, but RAM management may be even harder.

    Most people know the vague overall concept of how memory usage is displayed within Linux. You have your total memory which is everything inside the box; then there is used and free which is what the system is or is not using respectively. Some people might know that not all used is used and some of it actually is free.  It can be very confusing to understand, even for a someone who maintains procps (the package that contains top and free, two programs that display memory usage).

    So, how does the memory display work?

    (more…)