Understanding the modern view of security

David Magda wrote a good and interestingquestion in a comment on my entry on the browser security dilemma :

I'm not sure why they can't have an about:config item called somethinglike "DoNotBlameFirefox" (akin to Sendmail's idea).

There is a direct answer to this question (and I sort of wrote itin my comment), but the larger answer is that there has been a broadchange in the consensus view of (computer) security. Browsers area microcosm of this shift


'Command line text editor' is not the same as 'terminal-based text editor'

A while back, I saw a mention about what was called a new commandline text editor. My ears perked up, and then I was disappointed :

Today's irritation: people who say 'command line text editor' whenthey mean 'terminal/cursor-based text editor'.

I understand why the confusion comes up, I really do; an in-terminalfull screen editor like vi generally has to be started from thecommand line instead of eg from a GUI menu or icon. But for people


The browser security dilemma

So Pete Zaitcev ran into the failure mode of modern browsers beingstrict about security , which is that thebrowser locks you out of something that you need to access . The only thing I'mmuch surprised about is that it happened to Pete Zaitcev before ithappened to me. On the one hand, this is really frustrating when ithappens to you; on the other hand, the browsers are caught on thehorns of a real security dilemma here.

To simplify, there are two sorts of browser users; let


What does 'success' mean for a research operating system?

Sometimes people talk about how successful (nor not successful) anoperating system has been, when that operating system was createdas a research project instead of a product. One of the issues hereis that there are several different things that people can mean bya research OS being a success. In particular, I think that there areat least four sorts of it:

  • The OS actually works and thus serves as a proof of concept for theunderlying ideas that motivated this particular research OSvariation. What 'works' means

A problem with using old OmniOS versions: disconnection from the community

One of the less obvious problems with us probably never doinganother OmniOS upgrade is that I'm clearlygoing to become more and more disconnected from the OmniOS community.This is only natural, since most or almost all of the community isusing recent versions; as time goes on, those versions and theversion we're running are only going to drift more and more apart.

(It's true that OmniOS r151014 is an OmniOS LTS release, supportedthrough early 201


Your overall anti-spam system should have manual emergency blocks

We mostly rely on a commercial anti-spam system for our incomingspam filtering ( as described here ), andmany other people rely on a variety of open source options for theirspam filtering. This generally works very well, with us (and you)getting to offload the work of maintaining a high quality anti-spamsystem to other people (and it's certainly a lot of work). But notalways (and not just because it malfunctions ). The realities of life are thatsooner or later


Why SELinux is inherently complex

The root of SELinux's problems is that SELinux is a complex securitymechanism that is hard to get right. Unfortunately this complexityis not (just) simply an implementation artifact of the currentSELinux code; instead, it's inherent in what SELinux is trying todo.

What SELinux is trying to do is understand 'valid' program behaviorand confine programs to it at a fine grained level in an environmentwhere all of the following are true:

  • Programs are large, complex, and can legitimately do many things

SELinux is beyond saving at this point

SELinux has problems. It has a complexity problem (in that it isquite complex), it has technical problems with important issueslike usability and visibility , it has pragmatic problems with gettingin the way , and most of all it has asocial problem . At this point, I no longerbelieve that SELinux can be saved and become an important part ofthe Linux security landscape (at least if Linux remains commonlyused).

The fundamental reason why SELinux is beyond saving at this pointis that after something like a


How fast fileserver failover could matter to us

Our current generation fileservers don't have any kind of failover system, just like our originalgeneration . A few yearsago I wrote that we don't really miss failover , although I allowed that Imight be overlooking situations where we'd have used failover ifwe had it. So, yeah, about that: on reflection, I think there is arelatively important situation where we could really use fast,reliable cooperative failover (when both the old and new hosts ofa virtual fileserver are working properly)


Our problem with OmniOS upgrades: we'll probably never do any more

Our current fileserver infrastructure iscurrently running OmniOS r151014, and I have recently crystallizedthe realization that we will probably not upgrade it to a newerversion of OmniOS over the remaining lifetime of this generationof server hardware (which I optimistically project to be anothertwo to three years). This is kind of a problem for a number ofreasons (and yes, beyond the obvious), but my pessimistic view rightnow is that it's an essentially intractable one for us.

The core