LUG Community Blogs

The department of dirty

Planet SurreyLUG - 10 hours 57 min ago

I quite like the Open Rights Group‘s new campaign against internet filtering

The Department of Dirty is working with internet and mobile companies to stop the dirty internet. We are committed to protecting children and adults from online filth such as:

  • Talk to Frank: This government website tries to educate young people about drugs. We all know what ‘education’ means, don’t we? Blocked by Three.
  • Girl Guides Essex: They say, ‘guiding is about acquiring skills for life’. We say, why would young girls need skills? Blocked by BT.
  • South London Refugee Association: This charity aims to relieve poverty and distress. Not on our watch they don’t. Blocked by BT, EE, Sky and VirginMedia
We need you to help us take a stand against blogs, charities and education websites, all of which are being blocked [1]. It’s time to stop this sick filth. Together, we can clean up the internet.www.departmentofdirty.co.uk
Categories: LUG Community Blogs

Anton Piatek: The department of dirty

Planet HantsLUG - 10 hours 57 min ago

I quite like the Open Rights Group‘s new campaign against internet filtering

The Department of Dirty is working with internet and mobile companies to stop the dirty internet. We are committed to protecting children and adults from online filth such as:

  • Talk to Frank: This government website tries to educate young people about drugs. We all know what ‘education’ means, don’t we? Blocked by Three.
  • Girl Guides Essex: They say, ‘guiding is about acquiring skills for life’. We say, why would young girls need skills? Blocked by BT.
  • South London Refugee Association: This charity aims to relieve poverty and distress. Not on our watch they don’t. Blocked by BT, EE, Sky and VirginMedia
We need you to help us take a stand against blogs, charities and education websites, all of which are being blocked [1]. It’s time to stop this sick filth. Together, we can clean up the internet.www.departmentofdirty.co.uk
Categories: LUG Community Blogs

Mick Morgan: department of dirty

Planet ALUG - Wed, 23/07/2014 - 13:42

Like most ‘net users I get my fair share of spam. Most of it gets binned automatically by my email system, but of course some still gets through so I am used to hitting the delete button on random email from .ru domains offering me the opportunity to “impress my girl tonight”.

Most such phishing email relies on the recipient being dumb enough, naive enough, or (possibly) drunk enough to actually click through the link to the malicious website. I was therefore more than a little astonished at an email I received today from the open rights group. That email is given below in its entirety (I have obfuscated my email address for obvious reasons).

From: Department of Dirty
To: xxxxxxxx@yyy.zzz
Subject: Cleaning up the Internet
Date: Wed, 23 Jul 2014 07:14:18 -0400 (EDT)

Dear Mick,

Ever thought the internet was just too big? Want to help clean up online filth?

*Welcome to the Department of Dirty*

Watch the Department tackling its work here: www.departmentofdirty.co.uk and share our success, as we stop one man try to get one over us with his ‘spotted dick recipe’:

Department of Dirty Video: http://www.departmentofdirty.co.uk/

The Department of Dirty is working with internet and mobile companies to stop the dirty internet. We are committed to protecting children and adults from online filth such as:

*Talk to Frank: This government website tries to educate young people about drugs. We all know what ‘education’ means, don’t we? Blocked by Three.
*Girl Guides Essex:
They say, ‘guiding is about acquiring skills for life’. We say, why would young girls need skills? Blocked by BT.
*South London Refugee Association:
This charity aims to relieve poverty and distress. Not on our watch they don’t. Blocked by BT, EE, Sky and VirginMedia

This is just the tip of the iceberg.

We need you to help us take a stand against blogs, charities and education websites, all of which are being blocked [1]. It’s time to stop this sick filth. Together, we can clean up the internet.

http://www.departmentofdirty.co.uk

Sincerely,

Your Department of Dirty representative

[1] You can find out what we’re blocking at this convenient website: https://www.blocked.org.uk/

