It appears that the shell (and this broken behavior seems to be inherited by child shells, by the way), somehow loses the ability to map numeric Unix ids to login names.

So I tried another command:

% dscl . -read /Users/garrettOperation failed with error: eServerError
The same works properly in my other window (I'm not posting the entire output, since its really long).

I am wondering what could possibly be different. The behavior doesn't seem to depend on environment variables (I've tried stripping those out).

I'm thinking that there is something in the process table (in the MacOS X equivalent of the uarea?) that gives me access to directory services -- and that this is somehow clobbered. As indicated, whatever the thing is, it appears to be inherited across fork(2).

I thought maybe I could figure this out with DTrace or dtruss... but Apple have crippled DTrace on the platform and this is one of those binaries that I am unable to introspect. Arrgh!

sudo dtruss dscl . -read /Users/garrettPassword:dtrace: system integrity protection is on, some features will not be availabledtrace: failed to execute dscl: dtrace cannot control executables signed with restricted entitlements
Btw, I'm running the latest MacOS X:

Last Friday (October 16, 2016), a major DDoS attack brought down a number of sites across the Internet. My own employer was amongst those affected by the wide spread DNS outage.

It turns out that the sheer scale (millions of unique botnet members) was made possible by the IoT, and rather shoddy engineering practices.

Its time for device manufacturers and firmware engineers to "grow up", and learn how to properly engineer these things for the hostile Internet, so that they don't have to subsequently issue recalls when their customers' devices are weaponized by attackers without their owners knowledge.

This blog is meant to offer some advice to firmware engineers and manufacturers in the hope that it may help them prevent their devices from being used in these kinds of attacks in the future.

Passwords

Passwords are the root of most of the problems, and so much of the advice here is about improving the way these are handled.

No Default Passwords

The idea of using a simple default password and user name, like "admin/admin", is a practice from the 90's, and is intended to facilitate service personnel, and eliminate management considerations from dealing with many different passwords. Unfortunately, this is probably the single biggest problem -- bad usernames and passwords. Its far worse in an IoT world, where there are many thousands, or even millions, of devices that have the same user name and password.

The proper solution is to allocate a unique password to each and every device. Much like we already do manage unique MAC addresses, we need every device to have a unique password. (Critically, the password must not be derived from the MAC address though.)

