Search Results: "nate"

13 November 2006

Wouter Verhelst: #include <stdarg.h>

The stdarg API, which allows you to use a variable number of arguments to a function in C, is pretty fun. However, it's also pretty limited in what it allows, to a degree that it invites people to try and find workarounds to things you can't do with the API as it is documented. Unfortunately, this almost always breaks when the software is compiled on hardware that happens to be not your own, as there is a reason why stdarg is implemented the way it is: portability. A (not so) recent discussion on #debian-devel on OFTC showed to me how this confuses many people. Don't worry—it confused me too, the first time I had to think about it. The problem is that in order for stdarg to be able to do what it does, it needs to read function arguments from whereever they are stored. Where that actually is depends on the operating system and the hardware you're using; it could be on the stack, but e.g., the SPARC architecture actually has a mechanism to pass parameters using processor registers (although those are most likely not used when stdarg is in use, since the number of parameters that can be passed that way is obviously pretty limited). If parameters are on the stack, then you may be able to just access the memory as you would access any random variable; but it could also be the case that you need to take some specific steps to access the stack, or perhaps your architecture or operating system has some protection for stack-based security attacks, which would make it impossible to directly access memory on the stack that is actually part of another subroutine. So if you try to do anything that isn't defined in the stdarg api (like trying to figure out the number of arguments by peeking inside the va_list data type, or passing a va_list to another function without using the C99 va_copy macro) will break. Yes. Very sorry.

Wouter Verhelst: Rock's kernel

I've decided it's been enough. Rock has been running 2.6.12 for ages. Not because I didn't want to upgrade, but since 2.6.12 was the last Debian-packaged kernel that would actually boot on rock. You see, this machine is a rather old SMP system, and there seems to be something wrong with its interrupt system. It would boot if I used a uniprocessor kernel instead, but then it's pretty silly to have a box with two processors, and only use one of them... At first I ignored it, assuming it would get fixed some time soon. Unfortunately, that didn't happen. And since we're at 2.6.18 right now, and the kernel team has done away with uniprocessor or SMP-only kernels, that means I can't even upgrade to the latest kernel anymore, even if I'd want to. I've been using git-bisect for the last few days in an attempt to find the issue, so that I can report it... only today I realized that I did remember 2.6.13 not to work, but that perhaps it failed for reasons not related to my current problem. Downloading that package from snapshot.debian.net and verifying showed that this is, indeed, the case. Grmbl. So I had to start all over again... Not fun. After starting that, I suddenly found out that make-kpkg didn't want to be friends anymore:
LC_ALL=C make-kpkg --initrd --config oldconfig --rootcmd fakeroot kernel-image
exec debian/rules  DEBIAN_REVISION=2.6.13-10.00.Custom  INITRD=YES  ROOT_CMD=fakeroot  kernel-image 
debian/ruleset/targets/source.mk:34: *** target pattern contains no  %'.  Stop.
wouter@rock:/usr/src/linux-2.6$ 
Hate. Grmbl.

Evan Prodromou: 21 Brumaire CCXV