[DISCLAIMER] This email has come from the Open Rights Group. This email was delivered to: xxxxxxxx@yyy.zzz If you wish to opt out of future emails, you can do so here.

Now, I’m an ORG supporter (i.e. I am a paying member) and I am sure that someone, somewhere in ORG thought that this email campaign was a great idea. After all, it follows up the ORG’s earlier research on the fairly obvious stupidities arising from the implementation of Dave’s anti-porn campaign, it looks “ironic”, and it uses a snappy domain name which has shades of Monty Python about it. But I’m sorry, in my view this most certainly is not a good idea and I’m sure that ORG will come to regret it.

One of the most fundamental pieces of advice any and every ‘net user is beaten up with is “do not click on links in unsolicited emails”. In particular, the advice normally goes on – “if that email is from an unknown source, or has in any way a supicious from address you should immediately bin it”.

This email comes from an unknown address with a wonderfully prurient domain name. Even if it is successful and gets to the intended email inbox [1], it then relies on the recipient breaking a fundamental security rule. It does this by encouraging him (this looks to be male targeted) to click on a link which the naive might believe leads to a porn video.

How exactly is that going to help?

([1] Note. It got to my email inbox because the email system at e-activist.com which sent it is allowed by my filters.)

Categories: LUG Community Blogs

MJ Ray: Three systems

Planet ALUG - Tue, 22/07/2014 - 04:59

There are three basic systems:

The first is slick and easy to use, but fiddly to set up correctly and if you want to do something that its makers don’t want you to, it’s rather difficult. If it breaks, then fixing it is also fiddly, if not impossible and requiring complete reinitialisation.

The second system is an older approach, tried and tested, but fell out of fashion with the rise of the first and very rarely comes preinstalled on new machines. Many recent installations can be switched to and from the first system at the flick of a switch if wanted. It needs a bit more thought to operate but not much and it’s still pretty obvious and intuitive. You can do all sorts of customisations and it’s usually safe to mix and match parts. It’s debatable whether it is more efficient than the first or not.

The third system is a similar approach to the other two, but simplified in some ways and all the ugly parts are hidden away inside neat packaging. These days you can maintain and customise it yourself without much more difficulty than the other systems, but the basic hardware still attracts a price premium. In theory, it’s less efficient than the other types, but in practice it’s easier to maintain so doesn’t lose much efficiency. Some support companies for the other types won’t touch it while others will only work with it.

So that’s the three types of bicycle gears: indexed, friction and hub. What did you think it was?

Categories: LUG Community Blogs

Chris Lamb: Disabling internet for specific processes with libfiu

Planet ALUG - Mon, 21/07/2014 - 19:26

My primary usecase is to prevent testsuites and build systems from contacting internet-based services. This, at the very least, introduces an element of non-determinism and malicious code at worst.

I use Alberto Bertogli's libfiu for this, specifically the fiu-run utility which part of the fiu-utils package on Debian and Ubuntu.

Here's a contrived example, where I prevent Curl from talking to the internet:

$ fiu-run -x -c 'enable name=posix/io/net/connect' curl google.com curl: (6) Couldn't resolve host 'google.com'

... and here's an example of it detecting two possibly internet-connecting tests:

$ fiu-run -x -c 'enable name=posix/io/net/connect' ./manage.py text [..] ---------------------------------------------------------------------- Ran 892 tests in 2.495s FAILED (errors=2) Destroying test database for alias 'default'...

Note that libfiu inherits all the drawbacks of LD_PRELOAD; in particular, we cannot limit the child process that calls setuid binaries such as /bin/ping:

$ fiu-run -x -c 'enable name=posix/io/net/connect' ping google.com PING google.com (173.194.41.65) 56(84) bytes of data. 64 bytes from lhr08s01.1e100.net (17.194.41.65): icmp_req=1 ttl=57 time=21.7 ms 64 bytes from lhr08s01.1e100.net (17.194.41.65): icmp_req=2 ttl=57 time=18.9 ms [..]

