MerriLUG Notes, 17-April-2008: Dan Walsh & SELinux

Eleven people attended the April meeting of MerriLUG, the Merrimack Valley chapter of the Greater New Hampshire Linux User Group. Heather called the meeting to order at 7:30 PM, noted the that attendees were pretty much The Usual Suspects, and dispensed with the long-winded announcements for new members. http://www.gnhlug.org will tell you all you want to know.

Dan Walsh was the main presenter tonight. Dan had a very special visit from the Demo Gods, just before he was to start. His hard drive decided that his boot partition wasn’t. Never heard of ext3. Ouch. Ever the good showman, he borrowed my laptop, downloaded his presentations from the web, and put on a great show.

Dan mentioned that he’d lost his previous laptop during his recent tour in Europe when it was stolen and that maintaining your home directory encrypted was a Good Idea.

Dan reviewed the history of SELinux and the iterations we saw in Fedora 3 though 8 and RHEL 3 through 5 and what to expect in 9. He talked about the evolution of the policies, the different feature sets available, how the SELinux architecture can meet the stringent requirements of DoD level organizations (with bullet points like: “RHEL5: MSP Policy: EAL4+, LSPP, RBAC” – who wouldn’t be impressed?) to the Significant Others at home who really just want a machine to use the browser on.

Dan showed off the new kiosk policy, xguest, which was essentially a minimal-permissions user (no setuid, no executables in the home directory, no installation abilities, etc.) extended to run FireFox. Perfect when someone wants to borrow your machine for a second! In the default settings (installable in F8 or 9 with sudo yum install xguest), it creates a fairly ‘safe’ user that can’t do a lot of harm and whose directories are temporary RAM-based and vanish when the user logs out. (You can modify it to keep a persistent home to store cookies and bookmarks.) Ideal for a library or public kiosk situations. Yes, the evil minded boys in the room could come up with some work-around exploits, but this is a promising start!

Thanks to Dan for a great presentation under trying circumstances, to Heather and Jim for managing and promoting the meetings, to Martha’s Exchange for providing the facilities, and to all who attended and participated.

UPDATE: Dan’s posted an article to Red Hat Magazine, “Confining the user with SELinux” that covers a lot of material in the presentation, with more detail than my notes and links for further study.

YA Javascript library: Ext

Sometimes I think the community of Javascript libraries is like a high school popularity contest, with crowds swarming one cool thing before dropping it and moving on to the next. In a project last year, we started with a little hand-coded JS to spice up the site a little bit, then started dipping into the bigger UI libraries of Dojo, script.aculo.us, Prototype and more as the clients expectations went through the roof. I still have deep misgivings on making a web site work like a rich client application using HTML, CSS Javascript and/or AJAX. It’s still a web page, not an RIA, and concerns over web-scale scalability, responsiveness, variation in the client machine (six different browsers, JS on or off, Flash on/off, various readers for accessibility to the visually impaired, rendering on small devices, etc.) make rolling-your-own a fool’s mission.

We’d stabilized on a set of tools long enough for me to start to dig deep into its capabilities, when along comes a suggestion we look at Yet Another JS library, Ext. It is impressive at first glance, no doubt, and the demos have the requisite whiz, bang, oooh and aaah. But concerns over maturity, licensing, suitability to task, cost of retooling existing pages make it a questionable switch. At some time you have to commit, people. Live with what you’ve got or face the costs of serious rewrite. The tenets of RAD, XP and “Agile” as promoted by Scott Adams in DIlbert, not true practitioners, have given folks in charge the impression that they can just chase after the next shiny thing and follow the fashions without concern to the engineering implications of launching a world-class web site. Ah, well, my consultant friends tell me. This is why we get the big bucks.

Now I hear tell jQuery is where its at…

Security firm cracks encryption for Microsoft’s wireless keyboards – heise Security

Ouch! Encrypted communications between your computer and peripherals have to be impractically difficult to crack. The encryption scheme described in “Security firm cracks encryption for Microsoft’s wireless keyboards – heise Security” is beyond pathetic. I hope other manufacturers have more reasonable encryption schemes. In the mean time, don’t type anything on a Microsoft wireless keyboard you wouldn’t want to see published like, say, your bank account password. Disgraceful!

Link via Schneier on Security

When is a document not a document?

When is a document not a document? Perhaps when it contains executable code. Executable code can do bad things to your computer if it has the security permissions to do so or if it exploits flaws in the way the document readers execute the code. A Word document with AutoRun macros is an executable program in the form of document. A web page containing Javascript (or JScript or VBScript or Java or Flash) is an executable. Without limiting what functionality these executables can access, an action as simple as opening a document or navigate to a web site can open your machine to exploitation.

The latest instance of this is a flaw in Adobe Reader for Windows that allows a specially crafted PDF file to exploit your machine via the mailto protocol link. The SANS Internet Storm Center documents that the PDF mailto exploit documents in the wild, that is, it’s possible for you to catch this nasty bug off a web page or via the mail.

If you’re running Windows and have Adobe Reader installed, make sure you are running the latest version (links are in the article above). And don’t open any files from untrusted sources. And don’t trust any source.