Acrobat Reader blocks my audio system, WTF?

I wanted to play a song (yes I have a legally bought copy from which I made the mp3) in mplayer and got the following result:

$ mplayer "01 - Adiemus - Karl Jenkins.mp3"



[...]

open /dev/dsp: Device or resource busy

After a few researches, I found:

# lsof /dev



[...]

acroread 32723 christophe 61r CHR 116,33 11606 /dev/snd/timer

acroread 32723 christophe 62u CHR 116,16 12023 /dev/snd/pcmC0D0p

An open document in Acrobat Reader was blocking my sound system. Why? No idea. I closed Acrobat Reader and opened it anew: no problem anymore.

For reference, it's a Ubuntu 8.04 on a PC, with a typical AC97 integrated chip. Package alsa-base is 1.0.16-0ubuntu4 and Acrobat Reader itself is 7.0.

EDIT1 30/04: I should say Adobe Reader, not Acrobat Reader, the former name.
EDIT2 30/04: The package acroread is version 7.0.9-0.0.ubuntu0.7.04+medibuntu2

Acrobat Reader dangerous target

Acrobat Reader, the most common PDF viewer, is a lot targeted by attackers, in the form of specifically crafted PDF files. Through such attacks, access can be gained into the infected system and other threats such as botnets can occur. The security company F-Secure recommends to replace it with an alternative viewer. (the news from slashdot)

I remember foretelling this to colleagues six months ago.

Shredding files [4/4]: Additional details on shredding

A link to the three previous bills, please read them first:

1. Why it's useless to "shred" files, most of the time
2. Shredding empty space
3. Please shred the hard drive

Then the matters I wanted to speak about.

First, the choice of the shredding software. Given the high number of vendors for that and the increasing number of rogue security software, I advise to take only software from a well-known vendor (from its official site or from a reseller) or opensource software.
I would bet that among all the software that claim to shred files, one quarter are rogue software.

Second, the views I gave in the three previous bills only take in consideration a part of the complexity of the question. For instance, different media (RAIDed hard drives, Flash memory...) may not follow the same behaviors as hard drives. Another example: filesystems are not considered. If the setup includes a rollback system at the filesystem level, then shredding empty space might not be efficient.

Third and final: let's think practical. There is no need to buy expensive software when you don't have a need for expensive functionalities. Most of the functionalities are covered by the tools included in a basic Linux distribution (thanks ketherius (RO) for the example). There is no need to shred everything everyday if you don't handle extremely valuable information (and even then...)

EDIT 22/06/09: If you can speak French, there has been an eXCellent discussion thread on the matter on linuxfr.org.

Discussing failures

Excellent bill by Michael Krigsman arguing that we should discuss failures of IT projects and show them as examples of what not to follow.
If I should sum up, here are the five factors that I saw as the root of failures of IT security projects in organizations (companies + public sector), along the years. The examples are invented.

1. "Political" interests priming over "intelligent" choices. Such as buying a solution from one vendor because the salesperson is Mr Bigboss's friend or the vendor is Mr Bigboss's favorite brand.
2. Bad top-down communication of the goals and objectives, which results in the implementation of a solution that solves problem B instead of problem A. For instance, Mr Bigboss decides that the crucial point is to protect the integrity of the central databases, but doesn't communicate it well and Mr Smallboss implements a solution that protects the confidentiality of the data going out of the central database. (This one seems simple to avoid once explained, but if you look back, I guess you can find a real example pretty easily.)
3. Relying on/Trusting too much service providers, thinking that getting the hands dirty is not necessary. This one results in entire sides of the project being forgotten, because the consultants only do what they are asked to.
4. Bad theory training of the administrators who will use the security solution. They know how to manipulate it but they don't understand the principles and they make bad interpretations of results. They are also not able to react when something goes out of the plan. This is particularly true of "all integrated" products with a shining graphical interface, where some people only retain the location of buttons and screens, and not their actual meaning/behaviour.
5. Allowing exceptions for top executives of the organization. Once a plan has been decided, everyone must follow it, including them.
   

Yes, security is fun [sometimes]

As matter of fact, security people need to watch carefully other people's security blunders so they indeed get a good laugh every time somebody falls in a known trap. (Less if the fallen one is their employer.) The problem is not to get some fun with security, it's to share it with normal, not-security people. XKCD comics takes the challenge, as is the case today:

Opensource revolution: a map for good!

A dozen of free software personalities were gathered today in Marne-la-Vallée, near Paris, for a little mediatized meeting. The meeting took place in a little pub called "Billy Bob's". Richard Stallman, Eric Raymond, Linus Torvalds could be seen there, and there have been rumors about other personalities such as Alan Cox, Vincent-Xavier Jumel, Bruce Perens, the billionaire Mark Shuttleworth or even Andrew Tanenbaum.

The object of the meeting was to make a planning for managed discussions to settle all of the main ideological problems of the free software offer. Of course the first question was to draw a list of these problems. After easy jokes on the choice of VI or EMACS, the hackers (in the good meaning of the term) decided that a short list would be better, and that new items would be added up to this list if the meetings proved successful. They agreed on the following points:

• Settle for a common communication around the issues of dual license and mixt products [auth: such as MySQL]. The various typical reactions of the GPL defenders should be limited so as not to lessen the progress made by these products that are, all in all, positive for free software.
• Decide of milestones to generalize binary compatibility between all Linux distributions, FreeBSD and OpenBSD. (To non-technical readers, this means that a program compiled for one of the systems should work on the other.) [auth: I wonder if Andrew Tanenbaum's Minix is in the intended target ^^]
  
• Update the Linux Standard Base to recommend the use of APT rather than RPM.
• Decide of a weapon of embargo against constructors of videocards and other hardware that don't release opensource drivers.
• Possibly include a Window Manager in the Linux Standard Base recommendation. [auth: this point was very debatted.]

This project, codenamed Opensource Map For Good (OMFG), is great news for all the users of free desktops. Linus Torvalds himself accepted to become the manager of this series of meetings. He said the complete report would be available on Monday. Let's wish them all good luck!

Shredding files [3/4]: Please shred the hard drive

At this point, we don't shred files anymore and we shred the empty space when we have time and a motivation.

Now, the last important step is not to forget to destroy all of the data when the hard drive is disposed of. There is a lot of data that you must destroy, even if you destroyed your main "My documents": Internet downloaded files, drafts that you may have forgotten, saved passwords or connection parameters...

There are countless stories of companies being spied upon by use of their old hard drives. To get rid of this threat, you can use a hard drive shredder such as the one below.



OK. So, good practice is to establish a policy that forbids hard drives (including internal hard drives in the printers and xerox machines) going out before a shred. Don't donate, sell or dump an old hard drive before a shred.