Whilst it would certainly be more robust and flexible to use iptables—such as allowing localhost and other local socket connections but disabling all others—I gravitate towards this entirely userspace solution as it requires no setup and I can quickly modify it to block other calls on an ad-hoc basis. The list of other "modules" libfiu supports is viewable here.

Categories: LUG Community Blogs

Mick Morgan: drip

Planet ALUG - Mon, 21/07/2014 - 16:23

I get my domestic ADSL connectivity from the rather excellent people at Andrews and Arnold.

Here’s why. And this is the original reason I moved to them.

They also happily take (and similarly reply to) GPG encrypted support questions.

Good guys. Thoroughly recommended.

Now can you /really/ see BT doing any of that?

‘thought not.

Categories: LUG Community Blogs

Steve Kemp: An alternative to devilspie/devilspie2

Planet HantsLUG - Mon, 21/07/2014 - 15:30

Recently I was updating my dotfiles, because I wanted to ensure that media-players were "always on top", when launched, as this suits the way I work.

For many years I've used devilspie to script the placement of new windows, and once I googled a recipe I managed to achieve my aim.

However during the course of my googling I discovered that devilspie is unmaintained, and has been replaced by something using Lua - something I like.

I'm surprised I hadn't realized that the project was dead, although I've always hated the configuration syntax it is something that I've used on a constant basis since I found it.

Unfortunately the replacement, despite using Lua, and despite being functional just didn't seem to gell with me. So I figured "How hard could it be?".

In the past I've written softare which iterated over all (visible) windows, and obviously I'm no stranger to writing Lua bindings.

However I did run into a snag. My initial implementation did two things:

  • Find all windows.
  • For each window invoke a lua script-file.

This worked. This worked well. This worked too well.

The problem I ran into was that if I wrote something like "Move window 'emacs' to desktop 2" that action would be applied, over and over again. So if I launched emacs, and then manually moved the window to desktop3 it would jump back!

In short I needed to add a "stop()" function, which would cause further actions against a given window to cease. (By keeping a linked list of windows-to-ignore, and avoiding processing them.)

The code did work, but it felt wrong to have an ever-growing linked-list of processed windows. So I figured I'd look at the alternative - the original devilspie used libwnck to operate. That library allows you to nominate a callback to be executed every time a new window is created.

If you apply your magic only on a window-create event - well you don't need to bother caching prior-windows.

So in conclusion :

I think my code is better than devilspie2 because it is smaller, simpler, and does things more neatly - for example instead of a function to get geometry and another to set it, I use one. (e.g. "xy()" returns the position of a window, but xy(3,3) sets it.).

kpie also allows you to run as a one-off job, and using the simple primitives I wrote a file to dump your windows, and their size/placement, which looks like this:

shelob ~/git/kpie $ ./kpie --single ./samples/dump.lua -- Screen width : 1920 -- Screen height: 1080 .. if ( ( window_title() == "Buddy List" ) and ( window_class() == "Pidgin" ) and ( window_application() == "Pidgin" ) ) then xy(1536,24 ) size(384,1032 ) workspace(2) end if ( ( window_title() == "feeds" ) and ( window_class() == "Pidgin" ) and ( window_application() == "Pidgin" ) ) then xy(1,24 ) size(1536,1032 ) workspace(2) end ..

As you can see that has dumped all my windows, along with their current state. This allows a simple starting-point - Configure your windows the way you want them, then dump them to a script file. Re-run that script file and your windows will be set back the way they were! (Obviously there might be tweaks required.)

I used that starting-point to define a simple recipe for configuring pidgin, which is more flexible than what I ever had with pidgin, and suits my tastes.

Bug-reports welcome.

Categories: LUG Community Blogs

Meeting at "The Moon Under Water"

