Hacker News Reader

Comment by pjungwir | Hacker News Reader

I'm curious if anyone here from USDS or 18F has deployed Postgres in a FIPS 140-2 environment, and if so what challenges they had. The VA seems to be saying that Postgres should not be used:

http://www.va.gov/TRM/ToolPage.asp?tid=5692&tab=2

contrast that with Oracle:

http://www.va.gov/TRM/ToolPage.asp?tid=9&tab=2

(Don't miss the difference in tone on the "Analysis" tabs.)

I'm sure some of that is due to lobbyists, but nonetheless it seems to me that there are legitimate challenges in making Postgres meet FIPS 140-2 requirements. I've been able to recompile Postgres to use the FIPS OpenSSL wrapper, but storing passwords with MD5 is a harder issue to fix, and of course there is no definitive list. Does anyone have some experience with this?

View on HN

Hi! Engineer at USDS here.

There's definitely quite a bit of PostgreSQL in use in government, so this does not need to be a blocker. As someone noted, PAM auth is a good solution; and I think if you use CentOS or RHEL (Use the latest release please!) you'll end up with a FIPS OpenSSL which PostgreSQL is linked against.

More generally, the VA TRM is not a permanent thing, it's precisely the type of existing process which can be improved with the feedback of on the ground software engineers. If this is a blocker for you, I'm sure folks at DSVA would be happy to help!

Well, you can use SQLite instead :-)

http://www.va.gov/TRM/SearchPage.asp?catid=83&catName=Inform...

But it doesn't look good in general... :-( http://imgur.com/a/1ALQV

Contractor here, not USDS or 18F. I usually see Postgres configured to use PAM auth, often against LDAP. This can it make it easier to meet password complexity requirements (don't get me started) and lockouts after incorrect attempts (same).

I'm pretty sure the only OS that is approved for electronic voting systems is Windows XP, which has obviously become a problem, but a new OS would likely take two or more years to go through the approval process. Ubuntu changes so much in two years that by the time it is approved, it would have lost 2/3rds of its life even as an LTR.

I would assume that the main reason that Oracle is preferred is due to lobbying, but also the fact that they don't really innovate anymore so it is non-trivial for them to provide support and bug fixes for a decade or two.

Does anyone else find it extremely discomforting that the voting machines even have a full fledged OS?

It's a throwback to this xkcd https://xkcd.com/463/

In my mind, the ideal electronic voting machine:

- Has mechanical buttons which simultaneously punch a paper ballot in a manner observable to the voter

- Runs on a small (open source) microcontroller that's been audited for backdoors.

- Runs (open source) crypto directly on the metal

- Publishes the results in a cryptographically verifiable way.

IMO, anything else is evidence of at least government/contractor ineptitude, and potentially malfeasance.

In terms of security, that is probably exactly correct (I'm a complete security novice FWIW). Way too high of an attack surface area. That being said, as soon as you get into microcontroller territory, you turn it into a niche thing that makes it inaccessible to most. What are the chances of finding talent that can write user-facing code that runs bug free on microcontrollers while simultaneously writing/proving the crypto? Maybe that talent is more common than I suspect, but I certainly haven't seen it. I would be happy with rust/ocaml on a unikernel or rump kernel though :)

Why does dropping the OS mean you have to run on microcontrollers and write everything from scratch? All it means is your software needs to incorporate the OS functions that it needs for interacting with the hardware. You can still use any hardware platform you want and any third-party libraries available for said platform.

Which is exactly what micro controllers programming is.

I worked and still do some work for embedded programming. If you never did it before : OS make life super super easy. Really.

Well, yeah, most microcontrollers require bare-metal programming. That's not my point. My point is any device can be developed for that way, and that going OS-less does not mean having to write everything from scratch. After all, that's what the OS is: a bare-metal application that functions as middleware (amongst other things) for the hardware platform.

Also, I know having an OS makes it easy. If you have full control over the hardware platform and environment, and user interaction with the system is limited to a relatively small set of UI objects, you shouldn't need a full OS. Something bare-bones like DOS or FreeRTOS should be fine. Even on the box I worked on that used RHEL we stripped almost everything out. I'm still not sure why they decided to go with RHEL as the base, considering the amount of work that went into customizing it.

Microcontroller stuff isn't necessarily inaccessible. You can target extremely barebones platforms with Rust, and it goes without saying that C runs almost anywhere.

The point is to have absolute bare-minimum technology. There's no user-facing code to write, it should really be as simple as: - A function that encrypts an int between 0 and N, perhaps in homomorphic fashion - N-1 buttons (as in, mechanical contacts) that each trigger a subroutine "Encrypt the number X and broadcast it to whoever is tabulating and/or auditing the vote"

This is my reaction too. There are systems with no security flaws, but they tend to be small-surface devoted hardware. Something the size of Windows will consistently turn up zero-day flaws that could be used against voting, whereas plenty of on-metal microcontroller programs have no holes at all.

Frankly, a really reassuring voting system would be the exact opposite of what we have: it would be open to all security researchers and consist of minimal, verifiably-safe code to count vote totals.

Reply on news.ycombinator.com