Long day today (yesterday, actually, but I'm post-dating this in the interest of chronological flow). The baby's having a hard time coming off of West Coast time; she got up late and took a loooong nap till half-past three. Which was fine, because I needed the time to work on my NSLU2, which needed some attention. The NSLU2, or "Slug", is a tiny Linux computer from Linksys, about the size of a two packs of Marlboros laid side-by-side. My brother Nate gave me one last year for Christmas (thanks, nate), and I've been using it for network backups, but on our trip to SF Nate showed me that he's running all kinds of wild services off of his. So I decided to start shifting over some responsibilities to the little bugger. Which was just about time. Sometime during our trip to San Francisco, my main home server started having fan problems; it kept overheating and shutting itself down. It's going to take some time to diagnose the problem, but I figured that this was as good a time as any to move the critical services over to the Slug. The main one that needed budging was DNS. Maj's main domain, as well as my two .san-francisco.ca.us domains, run from home, because it's too hard to get the registrar to change them. The Unslung system I use for the Slug has a BIND package, which is a good thing to run, anyways. I was running MaraDNS on the big server, because I always root for the underdog, but there wasn't a MaraDNS package for the Slug. So I rewrote my zone files and things are up and running now. I don't know what else I'm going to put on there. Jabberd? Asterisk? A home wiki? Just not sure. tags:

Blah blah blah When the baby got up, we went to our local Loblaws, out towards the end of rue Rachel across from Canadian Tire. It's a pretty fantastic place to buy groceries -- it's the old CPR Angus Shops, a repair and maintenance facility for the Canadian Pacific Railway. The building is huge, with giant cranes and beams still attached to the roof. Amita and I grabbed a crapload of groceries and brought them home to Maj, who'd just had a massage at the centre around the corner and was feeling really good. She'd rented Tristram Shandy, the 2005 movie based on the 18th-century level-twisting novel. Me and Amita June made some baked potatoes, and we all watched the movie, and a good time was had. tags:
 

H****e en vrac One thing I always want to buy when I'm at the store in Quebec is the quite commonly available communion wafers. Yeah, really! big ol' 5-inches-diameter communion wafers, in the snack section next to the Doritos and the Humpty Dumpty potato chips. Quebec society has a had a precipitous secularization -- from around 90% church attendance in the 1950s to less than 10% today. But Catholicism still infuses all parts of life. For example, in Quebec, you cuss by using words from the church, including, of course, hostie ("the host"). So I can't figure out why hostie are a tasty snack treat. Is it a deliberate snub to the sacrament of communion by a secular society? Or did the practice antedate the Quiet Revolution, and did the formerly religious Quebecois eat communion wafers for fun? Or is it just a snork-snork funny thing to do, when the name of the food is actually a naughty word? I dunno. I'm fascinated, but not enough to buy a big bag of communion wafers to eat. (They're never cheese- or BBQ-flavored, by the way; they have a pristine seriousness to them.) More info solicited. tags:

Opinity One of the services mentioned in the Web 2.0 Summit infrastructure workshop was Opinity. Opinity seems to be a distributed reputation system, kind of like claimID but with a little more soft information. I think it looks pretty cool, and I'm glad to see another addition to the growing OpenID identity provider market. tags:

12 November 2006

Adam Rosi-Kessel: Toto, I Don't Think We're in Wikipedia Anymore

The last time I made any serious contributions to Wikipedia was back in 2001 or 2002. The community was exciting, friendly, and welcoming, and I enjoyed spreading the word as most non-technical people I knew had never heard of wikis or Wikipedia. Since then, I may have corrected the occasional typo or fixed a legal error, sometimes anonymously and sometimes under my account (apparently I “clarified the 13(c) protective arrangement issue” in the Urban Mass Transportation Act of 1970 back in the Fall of 2003, although I have no recollection of having done so), but I hadn’t started any new entries since the early days. At a recent presentation I attended by Sun’s Hal Stern, I learned that his eating club (Colonial Club) at Princeton University has a Wikipedia entry (as do all the other eating clubs). On further investigation, I learned there were no entries for any of the student cooperatives or other upperclassman eating options. To the uninitiated, it may be hard to understand why this matters beyond the insular Princeton community, but — suspend your disbelief just for a moment — the eating clubs have been called Princeton’s “peculiar institution” (a side-long reference to slavery) and have a storied and controversial history going back at least to the 1870’s (see, for example, this summary of the historical record from 1888-1993). It seemed to me that omitting the student cooperatives was akin to having a Wikipedia article on political parties that includes links to both the Republican and Democratic parties but leaves out any mention of the Green Party. Of course, the Green Party doesn’t wield the influence of either of the main parties, but its existence provides insight both into the American political system and the character of the two main parties. If no mention of the Green Party were included in Wikipedia, a foreign researcher attempting to learn about the American party system would come away with an incomplete and misleading understanding. The fact that the Green Party has not been particularly successful nationwide is, itself, interesting, useful, and relevant information. Although I wouldn’t pretend Princeton is as important or interesting as the American political system, it’s still a subject of scholarly investigation, and a topic that a fairly significant number of people are interested in learning about. I thought I would start basically a stub article for the Two Dickinson Street Co-op and spend a couple of days building it out and asking knowledgeable experts to contribute and add sources. Within a few seconds after I created the article, however, it was “speedily” deleted. A bit surprised, I tried to start an explanation as to why the entry warranted at least consideration for inclusion, and the article was deleted again and I found this message on my “talk” page:
This is your last warning.
The next time you vandalize a page, you will be blocked from editing Wikipedia. Diez2 14:55, 9 November 2006 (UTC)
I had gone from citizen to felon in two minutes flat! There then ensued several attempts to at least allow a debate on the deletion, but the article was unilaterally speedily deleted several times by several different editors. Even after one admin restored the article as not appropriate for “speedy deletion,” another admin stepped in and speedily deleted it again. I received some fairly acerbic retorts to my attempts — e.g. this: “We don’t have a page for every club in the world. If you want free web-hosting check out Myspace or usenet. Also anonymous postings do not make a topic notable or important.” (I’m not sure why he accused me of posting anonymously — I didn’t. Also, does “usenet” offer “free web-hosting?”) Finally, the deletion of the article was converted from a “speedy deletion” to a nomination as an “article for deletion” (‘AfD’), which allows at least for some discussion on the topic. The debate is ongoing — see it here — and some of the comments continue to be fairly corrosive. For example, one editor wrote:
Another editor called the debate a “pointless waste of time” over a “vanity article,” although I can’t find that comment any longer. I admit that I created the article without knowing much about the process, and certainly with little understanding of the numerous acronyms, flags, and the several different ways an article can be killed. Apparently, I didn’t contest the speedy deletion properly, although it wasn’t clear to me from the deletion notice exactly what I was supposed to do, and I assumed the restoration of the article by another admin meant that it would persist for at least a few days. I thus deserve some of the blame for not doing more pre-posting diligence, but I was relying for the most part on my 2001-2002 experience where you could create an article, spend a few days improving it, invite others to contribute, etc., and articles with a colorable argument for inclusion would generally stay in. It seems the new Wikipedia is a much less kind and less gentle Wikipedia. As another participant in the process wrote to me:
This whole situation is so strange. It makes me feel like I just stumbled into somebody else’s trench warfare. The defenders of notability! I wonder how long the constant vigilance of volunteers will hold out…
Of course, a similar phenomenon has occured with many open source projects. Initially, the doors are wide open and everyone’s contributions are, if not welcome, then at least tolerated. I suppose it is a sign of Wikipedia’s success that the front gates are locked so tightly. Still, I wonder how many potential good faith contributors are now permanently alienated by an initial bad experience such as this one, and whether Wikipedia will ultimately suffer from it. Low barriers to entry have traditionally been a key element to attracting participants to peer production efforts, but they seem to break down in direct relationship to the project’s external importance. Incidentally, Stern’s edit to the Colonial Club entry, mentioning F. Scott FitzGerald’s characterization of the club, was quickly reverted by another editor as “nonsense.”

Wouter Verhelst: Hardware support

A while back, my brother's computer had issues. It would dump core of random programs, and would produce a BSOD under Windows at random times, too. Running memtest86 showed that something was wrong with the memory, so we replaced it. Unfortunately, that didn't help; so the conclusion I made was that there was something wrong with something between the processor and the RAM—the cache (L1 or L2), some data or address line degrading, or perhaps even the memory controller. In any way, that didn't matter; what mattered is fixing the issue. So we replaced the mainboard and the processor with something newer. He's now got a pretty modern mainboard, with all the interesting bits and pieces found in such a thing, and a Dual Core Pentium4 at 3.4Ghz. Occasionally, I must say that the socket 775 is pretty... weird. But I digress. Upon installing everything, I found that trying to run the system with broken memory had managed to corrupt whatever was on the hard disk; his ReiserFS superblock thought the filesystem was some incredible amount larger than it really was, and Windows would turn up a BSOD before even booting. The first was pretty easy to fix; I hit 'e' in the grub menu, added init=/bin/bash to the end of the kernel command line, and instructed some tool from the reiserfs toolkit to fix the filesystem. After that finished, and after a subsequent exec /sbin/init finished, Debian was up and running again. That took all of a few minutes. Having booted it, I proceeded to install the security updates that had accumulated for Sarge since the time his system had started to break down (which is a few months). Then I realized that I had to reconfigure the system to understand the new mainboard. Only that had already happened. Hotplug, discover, and perhaps some friends, had all done their work and there was nothing to be done anymore. Isn't that nice. The same couldn't be said for Windows. Booting from the install medium and choosing "recovery" in the install menu didn't fix things. Even reinstalling the system without formatting the hard drive didn't get us any further. The only thing we could do was to wipe the drive clean and reinstall. Windows better hardware support? My ass.

11 November 2006

David Welton: Bicycling, Running, and Open Source Economics

I am very passionate about open source (or free software, or whatever you want to call it) software. In one way or the other, it seems I'm always drawn back to it, whatever else I'm supposed to be working on. I get a good feeling from the community aspects of it, believe in the potential for technological benefits, and appreciate that being open is often the best way to advance the state of the art. One thing that has always been something of a mystery though, is how the whole thing works in economic terms. There is no doubt in my mind that open source works in terms of creating value, but what isn't so simple is how it sustains itself, and where it makes sense. Some people, like Richard Stallman, sustain that all software should be free. Others take a more laissez faire attitude. Aside from philosophical debates, though, there is a very pragmatic question of how it works in practice, and if the process could be made more efficient, and in which cases should one simply decide to 'go proprietary' in terms of maximizing monetary returns. In the proprietary software world, this is all rather "simple" - (well, conceptually at least - it's not actually easy for anyone). If you write some software that you then sell, and people like it, they'll buy it, which in turn gives you money that you can funnel back into improving the product. If it stinks, you won't get any money, and presumably you'll move on to something you are more qualified for. It's a pretty simple and direct feedback loop. With free software though, it gets much more complex, because there is not necessarily an economic link between users and developers, which might mean that while the software provides very real economic benefits in terms of flexibility, avoiding vendor lock in, and low costs, none of those benefits necessarily flow to the person or people who actually wrote the software. This, in turn, means that they may have to support themselves in some other way and may not be able to dedicate much time to working on the code. This system is thus 'inefficient', because there is a disconnect between the value and the person who created it. A lot of thought has been dedicated to "solving" this problem, but it doesn't seem to have a satisfying answer just yet, although there are several free software companies that clearly do function, with a variety of models. One of the original ideas about how people would live in an entirely free software based economy, proposed by Stallman, is services. In other words, the software is free, but you get money to fix it, teach people about it, improve it, provide support for it, customize it and so on. While riding my bike around the Colli Euganei the other day, it occured to me that a pure services business is a lot like running. The minute you have fewer clients, go on vacation, or otherwise ease up... revenue drops proportionately, just as if you had slowed from a run to a walk. Ease off on the effort completely, and the money is gone, because you have no way of carrying your momentum forward. With a bicycle, on the other hand, it's more like a product-based business. It's certainly still an effort, and you have to be strong to beat your competitors, however, you can stop pedaling for a moment now and then, and you do get the descents after riding up the hills, and for a few meters at least, you can stop pedaling altogether and coast. What prompted me to think about products versus services was a small web application I developed recently. It's a nice ajaxy to-do list/time-tracker that I started developing with Ruby on Rails. My first instinct, and the easiest thing to do, of course, would be to open source it and let it go at that, but... I also wonder if I could make a little bit of money at it if I were to commercialize the product somehow. Not "get rich quick" money, but enough to pay me back for the time I sunk into making it work, and enough to let me justify doing more work on it to meet people's needs and requests. A couple of strategies come to mind: Whatever ends up happening with it, I'll be sure to post further information as it becomes available.

Andrew Pollock: [tech] What, no abstracts?!

I'm currently debating whether to go to linux.conf.au or not. I'd really like to go, because I didn't make it to Dunedin last year, and it really is the most rocking conference in the world. The catch is, I've already scored two work-funded trips this year, and I will have only barely returned from the second one by the time I'd be wanting to head off to Sydney again, so I don't feel right about asking for work to fork out for this, even though it's reasonably justifiable. I also want to go to Debconf in 2007, and I'd rather that one be covered. So I'll feel more comfortable forking out for it myself. So I now have to decide whether it's worth the airfare, the negative vacation balance, the two 20 hour flights in a week joy that is flying from San Francisco to Sydney and back again. And all I have to base this on is the title of the presentation and the presenter's name. Oh, the huge manatee! That said, on the face of it, there's enough tracks with at least one presentation that look like they whet my appetite that I would be prepared to go based on the face value of the program. I'll mull it over some more.

10 November 2006

Russell Coker: flash for main storage

I was in a discussion about flash on a closed mailing list, so I'll post my comments here.

I believe that flash will soon be suitable for main storage on most desktop and laptop machines (which means replacing the vast majority of the hard drive market). Flash survives mechanical wear much better than hard drives (flash storage in a camera will usually survive the destruction of the camera), it produces less heat and less noise, and it has better seek times. It is more expensive, although the price is coming down and the main problem now is the number of writes that can be made.

Flash is widely regarded as being slow for bulk IO (benchmark results I have seen approach 10MB/s - while 60MB/s is common for cheap desktop IDE disks). I am not sure how much of this is inherent to flash technology and how much is due to the interface used to access the flash. I often work with Gig-E networks, but for my home use I only have 100baseT, so I have little need for more than 10MB/s IO rates at home.

It is generally regarded that a sector of flash storage wears out at between 10,000 and 1,000,000 writes depending on how recent the hardware is and who you talk to (some vendors are more optimistic than others regarding the usable life of their devices).

Let's assume that you have a 32G flash module running JFFS2 with an average of 2G free (30G of long-term data that doesn't change and 2G of space that is used for new files). Let's assume that the most pessimistic prediction for flash reliability of 10,000 writes happens to be correct. So if 10,000 writes are to be made to that 2G of space that means 20T of data written! If we assume that the machine will be obsolete in 5 years then that allows us an average of just over 10G of data written per day (20,000/365/5=10.9). On my laptop iostat reports the following after 5 days of uptime:

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
hda 1.94 9.94 20.33 4614118 9439808
I believe that this means an average of 20 blocks were written per second over the last 5 days with a block size of 4K (page size), this means 6.6G per day. Clearly something is wrong with my laptop as there should not be so many writes, but even so I wouldn't expect it to wear out within 5 years if I used only flash storage. Incidentally I do a lot of travelling and generally find that I'm lucky if a laptop hard drive lasts three years. So I could expect flash to last longer than a hard drive for my laptop use.