Wolverhampton LUG News - Mon, 21/07/2014 - 15:20
Event-Date: Wednesday, 23 July, 2014 - 19:30 to 23:00Body: 53-55 Lichfield St Wolverhampton West Midlands WV1 1EQ Eat, Drink and talk Linux
Categories: LUG Community Blogs

Steve Kemp: Did you know xine will download and execute scripts?

Planet HantsLUG - Sat, 19/07/2014 - 21:48

Today I was poking around the source of Xine, the well-known media player. During the course of this poking I spotted that Xine has skin support - something I've been blissfully ignorant of for many years.

How do these skins work? You bring up the skin-browser, by default this is achieved by pressing "Ctrl-d". The browser will show you previews of the skins available, and allow you to install them.

How does Xine know what skins are available? It downloads the contents of:

NOTE: This is an insecure URL.

The downloaded file is a simple XML thing, containing references to both preview-images and download locations.

For example the theme "Sunset" has the following details:

  • Download link: http://xine.sourceforge.net/skins/Sunset.tar.gz
  • Preview link: http://xine.sourceforge.net/skins/Sunset.png

if you choose to install the skin the Sunset.tar.gz file is downloaded, via HTTP, extracted, and the shell-script doinst.sh is executed, if present.

So if you control DNS on your LAN you can execute arbitrary commands if you persuade a victim to download your "corporate xine theme".

Probably a low-risk attack, but still a surprise.

Categories: LUG Community Blogs

Martin Wimpress: Monitorix on Debian

Planet HantsLUG - Sat, 19/07/2014 - 12:00

I have a few Debian servers that run at home and on VPSs. I wanted to add some basic systems monitoring to them, but didn't want anything too complicated to look after. I found Monitorix.

Monitorix is a free, open source, lightweight system monitoring tool designed to monitor as many services and system resources as possible. It has been created to be used under production Linux/UNIX servers, but due to its simplicity and small size can be used on embedded devices as well.

Install Monitorix

This install has been tested on Debian Squeeze and Wheezy. First install the dependencies.

sudo apt-get install rrdtool perl libwww-perl libmailtools-perl \ libmime-lite-perl librrds-perl libdbi-perl libxml-simple-perl \ libhttp-server-simple-perl libconfig-general-perl libio-socket-ssl-perl

Now Monitorix itself.

wget -c "http://apt.izzysoft.de/ubuntu/dists/generic/index.php?file=monitorix_3.5.1-izzy1_all.deb" -O monitorix_3.5.1-izzy1_all.deb sudo dpkg -i monitorix_3.5.1-izzy1_all.deb

At this point Monitorix is installed and running. Point your browser to http://example.org:8080/monitorix/ and enjoy!

Configuring Monitorix

Everything in /etc/monitorix/monitorix.conf is comprehensively documented, just get tweaking.

Each time you update the configuration Monitorix will require a restart.

sudo service monitorix restart nginx status

If you run nginx then you'll want to drop the following into /etc/nginx/conf.d/status.conf so that Monitorix can monitor nginx.

server { listen localhost:80; location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } } References
Categories: LUG Community Blogs

Jonathan McDowell: On the state of Free VoIP

Planet ALUG - Thu, 17/07/2014 - 23:08

Every now and then I decide I'll try and sort out my VoIP setup. And then I give up. Today I tried again. I really didn't think I was aiming that high. I thought I'd start by making my email address work as a SIP address. Seems reasonable, right? I threw in the extra constraints of wanting some security (so TLS, not UDP) and a soft client that would work on my laptop (I have a Grandstream hardphone and would like an Android client as well, but I figure those are the easy cases while the "I have my laptop and I want to remain connected" case is a bit trickier). I had a suitable Internet connected VM, access to control my DNS fully (so I can do SRV records) and time to read whatever HOWTOs required. And oh my ghod the state of the art is appalling.

