Mon, 12 May 2008

I Feel Happy!

Michelle & Wes

The above photograph was taken by our good friend Matt Nuzzaco (AKA: Nuzz). I'll be putting the photographs up on my flickr site once I have them from Nuzz, but for now that's a good teaser.

I'm now officially married. This means I can start to get back to work on the things I've basically put on hold for a while now. Mostly the two weeks or so leading up to the wedding I didn't do much of anything useful outside of wedding things. That is over now and here are some of the things I intend to do as time permits (in no particular order):

About the first few entires... Jordan was recently given the C# code to a Win32 port of keynav and permission to release it under whatever license he saw fit. He passed the code on to me and I'm intending to release it once I've done some of the things on the list. If you're a fan of keynav and you use Windows I'm sure you'll like this application. If you have no idea what keynav is go read up on it.

Bonus points if you know where the title of this post is from. :)

posted at: 21:16 | tags: | path: /entries/generic | permanent link to this entry

Fri, 02 May 2008

Good Video Describing How The FreeBSD Project Works

Here's an interesting video explaining some of the aspects of the FreeBSD community, given by Robert Watson at Google in June 2007. It's a great thing to listen to if you have very little knowledge about FreeBSD and how it's community works. I just noticed that if you look closely you will see Jordan Sissel in the audience. He's wearing the maroon colored backwards hat (he's off on the right).

posted at: 20:52 | tags: | path: /entries/freebsd | permanent link to this entry

Mon, 28 Apr 2008

Extending the OPTIONS Framework - Part 3.

I'll save the boring details but I've cleaned up the first patch in this series (the one that extends the OPTIONS to a 4th field and requires OPTIONS_DESC). This new method means that there is always the '?' or F1 keys available, since if OPTIONS_DESC is not set it uses a default message (like in the second patch). If you want to see the current versions they will be available here at least until something happens with the PR (committed or stalled long enough for the patches to become stale).

I submitted both in a PR tonight. Now it's up to the powers that be to determine which solution they like best, and for me to adjust the patches as necessary to suit their concerns (if there are any).

Oh, I also finally got around to submitting my show-all-pkg-messages patch that I've been sitting on for a few months now. I had some initial reports from some friends that it worked on more ports than I tested with.

posted at: 22:57 | tags: , | path: /entries/freebsd | permanent link to this entry

Mario Kart Wii

I picked up a copy of Mario Kart Wii yesterday. It's fun, and the Wii-wheel is actually decent. It's the first tilt-the-controller that I've played that doesn't suck big time. The little additions they have made to the game (no more snaking, tricks in the air for boosts, etc) are good. The online play is well done too.

If you're reading this and want my friend code just send me a mail and if I know who you are I'll send it to you. I'd love to play more against people I know.

posted at: 07:50 | tags: | path: /entries/generic | permanent link to this entry

Fri, 25 Apr 2008

Extending the OPTIONS Framework - Part 2.

This is part 2 (part 1) of my venture into extending the OPTIONS framework to be a little more user friendly. For background read part 1, otherwise this won't make much sense.

With this approach the maintainer must declare DESC_FOO for every option. Failure to do so results in a default message being put in place. The upside of this approach is that the help screen becomes the default on every port, regardless of if they have long descriptions or not. The downside of this approach is that I must call make(1) for every OPTION, which is not very efficient - I've tried to figure out a way around it but couldn't. I tend to think my first approach is cleaner on the maintainer, at the expense of more complication in bsd.port.mk. Also, with the first approach there is a higher chance of the longer descriptions being the default (ie: not having them results in a failure to parse them).

Here's the patch - I'll probably send-pr it tonight or tomorrow: 

Index: bsd.port.mk
===================================================================
RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v
retrieving revision 1.592
diff -u -u -r1.592 bsd.port.mk
--- bsd.port.mk 14 Apr 2008 16:46:41 -0000  1.592
+++ bsd.port.mk 25 Apr 2008 23:01:35 -0000
@@ -1234,6 +1234,7 @@
 .else
 UNIQUENAME?=   ${PKGNAMEPREFIX}${PORTNAME}
 .endif
+OPTIONSDESCFILE?=  ${PORT_DBDIR}/${UNIQUENAME}/options.descr
 OPTIONSFILE?=  ${PORT_DBDIR}/${UNIQUENAME}/options
 _OPTIONSFILE!= ${ECHO_CMD} "${OPTIONSFILE}"
 .if defined(OPTIONS)
@@ -5783,6 +5784,7 @@
        . ${_OPTIONSFILE}; \
    fi; \
    set -- ${OPTIONS} XXX; \
+   TMPOPTIONSDESCFILE=$$(mktemp -t portoptionsdescr); \
    while [ $$# -gt 3 ]; do \
        OPTIONSLIST="$${OPTIONSLIST} $$1"; \
        defaultval=$$3; \
@@ -5798,14 +5800,21 @@
            val=$$3; \
        fi; \
        DEFOPTIONS="$${DEFOPTIONS} $$1 \"$$2\" $${val}"; \
+       LONGDESC=$$(cd ${.CURDIR} && ${MAKE} ${__softMAKEFLAGS} -V DESC_$$1); \
+       if [ "x$${LONGDESC}" = "x" ]; then \
+           ${ECHO_CMD} "$$1: No long description specified.  Contact the maintainer to fix this." | fmt >> $${TMPOPTIONSDESCFILE}; \
+       else \
+           ${ECHO_CMD} $$1: $${LONGDESC} | fmt >> $${TMPOPTIONSDESCFILE}; \
+       fi; \
        shift 3; \
    done; \
    TMPOPTIONSFILE=$$(mktemp -t portoptions); \
    trap "${RM} -f $${TMPOPTIONSFILE}; exit 1" 1 2 3 5 10 13 15; \
-   ${SH} -c "${DIALOG} --checklist \"Options for ${PKGNAME:C/-([^-]+)$/ \1/}\" 21 70 15 $${DEFOPTIONS} 2> $${TMPOPTIONSFILE}"; \
+   ${SH} -c "${DIALOG} --hfile $${TMPOPTIONSDESCFILE} --hline \"Press ? for a detailed description\" --checklist \"Options for ${PKGNAME:C/-([^-]+)$/ \1/}\" 21 70 15 $${DEFOPTIONS} 2> $${TMPOPTIONSFILE}"; \
    status=$$?; \
    if [ $${status} -ne 0 ] ; then \
        ${RM} -f $${TMPOPTIONSFILE}; \
+       ${RM} -f $${TMPOPTIONSDESCFILE}; \
        ${ECHO_MSG} "===> Options unchanged"; \
        exit 0; \
    fi; \
@@ -5832,11 +5841,14 @@
    if [ `${ID} -u` != 0 -a "x${INSTALL_AS_USER}" = "x" ]; then \
        ${ECHO_MSG} "===>  Switching to root credentials to write ${_OPTIONSFILE}"; \
        ${SU_CMD} "${CAT} $${TMPOPTIONSFILE} > ${_OPTIONSFILE}"; \
+       ${SU_CMD} "${CAT} $${TMPOPTIONSDESCFILE} > ${OPTIONSDESCFILE}"; \
        ${ECHO_MSG} "===>  Returning to user credentials"; \
    else \
        ${CAT} $${TMPOPTIONSFILE} > ${_OPTIONSFILE}; \
+       ${CAT} $${TMPOPTIONSDESCFILE} > ${OPTIONSDESCFILE}; \
    fi; \
-   ${RM} -f $${TMPOPTIONSFILE}
+   ${RM} -f $${TMPOPTIONSFILE}; \
+   ${RM} -f $${TMPOPTIONSDESCFILE}
 .endif
 .endif

@@ -5916,11 +5928,12 @@
    optionsdir=${_OPTIONSFILE}; optionsdir=$${optionsdir%/*}; \
    if [ `${ID} -u` != 0 -a "x${INSTALL_AS_USER}" = "x" ]; then \
        ${ECHO_MSG} "===> Switching to root credentials to remove ${_OPTIONSFILE} and $${optionsdir}"; \
-       ${SU_CMD} "${RM} -f ${_OPTIONSFILE} ; \
+       ${SU_CMD} "${RM} -f ${_OPTIONSFILE} ${OPTIONSDESCFILE}; \
            ${RMDIR} $${optionsdir}"; \
        ${ECHO_MSG} "===> Returning to user credentials"; \
    else \
        ${RM} -f ${_OPTIONSFILE}; \
+       ${RM} -f ${OPTIONSDESCFILE}; \
        ${RMDIR} $${optionsdir}; \
    fi
 .else

posted at: 19:05 | tags: , | path: /entries/freebsd | permanent link to this entry

Tue, 22 Apr 2008

Summer of Code 2008 Rundown.

So the Summer of Code 2008 projects are out for FreeBSD. There are some I'm really excited about:

posted at: 06:49 | tags: | path: /entries/freebsd | permanent link to this entry

Wed, 16 Apr 2008

CarolinaCon Lookback

I promise that I'll get back to my regular FreeBSD stuff later. I'm going out of town this weekend so I won't be doing any of the stuff I've been putting off for a week or so now. :)

I spent some time a few weeks ago at CarolinaCon which is a small conference put on by the NC2600 folks in the RTP area. This was my second time at the conference (it's been going on for 4 years now), and also my second time presenting there.

I've never been a fan of 2600 - it's just been too politically slanted (though I generally agree with their slant I still don't want it in my face all the time), and focusing on areas I quickly grew out of in my early teens. With that said, this conference has very little to do with 2600 - it's really just run by people that keep the 2600 meetings alive in the RTP area. Two years ago I noticed more of the 2600 crowd at the conference - boozing it up, not really contributing in any meaningful way, generally causing mayhem, etc. This past year I saw a much more subdued and respectable crowd. There was still plenty of hijinks to be had, but I wasn't cringing at some of the behavior of the folks like I was 2 years ago. The exception to that this year was the Marine who was passed out in the corner snoring really loud. He at least handled himself well when people woke him up and tried to get him to move to his room.

The core group of people at CarolinaCon are all great people. The talks range from not uber technical things, yet still really interesting (Women in Technology and Hacking) to the more technical and security related (Format String Vulnerabilities 101). I, again, really enjoyed the talk given by Dr. Thomas Holt (Hi Professor, if you read this drop me a line - I'd love to know if you actually do). His talk was entitled "Blogging for Bad Guys: What Not To Say On-Line" and while it was certainly nothing new to me his presentation was entertaining and refreshing. It's people like him that bring an interesting and new spin to these kinds of conferences. They all don't have to be about the latest and greatest research or 0-days. His research is interesting from a sociological and psychological viewpoint, and I always look forward to what he has to say.

I'll certainly be going back next year, and probably submitting at least one talk. I've been to all kinds of conferences, and contributed in multiple ways to the running of conferences from the very small to the very large. CarolinaCon has a feeling all of it's own. It's not going to blow my mind technically, but it's always good to go to the smaller conferences where it's not about business, schmoozing or anything else. It's about hanging out with like-minded individuals and talking about interesting things in technology, politics, law and society. Something about that conference just feels right. I like the people and the idea of a technology conference, not a security conference, sits well with me.

posted at: 22:17 | tags: , | path: /entries/geek | permanent link to this entry

Wed, 02 Apr 2008

Extending the OPTIONS Framework - Part 1.

This will be at least a two part post, possibly more depending upon where this takes me. I spent some time at night late last week working on extending the OPTIONS framework in ports. It started with this thread on ports@ and continued into April (same thread). The idea is to extend the OPTIONS framework used in ports from the 3 field way it is currently to an optional 4th field which would contain a much more detailed description of what the option means - possibly including listing dependencies it will pull in. Ports that choose to use this 4th field will automatically allow the user to hit '?' or F1 on the dialog(1) screen used to select the OPTIONS, which will bring up the detailed descriptions in a separate window.

My initial thoughts last week were to use a variable called DESC_foo to store the long description (where "foo" is the name of the OPTION). The upside of this is that I just have to look for DESC_foo and display it somehow. The downside is that it's not intuitive, given how the OPTIONS framework works currently. It just seems like a nicer solution to inline the long descriptions, rather than declare them separately. I thought about it some more and decided that Pav's approach - putting the descriptions inline - is nicer, though probably a bit more complicated to implement. So I whipped up an initial draft late Wednesday or Thursday night and decided to let it rest while I took a mini-vacation to North Carolina to speak at a conference (more on that later).

While at the conference I thought some more about it and came up with a fairly clean solution and implemented it when I returned. I like it and it seems to work for the one or two ports I've tested it on. I'm still waiting from a more formal review from people, but I think it will hold up. The one thing I dislike about the patch is that I had to implement another knob (OPTIONS_DESC) which maintainers must turn on when they implement the long description field. The reason for this is that without it I can't determine the difference between a port which has 3 OPTIONS with a long description (12 fields) or a port which has 4 OPTIONS without a long description (12 fields). Ideally, over time people will adopt this extension and eventually the knob can be removed and can be the default case. Of course, this is highly optimistic thinking... :)

I just spoke to some people tonight and they are concerned that it may break existing applications which parse OPTIONS. This lends credence to my initial thoughts on how to do it. I'll probably whip up that approach one of these nights and also try and get a formal review of it from the right people.

For now, here's the patch I described: 

Index: bsd.port.mk
===================================================================
RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v
retrieving revision 1.591
diff -u -u -r1.591 bsd.port.mk
--- bsd.port.mk 11 Mar 2008 23:45:04 -0000  1.591
+++ bsd.port.mk 1 Apr 2008 17:04:57 -0000
@@ -1229,6 +1229,7 @@
 .else
 UNIQUENAME?=   ${PKGNAMEPREFIX}${PORTNAME}
 .endif
+OPTIONSDESCFILE?=  ${PORT_DBDIR}/${UNIQUENAME}/options.descr
 OPTIONSFILE?=  ${PORT_DBDIR}/${UNIQUENAME}/options
 _OPTIONSFILE!= ${ECHO_CMD} "${OPTIONSFILE}"
 .if defined(OPTIONS)
@@ -5781,6 +5782,7 @@
        . ${_OPTIONSFILE}; \
    fi; \
    set -- ${OPTIONS} XXX; \
+   TMPOPTIONSDESCFILE=$$(mktemp -t portoptionsdescr); \
    while [ $$# -gt 3 ]; do \
        OPTIONSLIST="$${OPTIONSLIST} $$1"; \
        defaultval=$$3; \
@@ -5796,14 +5798,24 @@
            val=$$3; \
        fi; \
        DEFOPTIONS="$${DEFOPTIONS} $$1 \"$$2\" $${val}"; \
-       shift 3; \
+       if [ -n "${OPTIONS_DESC}" ]; then \
+           ${ECHO_CMD} "$$1: $$4" | fmt >> $${TMPOPTIONSDESCFILE}; \
+           shift 4; \
+       else \
+           shift 3; \
+       fi; \
    done; \
    TMPOPTIONSFILE=$$(mktemp -t portoptions); \
-   trap "${RM} -f $${TMPOPTIONSFILE}; exit 1" 1 2 3 5 10 13 15; \
-   ${SH} -c "${DIALOG} --checklist \"Options for ${PKGNAME:C/-([^-]+)$/ \1/}\" 21 70 15 $${DEFOPTIONS} 2> $${TMPOPTIONSFILE}"; \
+   trap "${RM} -f $${TMPOPTIONSFILE}; ${RM} -f $${TMPOPTIONSDESCFILE}; exit 1" 1 2 3 5 10 13 15; \
+   if [ -n "${OPTIONS_DESC}" ]; then \
+       ${SH} -c "${DIALOG} --hfile $${TMPOPTIONSDESCFILE} --hline \"Press ? for a detailed description\" --checklist \"Options for ${PKGNAME:C/-([^-]+)$/ \1/}\" 21 70 15 $${DEFOPTIONS} 2> $${TMPOPTIONSFILE}"; \
+   else \
+       ${SH} -c "${DIALOG} --checklist \"Options for ${PKGNAME:C/-([^-]+)$/ \1/}\" 21 70 15 $${DEFOPTIONS} 2> $${TMPOPTIONSFILE}"; \
+   fi; \
    status=$$?; \
    if [ $${status} -ne 0 ] ; then \
        ${RM} -f $${TMPOPTIONSFILE}; \
+       ${RM} -f $${TMPOPTIONSDESCFILE}; \
        ${ECHO_MSG} "===> Options unchanged"; \
        exit 0; \
    fi; \
@@ -5830,11 +5842,18 @@
    if [ `${ID} -u` != 0 -a "x${INSTALL_AS_USER}" = "x" ]; then \
        ${ECHO_MSG} "===>  Switching to root credentials to write ${_OPTIONSFILE}"; \
        ${SU_CMD} "${CAT} $${TMPOPTIONSFILE} > ${_OPTIONSFILE}"; \
+       if [ -n "${OPTIONS_DESC}" ]; then \
+           ${SU_CMD} "${CAT} $${TMPOPTIONSDESCFILE} > ${OPTIONSDESCFILE}"; \
+       fi; \
        ${ECHO_MSG} "===>  Returning to user credentials"; \
    else \
        ${CAT} $${TMPOPTIONSFILE} > ${_OPTIONSFILE}; \
+       if [ -n "${OPTIONS_DESC}" ]; then \
+           ${CAT} $${TMPOPTIONSDESCFILE} > ${OPTIONSDESCFILE}; \
+       fi; \
    fi; \
-   ${RM} -f $${TMPOPTIONSFILE}
+   ${RM} -f $${TMPOPTIONSFILE}; \
+   ${RM} -f $${TMPOPTIONSDESCFILE}
 .endif
 .endif

@@ -5868,7 +5887,11 @@
        if [ "$${val}" = "missing" ]; then \
            OPTIONS_INVALID=yes; \
        fi; \
-       shift 3; \
+       if [ -n "${OPTIONS_DESC}" ]; then \
+           shift 4; \
+       else \
+           shift 3; \
+       fi; \
    done; \
    if [ "$${OPTIONS_INVALID}" = "yes" ]; then \
        cd ${.CURDIR} && ${MAKE} config; \
@@ -5900,8 +5923,13 @@
        else \
            val="$$3 (default)"; \
        fi; \
-       ${ECHO_MSG} "     $$1=$${val} \"$$2\""; \
-       shift 3; \
+       if [ -n "${OPTIONS_DESC}" ]; then \
+           ${ECHO_CMD} "     $$1=$${val} \"$$2\" ($$4)" | fmt; \
+           shift 4; \
+       else \
+           ${ECHO_MSG} "     $$1=$${val} \"$$2\""; \
+           shift 3; \
+       fi; \
    done
    @${ECHO_MSG} "===> Use 'make config' to modify these settings"
 .endif
@@ -5909,16 +5937,17 @@

 .if !target(rmconfig)
 rmconfig:
-.if defined(OPTIONS) && exists(${_OPTIONSFILE})
+.if defined(OPTIONS) && (exists(${_OPTIONSFILE}) || exists(${OPTIONSDESCFILE}))
    -@${ECHO_MSG} "===> Removing user-configured options for ${PKGNAME}"; \
    optionsdir=${_OPTIONSFILE}; optionsdir=$${optionsdir%/*}; \
    if [ `${ID} -u` != 0 -a "x${INSTALL_AS_USER}" = "x" ]; then \
        ${ECHO_MSG} "===> Switching to root credentials to remove ${_OPTIONSFILE} and $${optionsdir}"; \
-       ${SU_CMD} "${RM} -f ${_OPTIONSFILE} ; \
+       ${SU_CMD} "${RM} -f ${_OPTIONSFILE} ${OPTIONSDESCFILE}; \
            ${RMDIR} $${optionsdir}"; \
        ${ECHO_MSG} "===> Returning to user credentials"; \
    else \
        ${RM} -f ${_OPTIONSFILE}; \
+       ${RM} -f ${OPTIONSDESCFILE}; \
        ${RMDIR} $${optionsdir}; \
    fi
 .else

posted at: 19:59 | tags: , | path: /entries/freebsd | permanent link to this entry

Mon, 24 Mar 2008

Fastest Sites is Committed.

Coming to a portsnap (or c[v]sup) mirror near you is something I just committed tonight. It's actually really small but quite useful and written by Jordan Sissel called fastest_sites.py. Basically, for every MASTER_SITE_foo in bsd.sites.mk it will run through the list and sort it based upon RTT for a TCP handshake (which is the best guess for least effort). The sorted list is output'ed in such a fashion that it can be included into your make.conf (.include "/path/to/output" is best).

It's quite useful for people who want to control the MASTER_SITE_foo closely. It's available at ports-mgmt/fastest_sites.

posted at: 21:42 | tags: , , | path: /entries/freebsd | permanent link to this entry

Fri, 21 Mar 2008

Security Mindset or Analytical Mindset?

This morning while drinking my morning water (I avoid soda and coffee as much as possible) I read Inside the Twisted Mind of the Security Professional. Being a rational person with a security background - at least I like to think of myself as rational - I tend to agree with most of what Bruce has to say. This particular essay is interesting to me because I've been saying for a few years now that security is not something which can be taught because it is a mindset. This is a mindset that has been ingrained in my very nature for as long as I can remember. I'm not sure how or why, but I look at things and instantly think of ways to make them fail. I'm forever cursed with thinking that way. I'm not sure "cursed" is the right word there, because I happen to like my view on the world. It's certainly pessimistic but it's also realistic and can help make the world a better place by exposing these problems.

An interesting side note here is the commercial which says "Never shake a baby." The first thing that popped into my head when I heard this was "Always shake a baby." Obviously I know the horrible things that can happen when you shake a baby (and I would never do that) but my mindset is such that I have to make those observations. If you tell me to go left I'm going to go right and see what happens.

Colin Percival then pointed out on IRC that his Security is Mathematics essay was getting a lot of traffic on reddit. After reading through it and discussing it with him I think he's right. What it boils down to is a good mathematician thinks of every possible edge case naturally, just like a good security professional.

I initially thought I agreed with both because while a mathematician must find every possible edge case in a proof, a security professional must find the edge failure case. But what is the difference? An edge case can cause failure in both systems, or it can be accounted for and handled properly. Either way both professionals naturally look for these kinds of things, but their motives are what make them different. A mathematician looks for edge cases in order to make his proof correct, while a security professional looks for edge cases in order to test security. The important thing is that it's both the same thought process. So what do you call the mindset that makes them both successful in their field? I'm going with "analytical mindset" - because that is what it is. They both must analyze a system and find the edge cases which cause failure.

So what makes a good security professional? I can list off a whole slew of things but the one that is relevant to this discussion is an analytical mindset combined with domain expertise, just like a good mathematician has an analytical mindset combined with domain expertise. This is true for lots of different things, but is it the general case?

Why is it, then, that I know people who have a very thorough analytical mindset and have little domain expertise but are still good security professionals? Why is it also true that I know people who have no analytical though capabilities but have a ton of domain expertise (they have certifications coming out their ears to prove this expertise too) and are just poor security professionals? Given that both ends of this spectrum exist I'd argue that what makes a good security professional is an analytical mindset more than domain expertise. Anyone can sit down and learn how a given technology/widget/ant farm mail in system/physical security system works. But if you don't analyze it from every possible angle looking for edge cases which can cause failure than you're just using domain expertise and not practicing what is really going to set you apart from your peers.

The question still remains: can you teach this mindset, like you can teach domain expertise? I'm leaning towards "yes" which is contrary to discussions I've had with people in the past. When you look at it as an analytical mindset - as opposed to a security mindset - then it makes sense that this can be taught. Some people are taught it throughout their upbringing (like me) while others get it in a more formal education. The end result is roughly the same.

An important note is that a security professional can't help but see it in every day life. A perfect example is the car dealership mentioned in Bruce's article. I've run into similar things countless times in my life. Another example is when I was at work early on a weekend to give a presentation to some important officials. After the presentation I was driving out with my co-worker in separate cars. We drove right past a giant fertilizer truck next to the building. It occurred to me that if there ever was a time to inflict damage that now would be the time to do it, and a fertilizer truck would be a good way to do it. Obviously I would not condone such a thing but I can't help to think of them - it's in my nature. A few days later at work I mentioned it to my co-workers who were there and only one of them (the guy who was driving out with me) happened to think the same thing as they drove past it later.

Not being a mathematician I can't comment on if these situations happen or not in that profession. I certainly think it's an interesting side-effect of being a security professional, but that mindset is certainly not unique to security people.

posted at: 07:09 | tags: , | path: /entries/geek | permanent link to this entry