When flash fails I believe that only a small part of the data will be lost, which is better than the hard drive failure condition which is often to lose everything!

Also there is nothing preventing you from creating a RAID-1 of flash devices. Last time I checked the JFFS2 kernel code didn't support such things but that could be fixed if there was suitable hardware.

Note that JFFS2 is vastly preferable to using Ext3 or similar filesystems on a flash device. Flash needs wear-levelling (spreading the write load over all parts of the disk) for sane operation. JFFS2 has this built in to the filesystem, while Ext3 etc are designed to repeatedly write the same parts of the disk. This means that to use Ext3 you need a mapping layer that does wear-levelling which causes inefficiency. Also JFFS2 has compression built in (same method as gzip). This is good for smaller flash devices (EG the 32M storage that was common in iPaQs), and also reduces the wear on larger storage.

The biggest problem for me in using flash at the moment is the lack of support for XATTRs (needed for SE Linux) in JFFS2. KaiGai Kohei has been working on this, it's been a while since I checked on the progress so I'm not sure if it's got into the kernel.org repository yet.

Another problem with flash is that it is totally unsuitable for use as a swap device. This means that you need to have so much RAM that swap is not needed. Fortunately desktop machines with 2G of RAM are becoming common.

Michael Janssen: It's too late baby, now it's too late