Let's start with getting a SIP server up and running. I went with repro which seemed to be a reasonably well recommended SIP server to register against. And mostly getting it up and running and registering against it is fine. Until you try and make a TLS SIP call through it (to a sip5060.net test address). Problem the first; the StartCom free SSL certs are not suitable because they don't advertise TLS Client. So I switch to CACert. And then I get bitten by the whole question about whether the common name on the cert should be the server name, or the domain name on the SIP address (it's the domain name on the SIP address apparently, though that might make your SIP client complain).

That gets the SIP side working. Of course RTP is harder. repro looks like it's doing the right thing. The audio never happens. I capitulate at this point, and install Lumicall on my phone. That registers correctly and I can call the sip:test.time@sip5060.net test number and hear the time. So the server is functioning, it's the client that's a problem. I try the following (Debian/testing):

  • jitsi - Registers fine, seems to lack any sort of TURN/STUN support.
  • ekiga - No sign of TLS registration support.
  • twinkle - Not in testing. A recompile leads to no sign of an actual client starting up when executed.
  • sflphone - Fails to start (Debian bug #745695).
  • Empathy - Fails to connect. Doesn't show any useful debug.
  • linphone - No TLS connect (Debian bug #743494).

I'm bored at this point. Can I "dial" my debian.org SIP address from Lumicall? Of course not; I get a "Codecs incompatible" (SIP 488 Not Acceptable Here) response. I have no idea what that means. I seem to have all of the options on Lumicall enabled. Is it a NAT thing? A codec thing? Did I sacrifice the wrong colour of goat?

At some point during this process I get a Skype call from some friends, which I answer. Up comes a video call with them, their newborn, perfect audio, and no hassle. I have a conversation with them that doesn't involve me cursing technology at all. And then I go back to fighting with SIP.

Gunnar makes the comment about Skype creating a VoIP solution 10 years ago when none was to be found. I believe they're still the market leader. It just works. I'm running the Linux client, and they're maintaining it (a little behind the curve, but close enough), and it works for text chat, voice chat and video calls. I've spent half a day trying to get a Free equivalent working and failing. I need something that works behind NAT, because it's highly likely when I'm on the move that's going to be the case. I want something that lets my laptop be the client, because I don't want to rely on my mobile phone. I want my email address to also be my VoIP address. I want some security (hell, I'm not even insisting on SRTP, though I'd like to). And the state of the Open VoIP stack just continues to make me embarrassed.

I haven't given up yet, but I'd appreciate some pointers. And Skype, if you're hiring, drop me a line. ;)

Categories: LUG Community Blogs

Steve Kemp: So what can I do for Debian?

Planet HantsLUG - Wed, 16/07/2014 - 21:49

So I recently announced my intention to rejoin the Debian project, having been a member between 2002 & 2011 (inclusive).

In the past I resigned mostly due to lack of time, and what has changed is that these days I have more free time - primarily because my wife works in accident & emergency and has "funny shifts". This means we spend many days and evenings together, then she might work 8pm-8am for three nights in a row, which then becomes Steve-time, and can involve lots of time browsing reddit, coding obsessively, and watching bad TV (currently watching "Lost Girl". Shades of Buffy/Blood Ties/similar. Not bad, but not great.)

My NM-progress can be tracked here, and once accepted I have a plan for my activities:

  • I will minimally audit every single package running upon any of my personal systems.
  • I will audit as many of the ITP-packages I can manage.
  • I may, or may not, actually package software.

I believe this will be useful, even though there will be limits - I've no patience for PHP and will just ignore it, along with its ecosystem, for example.

As progress today I reported #754899 / CVE-2014-4978 against Rawstudio, and discussed some issues with ITP: tiptop (the program seems semi-expected to be installed setuid(0), but if it is then it will allow arbitrary files to be truncated/overwritten via "tiptop -W /path/to/file"

(ObRandom still waiting for a CVE identifier for #749846/TS-2867..)

And now sleep.

Categories: LUG Community Blogs
Syndicate content