My advice is to simply have a small amount of ROM that is factory burned with either a unique password, or a numeric key that can be used to create one. (If you have enough memory to store a dictionary in generic firmware -- say 32k words, you can get very nice human manageable default passwords by storing just four 16-bit numbers, each representing an index into the dictionary (so only 15 bits of unique data, but thats 60 bits of total entropy, which is plenty to ensure that every device has its own password -- and only requires storing a 64-bit random number in ROM.)

Then you have nice human parseable passwords like "bigger-stampede-plasma-pandering". These can be printed on the same sticker that MAC passwords are typically given. (You could also accept a hexadecimal representation of the underlying 64-bit value, or just use that instead of human readable passwords if you are unable to accommodate an English dictionary. Devices localized for use in other countries could use locale-appropriate dictionaries as well.)

Mandatory Authorization Delay

Second, IoT devices should inject a minimum delay after password authentication attempts (regardless of whether successful or otherwise). Just a few seconds is enough to substantially slow down dictionary attacks against poorly chosen end-user passwords. (2 seconds means that only 1800 unique attempts can be performed per hour under automation - 5 seconds reduces that to 720. It will be difficult to iterate a million passwords against a device that does this.)

Strong Password Enforcement

User chosen passwords should not be a single dictionary word; indeed, the default should be to use a randomly generated password using the same dictionary approach above (generate a 64-bit random number, break into chunks, and index into a stock dictionary). It may be necessary to provide an end-user override, but it should be somewhat difficult to get at by default, and when activate should display large warnings about the compromise to security that user-chosen passwords typically represent.

Networks

Dealing with the network, and securing the use of the network, is the other part of the problem that IoT vendors need to get right.

Local Network Authentication Only

IoT devices generally know the network they are on; if the device has a separate management port or LAN-only port (like a WiFi Router), it should only by default allow administrator access from that port.

Devices with only a single port, or that exist on a WiFi network, should prevent administrator access from "routed" networks, by default. That is, devices should not allow login attempts from a remote IP address that is not on a local subnet, by default. While this won't stop many attacks (especially those on public WiFis), it makes attacking them from a global botnet, or managing them as part of a global botnet, that much harder. (Again, there has to be a provision to disable this limitation, but it should present a warning.)

Encrypted Access Only

Use of unsecured channels (HTTP or telnet) is unacceptable in this day and age. TLS and/or SSH are the preferred ways to do this, and will let your customers deploy these devices somewhat more securely.

Secure All Other Ports

Devices should disable any network services that are not specifically part of the service they offer, or intrinsic to their management. System administrators have known to do this on systems for decades now, but it seems some firmwares still have stock services enabled that can be used as attack vectors.

Don't Advertise Yourself

This one is probably the hardest. mDNS and device discovery over "standard" networks is one of the ways that attackers find devices to target. Its far far better to have this disabled by default -- if discovery is needed during device configuration, then it can be enabled briefly, when the device is being configured. Having a "pairing" button to give end-users the ability to enable this briefly is useful -- but mDNS should be used only with caution.

Secure Your Channel Home

Devices often want to call-home for reporting, or web-centric command & control. (E.g. remote management of your thermostat.) This is one of the major attack vectors. (If you can avoid calling home altogether, this is even better!)

Users must be able to disable this function (it should be disabled by default in fact). Furthermore, the channels must be properly secured entirely through your network, with provision for dealing with a compromise (e.g. leaked private keys at the server side). Get a security expert to review your protocols, and your internal security practices.

Mesh Securely

Building local mesh networks of devices, e.g. to create a local cloud, means having strong pairing technology. The strongest forms of this require administrator action to approve -- just like pairing a bluetooth keyboard or other peripheral.

If you want to automate secure mesh provisioning, you have to have secure networking in place -- technologies like VPN or ZeroTier can help build networking layers that are secure by default.

Don't Invent Your Own Protocols

The roadside is littered with the corpses of protocols and products that attempted to invent their own protocols or use cryptography in non-standard ways. The best example of this is WEP, which took a relatively secure crypto layer (RC4 was not broken at the time), but deployed it naively and brokenly. RC4 got a very bad rap for this, but it was actually WEP that was broken. (Since then, RC4 itself has been shown to have some weaknesses, but this is relatively new compared to the brokenness that was WEP.)

General Wisdoms

Next we have some advice that most people should already be aware of, but yet bears repeating.

Don't Rely on Obscurity

Its an old adage that "security by obscurity is no security at all". Yet we often see naive engineers trying to harden systems by making them more obscure. This really doesn't help anything long term, and can actually hinder security efforts by giving a false sense of security or creating barriers to security analysis.

Audit

Get an independent security expert to audit your work. Special focus should be paid to the items pointed out above. This should include a review of the product, as well as your internal practices around engineering, including secure coding, use of mitigation technologies, and business practices for dealing with keying material, code signing, and other sensitive data.

Saturday, May 14, 2016

In order to debug nanomsg problems on Windows, I recently installed a copy of Windows 8.1 in a VMWare guest VM, along with Visual Studio 14 and CMake 3.5.2. (Yes, I've entered a special plane of Hell, reserved for just for people who try to maintain cross-platform open source software. I think this one might be the tenth plane, that Dante skipped because it was just too damned horrible.)

Every time I tried to build, I got bizarre errors from the CMake / build process ... like this:

Cannot evaluate the item metadata "%(FullPath)

Turns out that when I created my account, using the "easy" installation in VMWare, it created my Windows account using my full name. "Garrett D'Amore". Turns out that the software is buggy, and can't cope with the apostrophe in my full name, when it appears in a filesystem path.

Moving the project directory to C:\Projects\nanomsg solved the problem.

Really Microsoft? This is 2016. I expected programs to struggle and for me to find bugs in programs (often root exploits -- all hackers should try using punctuation in their login and personal names) with the apostrophe in my name back in the 1990s. Not in this decade.

Not only that, but the error message was so incredibly cryptic that it took a Google search to figure out that it was a problem with the path. (Other people encountered this problem with paths > 260 characters. I knew that wasn't my problem, but I hypothesized, and proved, that it was my name.) I have no idea how to file a bug on Visual Studio to Microsoft. I'm not a paying user of it, so maybe I shouldn't complain, and I really have no recourse. Still, they need to fix this.

Normally, I'd never intentionally create a path with an apostrophe in it, but in this case I was being lazy and just accepted some defaults. I staunchly refuse to change my name because some software is too stupid to cope with it -- this is a pet peeve for me.

We're in the new millennium, and have been for a decade and half. Large numbers of folks with heritage from countries like Italy, France, and Ireland have this character in their surname. (And more recently -- since like the 1960s! -- the African-American community has been using this character in their first names too!) If your software can't accommodate this common character in names, then it's broken, and you need to fix it. There are literally millions of us that are angered by this sort of brokenness every day; do us all a favor and make your software just a little less rage inducing by letting us use the names we were born with please.

The reasons for this are fairly simple. They have nothing to do whatsoever with technology. I love the GitHub platform, and have been a happy user of it for years now. I would dearly love it if I could proceed with GitHub. Fortunately GitLab seems to have feature parity with GitHub (and a growing user and project base), so I'm not trapped.

The reason for leaving GitHub is because of the hostility of it's leadership towards certain classes of people makes me feel that I cannot in good conscience continue to support them. In particular, their HR department is engaging in what is nothing less than race warfare against white people. (Especially men, but even white women are being discriminated against.) By the way, I'd take the same position if the hostility were instead towards any other racial or gender group other than my own.

I'm not alone in asking GitHub to fix this; yet they've remained silent on the matter, leading me to believe that the problematic policies have support within the highest levels of the company. (Github itself is in trouble, and I have doubts about its future, as both developers and employees are leaving in droves.)

Post Tom Preston-Werner, GitHub's leadership apparently sees the company as a platform for prosecuting the Social Justice War, and it even has a Social Impact Team just to that effect. In GitHub's own words:

"The Social Impact team will be focused
on these three areas: - Diversity & Inclusion - both internally and within the Open Source Community - Community
Engagement - we have a net positive impact in local and online communities via partnerships - Leveraging GitHub
for Positive Impact - supporting people from varied communities to use GitHub.com in innovative ways"

Those of you who have followed me know that I’m strongly in favor of inclusion, and making an environment friendly for all people, regardless of race or gender or religion (provided your religion respects my basic rights -- religious fundamentalist nut-jobs need not apply).

Lack of diversity cannot be fixed through exclusion. Attempts to do so are inherently misguided. Furthermore, as a company engages in any exclusive hiring practices they are inherently limiting their own access to talent. Racist or sexist (or ageist) approaches are self-destructive, and companies that engage in such behavior deserve to fail.

The way to fix an un-level playing field is to level the playing field -- not to swing it back in the other direction. You can't fix social injustice with more injustice; we should guarantee equal opportunity not equal results.

There are plenty of people of diverse ethnic backgrounds who have overcome significant social and economic barriers to achieve success. And many who have not. News flash -- you will find white men and women in both lists, as well as blacks, latinos, women, gays, and people of "other gender identification". Any hiring approach or policy (written or otherwise) that only looks at the color of a person's skin or gender is unfair, and probably illegal outside of a very limited few and specific instances (e.g. casting for movie roles).

Note that this does not mean that I do not support efforts to reach out to encourage people from other groups to engage more in technology (or any other field). As I said, I encourage efforts to include everyone -- the larger talent pool that we can engage with, the more successful we are likely to be. And we should do everything we can as a society and as an industry to make sure that the talent pool is as big as we can make it.

We should neither exclude any future Marie Curie or Daniel Hale Williams from achieving the highest levels of success, nor should we exclude a future Isaac Newton just because of his race or gender. The best way to avoid that, is to be inclusive of everyone, and make sure that everyone has the best opportunities to achieve success possible.

Sadly I will probably be labeled racist or sexist, or some other -ist, because I'm not supportive of the divisive agendas supported by people like Nicole Sanchez and Danilo Libre, and because I am a heterosexual white middle class male (hence automatically an entitled enemy in their eyes.) It seems that they would rather have me as an enemy rather than a friendly supporter -- at least that is what their actions demonstrate. It's certainly easier to apply an -ist label than to engage in rationale dialogue.

I am however deeply supportive of efforts to reach out to underrepresented groups in early stages. Show more girls, blacks, and latinos filling the role of technophiles in popular culture (movies and shows) that market towards children. Spend money (wisely!) to improve education in poorer school districts. Teach kids that they truly can be successful regardless of color or gender, and make sure that they have the tools (including access to technology) to achieve success based on merit, not because of their grouping. These efforts have to be made at the primary and secondary school levels, where inspiration can have the biggest effects. (By the way, these lessons apply equally well to white boys; teaching children to respect one another as individuals rather than as labels is a good thing, in all directions.)

By the time someone in is choosing a college or sitting in front of a recruiter, it's far too late (and far too expensive). The only tools that can be applied at later stages are only punitive in nature, and therefore the only reasonable thing to do at this late stage is to punish unjust behaviors (i.e. zero tolerance towards bigotry, harassment, and so forth.)

I'll have more detail as to the moves of the specific repos over the coming days.

PS: GitLab does support diversity as well, which is a good thing, but they do it without engaging in the social justice war, or exclusive policies.

Wednesday, January 6, 2016

(Quick reminder that this blog represents my own opinion, and not necessarily that of any open source project or employer.)

For nearly a year, I've been primary maintainer of nanomsg, a library of common lightweight messaging patterns written in C.

I was given this mantle when I asked for the nanomsg community to take some action to get forward progress on some changes I had to fix some core bugs, one of which was a protocol bug. (I am also the creator of mangos, a wire-compatible library supporting the same patterns written in Go, which is why I came to care about fixing nanomsg.)

Today, I am stepping down as maintainer.

There are several reasons for this, but the most relevant right now is my frustration with this community, and its response to what I believed to be a benign proposal, that to adopt a Code of Conduct, in an attempt to make the project more inviting to a broader audience.

I was unprepared for the backlash.

And frankly, I haven't got enough love of the project to want to continue to lead it, when its clearly unwilling to codify what are frankly some sound and reasonable communication practices.

As maintainer, I could have just enforced my will upon the project, but since the project existed before I came to it, that doesn't feel right. So instead, I'm just stepping down.

I'm not sure who will succeed me. I can nominate a party, but at this point there are several other parties with git commit privileges to the project; I think they should nominate one. Martin (the founder) still has administrative privileges as well.

To be clear, I think both sides of the Code of Conduct are wrong -- a bunch of whinny kids really.
On the one side, we have people who seem to feel that the existence of a document means something.

I think that's a stupid view; it may have meaning when you have larger democratic projects and you need therefore written rules to justify actions -- and in that case a Code of Conduct is really a way to justify punishing someone, rather than prevention or education. To those of you who think you need such a document in order to participate in a project -- I think you're acting like a bunch of spineless wimps.

This isn't to say you should have to put up with abuse or toxic conduct. But if you think a document creates a "safe space", you're smoking something funny. Instead, look at the actual conduct of the project, and the actions of leadership. A paper Code of Conduct isn't going to fix brokenness, and I have my doubts that it can prevent brokenness from occurring in the first place.

If the leadership needs a CoC to correct toxic behavior, then the leadership of the project is busted. Strong leadership leads by example, and takes the appropriate action to ensure that the communities that they lead are pleasant places to be. (That's not necessarily the same as being conflict-free; much technical goodness comes about as a consequence of heartfelt debate, and developers can be just as passionate about the things they care about as anyone else. Keeping the tone of such debate on topic and non-personal and professional is one of the signs of good leadership.)

On the other side, are those who rail against such a document. Are you so afraid of your own speech that you don't think you can agree to a document that basically says we are to treat each other respectfully? The word I use for such people is "chickenshit". If you can't or won't agree to be respectful towards others in the open source projects I lead, then I don't want your involvement.

There's no doubt that there exists real abuse and intolerance in open source communities, and those who would cast aspersions on someone because of race, religion, physical attribute, or gender (or preference), are themselves slime, who really only underscore for everyone else their own ignorance and stupidity. I have no tolerance for such bigotry, and I don't think anyone else should either.

Don't misunderstand me; I'm not advocating for CoCs. I think they are nearly worthless, and I resent the movement that demands that every project adopt one. But I equally resent the strenuous opposition to their existence. If a CoC does no good, it seems to me that it does no harm either. So even if it is just a placebo effect, if it can avoid conflict and make a project more widely acceptable, then its worth having one, precisely because the cost of doing so is so low.

Yes, this is "slacktivism".

I've been taught that actions speak louder than words though.

So today I'm stepping down.

I'm retaining my BDFL of mangos, of course, so I'll still be around the nanomsg community, but I will be giving it far less of my energy.

Friday, December 11, 2015

Those who know me know that I have little love for Microsoft Windows. The platform is a special snowflake, and coming from a Unix background (real UNIX, not Linux, btw), every time I'm faced with Windows I feel like I'm in some alternate dimension where everything is a little strange and painful.

I have to deal with Windows because of applications. My wife runs Quickbooks (which is one of the more chaotic and poorly designed bits of software I've run across), the kids have video games they like. I've had to run it myself historically because some expense report site back at former employer AMD was only compatible with IE. I also have a flight simulator for RC aircraft that only works in Windows (better to practice on the sim, no glue needed when you crash, just hit the reset button.)

All of those are merely annoyances, and I keep Windows around on one of my computers for this reason. It's not one I use primarily, nor one I carry with me when I travel.

But I also have created and support software that runs on Windows, or that people want to use on Windows. Software like nanomsg, mangos, tcell, etc. This is stuff that supports other developers. Its free and open software, and I make no money from any of it.

Supporting that software is a pain on Windows, largely due to the fact that I don't have a Windows license to run Windows in a VM. The only reason I'd buy such a license for my development laptop would be to support my free software development efforts. Which would actually help and benefit the Windows ecosystem.

I rely on AppVeyor (which is an excellent service btw) to help me overcome my lack of a Windows instance on my development system. This has allowed me to support some things pretty well, but the lack of an interactive command line means that some experiments are nigh impossible for me to try; others make me wait for the CI to build and test this, which takes a while. Leading to lost time during the development cycle, all of which make me loathe working on the platform even more.

Microsoft can fix this. In their latest "incarnation", they are claiming to be open source friendly, and they've even made big strides here in supporting open source developers. Visual Studio is free (as in beer). Their latest code editor is even open source. The .Net framework itself is open source.

But the biggest barrier is the license for the platform itself. I'm simply not going to run Windows on the bare metal -- I'm a Mac/UNIX guy and that is not going to change. But I can and would be happier to occasionally run Windows to better support that platform in a VM, just like I do for illumos or Linux or FreeBSD.

So, Microsoft, here's your chance to make me hate your platform a little less. Give open source developers access to free Windows licenses; to avoid cannibalizing your business you could have license terms that only allow these free licenses to be used when Windows is run in a virtual machine for non-commercial purposes. This is a small thing you could do, to extend your reach to a set of developers who've mostly abandoned you.

(And Apple, there's a similar lesson there for you. I'm a devoted MacOS X fan, but imagine how much wider your developer audience could be if you let people run MacOS X in a VM for non-commercial use?)

In the meantime, if you use software I develop, please don't be surprised if you find that I treat Windows as a distinctly second class citizen. After all, its no worse than how Microsoft has treated me as an open source developer.

Tuesday, December 8, 2015

Yesterday there was a flurry of activity on Twitter, and in retrospect, it seems that some have come away with interpretations of what I said that are other than what I intended. Some of that misunderstanding is pretty unfortunate, so I'd like to set the record straight on a couple of items now.

First off, let me begin by saying that this blog, and my Twitter account, are mine alone, and are used by me to express my opinions. They represent neither illumos nor Lucera, nor anyone or anything else.

Second, I have to apologize for it seems that I've come across as somehow advocating either against diversity (whether in the community or in the workplace) or in favor of toxicity.

Nothing could be further from the truth. I believe strongly in diversity and an inclusive environment, both for illumos, and in the work place. I talked about this at illumos day last year (see about 13:30 into the video, slides here), and I've also put my money where my mouth is. Clearly, it hasn't been enough, and I think we all can and should do better. I'm interested in finding ways to increase the diversity in illumos in particular, and the industry in general. Feel free to post your suggestions in the comments following this blog.

Additionally, no, I don't believe that anyone should have to put up with "high performing toxic people". The illumos community has appropriately censured people for toxic behavior in the past, and I was supportive of that action back then, and still am now. Maintaining a comfortable work place and a comfortable community leads to increased personal satisfaction, and that leads to increased productivity. Toxicity drives people away, and that flies in the face of the aforementioned desire for diversity (as well as the unstated ones for a growing and a healthy community.)

Finally, I didn't mean to offend anyone. If I've done so in my recent tweets, please be assured that this was not intentional, and I hope you'll accept my heartfelt apology.