Getting to the gym consistently is one of the biggest hurdles that I have stuck to jumping over while I'm trying to lose a bit more than a few. I seem to have no consistent schedule, except that I do end up doing it every day that I can. One downside of this is that I tend to work out late at night, almost always an hour or less before I go to bed. I've heard that this is not the best for the sleep, but I suspect it is actually better than nothing, so I continue to get to the gym at 11pm or 12pm. Unfortunately, I found myself with some extra roadblocks this week: the exercise room was half broken. The breakers on one half of the room tend to trip when the air conditioner and two machines that are on that circuit are all in use. This means that no one can use those machines until someone from the coop management goes and resets the switch. The treadmill machine, my weapon of choice for shedding a few pounds, is inconveniently on this circuit, and can't be plugged in anywhere else. This happened 3 times this week, Wed-Fri. I'm calling the office for the second time tomorrow.

It is significantly harder to exercise when I don't have the treadmill handy — the stepping machine works on semi-powered days, but it tires me out much too quickly and I cannot get enough exercise in. I'm not the kind of person to reliably run in place or do jumping jacks. My solution was to move the exercise bike to the powered side of the room. The biggest problem with semi-powered days is motivation. Usually I have the motivation to get to the exercise room and start the machine, and once I've started I can stop. Opening the door to a bunch of non-working machines is a huge motivation hit though. It's so much easier to take a roadblock like this and skip a day — in fact I did this week once. Luckily I discovered that the bike is on wheels on one side so it is easy to move to the other side of the room. However, I'd like to solicit suggestions for alternate exercises for semi-power days. The things that work in the room are a weight machine with a bunch of attachments, the stepping machine, and the exercise bike. I can't really go outside and exercise, because of the late hour and neighborhood that I live in, so it needs to be an inside task. The last requirement is that it focuses on losing weight, not gaining muscle. I'm fairly sure that I'll be gaining some muscle along this process, but the goal is to drop the weight.

I have taken Saturdays to be my day off, so that I can get a little rest and not be so stressed about things, but I'm not taking it this week as I need to "make up" for the skipped day.

This week (Nov 3 - Nov 9):
Minimum: 338.0 (-0.5) (Nov 7)
Maximum: 340.0 (-1.0) (Nov 4)
Average: 339.25 (-0.35) (139.25 to goal)
Exercise Calories: 2314 on 5 days
Average Calories per session: 462.8

Roland Mas: Timfx 0.2.2-1

Jens wants me to sponsor timfx 0.2.2-1, which fixes an FTBFS bug. Unfortunately, it also removes the automatic updating of the config. sub,guess files. Since it's an useful feature, I told him to un-remove that, then I'll upload 0.2.2-2.

9 November 2006

Russell Coker: a good security design for an office


One issue that is rarely considered is how to deal with office break-ins for the purpose of espionage. I believe that this issue has been solved reasonably well for military systems, but many of the military solutions do not apply well to civilian systems - particularly the use of scary dudes with guns. Also most office environments don't have the budget for any serious security, so we want to improve things a bit without extra cost. Finally the police aren't interested in crimes where an office is burgled for small amounts of cash and items of minor value, it gets lost in the noise of junky burglaries, so prevention is the only option.

Having heard more information about such break-ins than I can report, I'll note a few things that can be done to improve the situation - some of which I've implemented in production.

The most obvious threat model is theft of hard drives. The solution to this is to encrypt all data on the drives. The first level of this is to simply encrypt the partitions used for data, support for this is available in Fedora Core 6 and has been in Debian for some time. The more difficult feature is encrypting the root filesystem, encrypting root means that important system files such as /etc/shadow are encrypted. Also if the root filesystem is encrypted then an attacker can't trivially subvert the system by replacing binaries. An unencrypted root filesystem on a machine that is left turned off overnight (or for which an unexpected reboot won't be treated seriously) allows an attacker to remove the drive, replace important system files and then re-install it. If the machine is booted from removable media (EG USB key) which contains the kernel and the key for decrypting the root filesystem then such attacks are not possible. Debian/unstable supports an encrypted root filesystem, but last time I tried the installer there did not appear to be any good support for booting from USB (but given the flexibility of the installer I think it's within the range of the available configuration options). I have run Fedora systems with an encrypted root filesystem for a few years, but I had to do some gross hacks that were not of a quality that would be accepted. With the recent addition of support for encrypted filesystems in Fedora it seems likely that some such patches could be accepted - I would be happy to share my work with anyone who wants to do the extra work to make it acceptable for Fedora.

Once the data is encrypted on disk the next thing you want to do is to make the machines as secure as possible. This means keeping up to date with security patches even on internal networks. I think that a viable attack method is to install a small VIA based system in the switch cabinet (no-one looks for new equipment appearing without explanation) that sniffs an internal (and therefore trusted) network and proxies it to a public network. This isn't just an issue of securing applications, it also means avoiding insecure protocols such as NFS and AoE for data that is important for your secrecy or system integrity.

An option for using NFS is to encrypt it with IPSEC or similar technology. AoE can be encrypted with cryptsetup in the same way as you encrypt hard drive partitions, it doesn't use IP so IPSEC won't work but it is a regular block device so anything that encrypts block devices will work. I have been wondering about how well replay attacks might work on an encrypted AoE or iSCSI device.

Security technologies such as SE Linux are good to have as well. An attacker who knows that a server has encrypted hard drives might try cracking it instead. A thief who has stolen a laptop and knows that it has an encrypted drive can keep it running until future vulnerabilities are discovered in any daemons that accept data from the network (of course if you have enough technology you could sniff the necessary data from the system bus and from RAM while it's running - but most attackers won't have such resources). I have considered running a program on my laptop that would shut it down if for a period of 48 hours I didn't login or un-blank the screen, that would mean that if it was stolen then the thief would have 48 hours to try and crack it.

Prevent access to some hardware that you don't need. If you allow the system to load all USB drivers then maybe a bug in such a driver could be exploited to crack it. Remember that in a default configuration USB drivers will be loaded when a device is inserted (which is under control of an attacker) and the device will use data from the attacker's hardware (data of low integrity being accessed by code that has ultimate privilege). Turning off all USB access is an option that I have implemented in the past. I have not figured out a convenient way of disabling all USB modules other than the few that I need, I have considered writing a shell script to delete the unwanted modules that I can run after upgrading my kernel package.

Once these things have been done the next issue is securing hardware. Devices to monitor keyboard presses have been used to steal passwords. The only solution I can imagine for this is to use laptops on people's desks and then store them in a safe overnight, unfortunately laptops are still quite a bit more expensive than desktop machines and consequently they are mostly used as status symbols in offices. Please let me know if you have a better idea for solving the key-logging problem.

For servers there is also a problem with keyboard sniffing. Maybe storing the server's keyboard in a safe would be a good idea.

Security monitoring systems are a good idea, unfortunately they can be extremely expensive. There has already been at least one recorded case of a webcam being used to catch a burglar. I believe that this has a lot of potential. Get a webcam server setup with some USB hubs and cameras and you can monitor a small office from all angles. When the office is empty you can have it GPG encrypt pictures and send them off-site for review in the case of burglary. You could also brick the server into a wall (or make it extremely physically secure in other ways) so that the full photo record would be available in the case of damaged phone lines, and to give more pictures than the upload bandwidth of an ADSL link would allow (512Kb/s doesn't allow uploading many pictures - no-where near the capacity of a few high-resolution web-cams).

This is just a few random thoughts, some things I've done, some things I plan to do, and some that just sound like fun. I expect comments telling me that I have missed some things. I may end up writing a series of articles on this topic.

PS I've uploaded day 32 of the beard (which was taken yesterday). Last night at a LUV meeting I was asked to stand in front of the audience to show them my beard. I had imagined that they might have seen it enough through my blog, but apparently not.

7 November 2006

Evan Prodromou: 16 Brumaire CCXV

I'm sitting in the keynote for the Web 2.0 Conference and realizing that it's been far too long since I made an entry on my blog. It's been a huge week for me since I last posted. Whew. OK, so, I think I'm caught up. There's probably a lot of stuff that I missed, but I don't feel like I have to fill in any more. The next 3 days at Web 2.0 are going to be busy, so I really want to be able to blog without guilt. tags:

Adam Rosi-Kessel: Minor Voting Irregularities

We are fortunate in Massachusetts to have fairly simple paper ballot voting machines (rather than electronic touch-screen voting machines, see, e.g. Ed Felten’s comprehensive critiques of electronic voting). When I voted this morning, however, the machines were not feeding the ballots. Instead, the poll workers were piling the ballots up on top of the machines, apparently to be fed into the machines when they figured out how to get them to work. When I left (about 90 minutes after the polls opened), they had gotten to the point of triple-checking whether the machine was plugged in. I felt a bit uneasy leaving my secret ballot in a big open pile. It was somewhat reassuring that a police officer seemed to be in charge of watching the ballots, but I still will always have a slight reservation as to whether or not my vote was actually counted. Don’t they get to work early to test the machines? Perhaps do a few dry runs, kick the tires, etc.? Other industries seem to have figured out most of these problems a long time ago — for example, I can’t remember a single instance in my entire life of encountering a paper jam (cash or receipt) with an ATM. (I’m sure it does happen, just rarely enough that it’s never effected me). If a system is mission critical, it should be possible to get the failure rate down to something more acceptable.

Adrian von Bidder: Good News to Balance the Bad?

After the ambiguous MS-Novell deal (Received a lot of bad press, but I'm still not so sure in the long term. It might be bad for Novell and SuSE, but it might be good for Free Software as a whole), here's a piece of news that is hopefully less beset with snares: Flash becomes more open: Adobe donates some code to the Mozilla foundation. Now the only part that bothers me is that this likely means the Mozilla license will be used, which is AFAIK GPL-incompatible, which means that Konqueror will not get native flash in the foreseeable future now. Especially because I think that this move will cause work on the free flash player front (Gnash, and I believe there were others) to slow down. Update: MJ Ray corrects me, thanks - Mozilla code is multi-licensed MPL, GPL, LGPL. So integrating in Konqueror is, in theory, no license problem.

5 November 2006

Mike Hommey: Blackout in Europe

Joey, I can tell you such people exist (people whose power was cut in order to limit the impact), because I am one of them. No power for something like 45 minutes in all the neighbourhood at least, for what I know, and press reported 5 millions people without electricity for France alone. ADSL came back some 30 minutes after electricity, so everything was back to normal by 23:30 GMT+1. We also had a ‘micro-blackout’ earlier the same day, a bit before mid day, if I recall correctly, which made the external hard drive connected to my server be stuck during an I/O. Fortunately, powering it off and on solved the problem, and the filesystem is okay. The server itself being an old laptop, it didn’t lose its uptime, but without network, it was quite useless…

4 November 2006

David Moreno Garza: Yeah Yeah Yeahs and Corona Music Fest

I had an exhausting and stressing weekend. We had a long long holiday this week in Mexico. Some people had the week until Tuesday and had from Wednesday to Sunday off, because of the Day of the Dead celebration (being Nov 1st and 2nd, and taking Friday 3rd also). I didn’t have any classes, but the Superior Algebra teacher made us attend an exam on Friday and Saturday (9 am and 8 am, respectively). Some of my friends were high and drunk from Tuesday afternoon and will remain that way until tomorrow, while I had to stay at home and work stressing for my poor understanding on the class, trying to study with tons of things on my head, etc. This so much sucks. Anyway, last week, Raquel, Tato, Javier and a friend of Tato managed to go to Yeah Yeah Yeahs‘ concert, which was fucking amazing. I love Karen O, her sex appeal and the way she does to put people in the mood is great and lovely. Unfortunately, Rach hasn’t put the pics (we got her digital camera inside the building but was discovered by the staff and forced to put it on a stuff hold table, fuckers) yet, I hope she does soon :) The best moment of the concert: Date with the Night. Next weekend, the Corona Music Fest will take place in the Azteca stadium, which has me anxious. I can’t wait to watch The Mars Volta on stage. Other nice bands I’m expecting to watch are NOFX, Clap Your Hands Say Yeah, Resorte, La Gusana Ciega and the Nortec Collective. Here’s the flyer:

3 November 2006

Joachim Breitner: Building around Scamblocks

I'm currently travelling through Ghana, as the German readers of my blog know. For some reason, I can't access my server from this internet cafe, and my assumption is that my hoster or his carrier blocks some Ghanaian IP ranges, to prevent scam mails, which mostly originate in Nigeria and other West African countries.But I still want to reach my server, to check my mail and write blog entries. Luckily, I could work around that barrier, using various holes in the setup here. The software on this computer does not allow me to access the start menu, but I still could download putty and start it from Firefoxes download list. First hole. I could then connect to my account at my university in Germany, so no firewall here. Second hole. Unfortunately, putty can not act as a SOCKS server as OpenSSH does, but luckily, there is usocksd, a small SOCKS server, installed on the university server. I then forwarded the local port 8080 to there using putty, and I could change the proxy settings of firefox to use that instead of the internet cafe's proxy. Third hole. Additional benefit: Encrypted browsing...

Adrian von Bidder: OpenBC

With mixed feelings, I joined OpenBC recently. It is a good idea, but unfortunately there is absolutely nothing “open” in it. I'm starting to think that it would be nice to have such a platform, with the word open actually having some meaning.

Adrian von Bidder: OpenBC

With mixed feelings, I joined OpenBC recently. It is a good idea, but unfortunately there is absolutely nothing “open” in it. I'm starting to think that it would be nice to have such a platform, with the word open actually having some meaning.

Maximilian Attems: Early Userspace Fun

History
For the sarge release official kernel-images from the newly formed Debian kernel team came together with initrd-tools. initrd-tools Maintainer was jbailey. It saw some care from tbm, vorlon and me before the actual release. Remembering the flow of bugs and installation-reports it accounted for a huge number of install failures plus lacked many features the Red Hat mkinitrd had. Ubuntu got hit more directly as hoary released with a newer kernel than 2.6.8 and due to the initrd-tools devfs requirement.
initramfs-tools originated out of the need of a direct replacement. Inspired by an initramfs OLS talk jbailey had the goals of boot-time hardware detection using the nice and neat features the Linux 2.5 branch incorporated: The sysfs support of the Linux drivers allows an neat userspace daemon aka udev to coldplug them. udev is the replacement of a maze of slow shell scripts called hotplug package. The second big feature is the new initramfs format (the curious may want to read Documentation/filesystems/ramfs-rootfs-initramfs.txt of any current linux-2.6 source). For a boot loader initramfs or initrd is the same fish. The smaller and more efficient in kernel code makes the difference. The initramfs gets loaded much earlier, due to being only an cpio archive and not an fs allowing it to completely rule the rootfs search and mount. One initial assigned spec had the name "easy NFS root". The LTSP guys joined in and showed interest in incorporating their work.
Technology
initramfs-tools got default in Debian together when the first common linux-2.6 (2.6.15) package reached etch, powered all the Ubuntu releases from Breezy on and is used by the grml live-cd. Since archive inclusion almost a year ago it got much better support of all the various linux boot parameters (see man initramfs-tools or the "official" Documentation/kernel-parameters.txt), keeps an backup initrd around and has better block-based bootloader support (lilo, ..). klibc has been ported to _all_ the Debian release archs where it is in use and compiles fine on m68k and sh.
The initramfs-tools early userspace is very flexible based on it's hooks for initramfs build and boot. Thanks to alphix for the help on shaping the building blocks. There are initramfs hooks in cryptsetup, evms, dmraid, firmware-qlogic, lvm2 multipath, mdadm, usplash, .. Reviewers, uploaders and sponsors included fs, jbailey and Sesse. Most of the time it is sufficient and easy to test changes in qemu images (See slides workshop early userspace). The best wish of an early userspace is not to be remarked - aka happy booting. Nevertheless thanks a lot for the public support: Achieving Xen Disk encryption support in Etch, Popping my initramfs cherry, ..
Future
The latest initramfs-tools release seems almost ready for the upcoming etch release. The bug reports coming over from installation-reports are happily rare. Although the uuid based fstab generation solution is not yet integrated in the debian-installer. There are one or two known nitpicks left-over in the bts plus one bugger: udevsettle may exit to early, when not all the discs are ready for use. For grub there is a fail-over net, but which does not account for a to early md or lvm2 boot hook. Future initramfs-tools development will focus on an optional small klibc based Modules=dep hand walking /sys initramfs generation allowing better embedded support. grub2 will present run-time assembly challenges for the initramfs.

Next.

Previous.