Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Keeping Up With DoD Security Requirements In Linux?

timothy posted more than 5 years ago | from the behind-the-phony-curve dept.

Government 211

ers81239 writes "I've recently become a Linux administrator within the Department of Defense. I am surprised to find out that the DoD actually publishes extensive guidance on minimum software versions. I guess that isn't so surprising, but the version numbers are. Kernel 2.6.30, ntp 4.2.4p7-RC2, OpenSSL 9.8k and the openssh to match, etc. The surprising part is that these are very fresh versions which are not included in many distributions. We use SUSE Enterprise quite a bit, but even openSUSE factory (their word for unstable) doesn't have these packages. Tarballing on this many systems is a nightmare and even then some things just don't seem to work. I don't have time to track down every possible lib/etc/opt/local/share path that different packages try to use by default. I think that this really highlights the trade-offs of stability and security. I have called Novell to ask about it. When vulnerabilities are found in software, they backport the patches into whatever version of the software they are currently supporting. The problem here is that doesn't give me a guarantee that the backport fixes the problem for which this upgrade is required (My requirements say to install version x or higher). There is also the question of how quickly they are providing the backports. I'm hoping that there are 100s of DoD Linux administrators reading this who can bombard me with solutions. How do you balance security with stability?"

Sorry! There are no comments related to the filter you selected.

I am surprised (4, Interesting)

ls671 (1122017) | more than 5 years ago | (#28787075)

I thought the DoD would forbid to run newer versions that haven't been ran and scrutinized enough by a lot of people.

I though they would do like many big iron companies that run older versions with security patches applied. I mean if I remember right, no later than last week, exploits were found in newer versions like Linux kernel 2.6.30 and Firefox 3.5. I think this is more likely to happen with newer releases of software than with older releases tested through the years.

   

Re:I am surprised (2, Insightful)

Dragon_Hilord (941293) | more than 5 years ago | (#28787263)

I think there might be some changelog analysis going on too. If you see "Huge exploit xyz fixed in this patch", you're more likely to use the new, untested version just because a known exploit is closed. With security software, they're always usually fixing, improving, and generally securing their software.

I personally keep pretty up-to-date, and I can understand that a government agency would want to be completely on top of things.

"It's safer"

Re:I am surprised (3, Interesting)

vertinox (846076) | more than 5 years ago | (#28787265)

I thought the DoD would forbid to run newer versions that haven't been ran and scrutinized enough by a lot of people.

Depends on who you work for and what you do.

Not everything various DoD employees do is related to a "super secret project".

A lot of stuff in the DoD doesn't really have the need or want to be super scrutinized. Some of the stuff that they do is as boring as public relations and kitchen supplies.

Re:I am surprised (2, Insightful)

characterZer0 (138196) | more than 5 years ago | (#28787495)

Some of the stuff that they do is as boring as public relations and kitchen supplies.

Why would they possibly need the latest kernel version?

Re:I am surprised (3, Funny)

Midnight Thunder (17205) | more than 5 years ago | (#28787563)

Some of the stuff that they do is as boring as public relations and kitchen supplies.

Why would they possibly need the latest kernel version?

They probably believe it provides the kitchen sink ;)

Re:I am surprised (0)

Anonymous Coward | more than 5 years ago | (#28787677)

Why would they possibly need the latest kernel version?

Because exploits are fixed in the latest version, along with new bugs ;-)

Re:I am surprised (2, Informative)

piojo (995934) | more than 5 years ago | (#28787679)

Why would they possibly need the latest kernel version?

Wasn't there a kernel root exploit publicized (and patched) a few days ago?

Re:I am surprised (0)

Anonymous Coward | more than 5 years ago | (#28787829)

You mean boring like invoices for $30000.00 toilet seats?

Re:I am surprised (0)

Anonymous Coward | more than 5 years ago | (#28788837)

If you think they are really buying toilet seats with that money rather than just using that as cover for what they are really buying you are terribly naive.

Re:I am surprised (1)

opec (755488) | more than 5 years ago | (#28788847)

A lot of stuff in the DoD doesn't really have the need or want to be super scrutinized. Some of the stuff that they do is as boring as public relations and kitchen supplies.

That's what they want you to think.

Re:I am surprised (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#28787423)

Linux doesn't suffer from these peoblems like your Windoze does, Micro$oft shill.

Re:I am surprised (0)

Anonymous Coward | more than 5 years ago | (#28787545)

Yeah... In my experience, it's getting a new distribution approved that's a total nightmare.

There's only one Linux machine in the lab where I work, running 2.4.

There was an attempt to get a new machine into that lab with a 2.6 series kernel on it, but the paperwork took so long that the machine's need passed (workarounds were found) and it was moved to a nonsecure lab.

Re:I am surprised (2, Insightful)

RichardJenkins (1362463) | more than 5 years ago | (#28787883)

The submitter says using back-ported security fixes (presumably from some official repository) is not an option because it doesn't give a guarantee of fixing the vulnerability the original update was for. If this is a problem I'm curious as to why he thinks manually installing the latest versions is any better. Is someone being paid to guarantee the efficacy of security fixes but only in those latest versions? If that is the case why not just pay them to audit the back-ported fixes in a repository instead? If you're using Linux and have been shrewd enough to install all of your applications through the distribution maintainers repository, then the sweet-spot between security and stability *is* using back-ported security fixes.

maybe DoD needs to build their own distro (1)

nobodylocalhost (1343981) | more than 5 years ago | (#28788301)

Just build it off of slackware and distribute the whole thing using apt. That way, you just need to build the whole thing on one set of systems and distribute out to all the boxen you need to update/install.

Grindstone (1)

autocracy (192714) | more than 5 years ago | (#28787141)

You'll probably have to solve it by using build scripts and tarballs. If you're feeling really ambitious, up the ladder and find out why it's only by version. Finding versions for each distro is probably more work for the people who do the list.

Re:Grindstone (3, Informative)

jd (1658) | more than 5 years ago | (#28787455)

The most logical thing, surely, is to have a script that grabs the latest source, build suitable binary RPMs and a binary DEB, and then move these files to the correct directory for a repository manager.

(For RPMs, you could simply use the distro-supplied SPEC file and have the script replace values as needed. This only breaks when files are added/deleted, which usually doesn't happen.)

Alternatively, standardize on Slackware and banish the distro-specific issues to history. The drawbacks are less support and fewer fixes, but since the DoD can't track or test all variants, it's reasonable to assume they only track issues for the vanilla version. Distro-modded versions could have flaws added ad well as flaws removed, and in the DoD, it's better to have an absence of known threats.

Who sets those minimum versions? (2, Interesting)

PingXao (153057) | more than 5 years ago | (#28787153)

I smell something fishy. Sounds to me like whoever is making money off securing DoD systems is also involved in specifying what versions to use. If you run something that's been battle tested and known to be "safe" (relative term) then there's no money to be made.

Here's a cheap way to make DoD Linux systems safe: don't connect them to the public internet, period.

Re:Who sets those minimum versions? (3, Informative)

Jaysyn (203771) | more than 5 years ago | (#28787237)

The few DOD installations that my company has wired had two completely separate, very secure, physical networks. Big air gap between the secure PCs & the internet.

Re:Who sets those minimum versions? (4, Informative)

YrWrstNtmr (564987) | more than 5 years ago | (#28787511)

Jesus christ on a crutch. If I see this stupidly retarded statement one more time...
If you've been here on /.more than about 3 seconds, you would have come across a little tidbit of information alluding to the different networks within the US DoD, and their various levels of security. Not everything that lives on a hard drive in the DoD is sooper sekrit and needs to be cut off from the outside world.

Some of these networks are truly open. Some are only acecssible from a .mil domain. Some are not connected to the internet at all, and split with an air gap. And some even more restrictive than that.

Your oh so insightful remark is also a cheap way to hamper operations.
We need a -1 Dumbass.

Re:Who sets those minimum versions? (1)

Bromskloss (750445) | more than 5 years ago | (#28787821)

Some are not connected to the internet at all, and split with an air gap.

This "air gap", I see mentioned several times, what is it, really? The entire building floating on an air cushion?

And some even more restrictive than that.

You're getting me curious! What are those networks like?

Re:Who sets those minimum versions? (2, Informative)

Obyron (615547) | more than 5 years ago | (#28787931)

An air gap means the network isn't connected to the public internet, or to unsecured networks. The "air gap" is the open air between the secure computers and the insecure computers. At present most networking gear has a hard time routing packets through open air, but I hear they're ginning up a new RFC to address that.

Re:Who sets those minimum versions? (1)

HomelessInLaJolla (1026842) | more than 5 years ago | (#28787975)

I hear they're ginning up a new RFC to address that

As with most military projects it has been in the works for a long time [faqs.org] .

Re:Who sets those minimum versions? (2, Funny)

jonbryce (703250) | more than 5 years ago | (#28788083)

My Netgear box routes packets over open air without too much trouble.

Re:Who sets those minimum versions? (0)

Anonymous Coward | more than 5 years ago | (#28788239)

Whoooooosh!

Re:Who sets those minimum versions? (2, Funny)

Deltaspectre (796409) | more than 5 years ago | (#28788689)

802.11(b,g,n)?

Re:Who sets those minimum versions? (1)

Freetardo Jones (1574733) | more than 5 years ago | (#28788869)

At present most networking gear has a hard time routing packets through open air

That's weird. My 8 year old wireless router seems to handle routing packets through the open air just fine. *shrug*

Re:Who sets those minimum versions? (0)

Anonymous Coward | more than 5 years ago | (#28789049)

Would that be the entire 802.* - series of RFCs?

Re:Who sets those minimum versions? (1)

A. B3ttik (1344591) | more than 5 years ago | (#28788059)

Above dude is a little cryptic so I'll risk being redundant:

An air gap just means that the computer networks aren't physically connected to each other at all. They exist entirely on separate networks, and the secure one usually isn't connected to any network with computers outside the building, much less on the internet.

Re:Who sets those minimum versions? (2, Funny)

lennier (44736) | more than 5 years ago | (#28788763)

"And some even more restrictive than that.

You're getting me curious! What are those networks like?"

Their TCP three-way handshake goes like this: SYN SYN NACK.

Welcome, BARACK.OBAMA@WHITEHOUSE.GOV, to area52.31337.nopeeping.nuh-uh.icu.goaway.clubhouse.nwo.mil.
Your security clasification: ACCESS DENIED
Would you like to play a game?

$ls
NO
$cat .
NOPE
$pwd
AS IF
$cd ..
YEAH RIGHT

It simplifies things immensely.

Re:Who sets those minimum versions? (0)

Anonymous Coward | more than 5 years ago | (#28789029)

Uh, a locked series of rooms... Biometric locks... Guards with guns... Come on! Use your imagination! Yes, sci-fi takes this to an extreme, but sometimes it is real.

Re:Who sets those minimum versions? (1)

JWSmythe (446288) | more than 5 years ago | (#28788469)

    If I was working on something that needed real security, I'd prefer a steel reinforced concrete gap with armed guards outside. But I guess an air gap would do. It doesn't do much for the physical security though. :)

Re:Who sets those minimum versions? (1)

megamerican (1073936) | more than 5 years ago | (#28788485)

Your oh so insightful remark is also a cheap way to hamper operations.
We need a -1 Dumbass.

I think a +1 Bad Example would be more appropriate. Have it be karma neutral like +1 Funny. Even if you are a total failure you can still be used as a bad example!

Doing your job? (0, Flamebait)

NewmanKU (948325) | more than 5 years ago | (#28787159)

"I don't have time to track down every possible lib/etc/opt/local/share path that different packages try to use by default."

Sorry to sound like a jerk, but isn't this what you're paid to do?

Re:Doing your job? (1)

Aphoxema (1088507) | more than 5 years ago | (#28787225)

Sorry to sound like a jerk, but isn't this what you're paid to do?

What, create time?

Re:Doing your job? (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28787565)

working smarter vs working harder?

Re:Doing your job? (1)

Midnight Thunder (17205) | more than 5 years ago | (#28787653)

Sorry to sound like a jerk, but isn't this what you're paid to do?

While it might be, is that any reason not to want to find a software solution to make his life easier? Heck, I thought that was what software solutions were all about? Also, have you considered it might not be his only job?

Re:Doing your job? (1, Troll)

HomelessInLaJolla (1026842) | more than 5 years ago | (#28787849)

is that any reason not to want to find a software solution to make his life easier?

That sounds great in theory but, mostly, it is the excuse of the incompetent who would like to have someone else do the work while they gather all the credit. The conceptual progression is no different than cheating on homework beginning in second grade.

I thought that was what software solutions were all about?

I think we've come a long way from the original path of software solutions. The system began as people who had computers at their disposal and who enjoyed working with them. They created solutions--heck, they created their own problems. They found new hardware, or new software, or new applications, and they had a simple interest to put things together and make them work. They created software solutions. Some of them began to sell their software solutions to people who needed them. The most inventive minds, however, continued to create their own solutions.

I think the largest problem is that management has even forgotten this. They want the job done. They do not want to spend money on it, they do not want to wait for it to happen, whatever the need is the managers want it done, now, at no cost. Part of this is just the crap rolling down hill from upper management who want something to report to the executives, and the executives just want to have material for their latest bout of grandstanding and speeches at various dinners, conferences, get-togethers, or golf outings, to have that edge to be able to feed to the investment partners, so that the numbers which drive their salaries and bonuses will go up. So the investment partners want something, that makes the executives want something, that means upper management wants something, that means middle management wants something, that means that front line managers want something done, and that means someone must do it.

So, rather than seeing people who have a genuine interest in developing and advancing computer, hardware, software, and programming technologies and art forms... we have an enormous population of what amounts to slightly more technically trained button pushing monkeys. These monkeys are slightly better than previous generations of monkeys in that these monkeys have been trained to be able to recognize more technical language and can follow the mouse pointer across the screen with their eyes.

I don't think the DoD wants "purchase, install, and deploy" monkeys--though quite likely the managers who will administer the posted position will (because monkeys are easier to push around and ride for their own professional profit than a real thinking human being). I think the requirements are set attempting to find those candidates who really and truly have a desire to work with those systems.

Re:Doing your job? (1)

JWSmythe (446288) | more than 5 years ago | (#28788307)

    Really....

    "Sorry, I can't be bothered with finding this, so I'll ask Slashdot how to do it without trying."

    I would think his problem should be pretty simple. SuSE does have a package manager, right? You can uninstall the vendor package, and install your own. Voila, problem gone.

    I've been known to do both the tarball method, and the source method. It's really not *that* painful to build things from source directly on the machines in question. Writing a script to log in and do something like

echo "To: me@dod.gov\nSubject: " > /tmp/somemsg
hostname >> /tmp/somemsg
echo "somepkg\n\n\n" >> /tmp/somemsg

rpm --erase somepkg >> /tmp/somemsg
cd /usr/src/
wget http://internal.dod.gov/srcs/somepkg.tar.gz [dod.gov]
tar xpzf somepkg.tar.gz
cd somepkg ./configure && make && make install >> /tmp/somemsg
sendmail -t /tmp/somemsg

cd ..
rm -rf somepkg
rm somepkg.tar.gz
rm /tmp/somemsg

DOD Repository (1)

Jaysyn (203771) | more than 5 years ago | (#28787165)

Can you set up your own private DOD repository to hold those newer versions? Beats updating a ton of PCs manually.

Re:DOD Repository (1)

Protocron (611778) | more than 5 years ago | (#28788725)

Yeah, I worked at shitty little web hosting company and they had their own repository server for updates to all of the managed servers. The admin team has at least three security guys who's job it was to QA the repository on pretty much a daily basis. They monitored for security patches and posted them to the repository as soon as possible. And we supported about 4 different OS's at the time.
I can't see why you won't have your own repository with a few people who knew deb/rpm package building for your specific repositories. And then it's just a matter of standardization. "Here are the OS we support."

Security Breach! (1)

barnyjr (1259608) | more than 5 years ago | (#28787175)

"I've recently ***been fired from my job for telling everyone I'm*** a Linux administrator within the Department of Defense." ... fixed.

Re:Security Breach! (0)

Anonymous Coward | more than 5 years ago | (#28787493)

seriously, who would post sensitive information about themselves and details about their network, for the whole internet to see....back to security 101 for you..

Re:Security Breach! (1)

JWSmythe (446288) | more than 5 years ago | (#28788529)

Ya, I'm pretty sure that's a no-no. Unless he didn't really work for DoD, and he was just hoping that blurb would make him browny points with the Slashdot crowd. Reading the comments so far, it doesn't look like it made him any new friends. :)

Let the process work. (4, Informative)

tprox (621523) | more than 5 years ago | (#28787241)

Apply for a waiver on those requirements :)

Re:Let the process work. (0)

Anonymous Coward | more than 5 years ago | (#28787325)

Ding ding ding, we have a winner!

Re:Let the process work. (1)

MaerD (954222) | more than 5 years ago | (#28787809)

Please Mod this up. I have not worked for the DOD, but I worked for a Linux vendor that had DOD customers.

This came up all the time, and for the major Linux vendors (SUSE, Red Hat) either a waiver or looking at a "We're running RHEL/SLES X with updates" type blanket exception was the best solution.

Re:Let the process work. (5, Informative)

bcong (1125705) | more than 5 years ago | (#28787977)

He's not kidding. The waiver is called a Plan of Action and Milestone (POA&M) if he's going by the DoD/DISA IA vulnerabilities and their vulnerability management system. This is the only way they can actually set maintenance schedules. A lot of the admins submit these 'waivers' with a plan of action which includes quarterly or monthly patch days, otherwise they'd have to run patches every other day, possibly breaking their applications and services. It's a lot easier to bulk patch and test the app/service once a month or quarter than every day. The frequency of DoD IA notices is so high that this is the only manageable solution.

A few things (2, Interesting)

lymond01 (314120) | more than 5 years ago | (#28787243)

1) Does the DoD contribute heavily to security software programs or packages? If so, they probably know which libraries are needed as they've been using them to provide the updates.

2) Maintenance of multiple server systems is always difficult. This is why Rocks was developed and why some develop their own startup and build scripts for clusters or server farms. Advanced scripting techniques are a must in a large environment.

3) Even if DoD doesn't contribute, they'll always point out the latest stable software and security fix. If you're talking about the defense of the country, how could you say, "We recommend this version...the one with the security hole that was fixed in the next version."

repo (3, Funny)

arnodf (1310501) | more than 5 years ago | (#28787255)

add my repository, it has all the latest versions of everything, trust me, just update everything from my repo, you won't regret it...

Rolling Distrobution (2, Informative)

iVasto (829426) | more than 5 years ago | (#28787277)

If you need to stay cutting edge, why not use a rolling distrobution such as Arch or Gentoo? You could also set up your own repository where you build the Suse packages once and then push them out to all systems.

Re:Rolling Distrobution (1)

chrysalis (50680) | more than 5 years ago | (#28788269)

I second this.

Arch Linux and Funtoo can fit the bill.

Anonymous Coward. (0)

Anonymous Coward | more than 5 years ago | (#28787293)

Dump SuSE (SLES)

Military Mirror (1)

RichMan (8097) | more than 5 years ago | (#28787301)

If it is an issue I am surprised there is not a military mirror.

Why would not CyberCommand (or whatever it is called) maintain a mirror of OS they approve of.
It is easy enough to set up and they can log all the machines to make an inventory. Even make sub-mirrors for different commands.

Re:Military Mirror (2, Interesting)

neowolf (173735) | more than 5 years ago | (#28787437)

That was my first thought. If the DOD requires specific versions- they should maintain repositories of them on their own servers. Perhaps one on their secure/classified network, and one on a more accessible network. They could be writable by only a few key people, so their chances of become corrupted would be very low.

Re:Military Mirror (0)

Anonymous Coward | more than 5 years ago | (#28787749)

I work in the Air Force and deal heavily with the systems and network folks because my job deals with web communications between very geographically separated bases. Unfortunately, I have not been able to have direct access to many of the poeple who operate and maintain many of the servers on which I depend. In my discussions with some of the more senior level staff they indicated that several of the systems on which I rely were running linux, but only specifically approved versions by the NSA. Perhaps the NSA has some guildlines or procedures for applying/testing/approving patches for various version of linux in the DoD?

Re:Military Mirror (1)

nahdude812 (88157) | more than 5 years ago | (#28788367)

They probably want to departmentalize that to a certain extent; a single source for all military computers would mean a single point of compromise for all military networks.

There are also networks isolated by an air gap which have no outside connection but should still be running patched software.

Tarballing? Maybe you should try... (0)

Anonymous Coward | more than 5 years ago | (#28787307)

"Tarballing on this many systems is nightmare and even then some things just don't seem to work."

Maybe you should try untarballing. :-)

Switch distros? (3, Insightful)

HFShadow (530449) | more than 5 years ago | (#28787333)

Take a look at gentoo, it'll definitely be bleeding edge enough to have the latest versions. Ubuntu server might satisfy your needs too.

Re:Switch distros? (2, Informative)

$RANDOMLUSER (804576) | more than 5 years ago | (#28787479)

Running a local Gentoo rsync server would be my first choice. You update one box, everybody else updates from there.

Re:Switch distros? (1)

BluePeppers (1596987) | more than 5 years ago | (#28787655)

I wouldn't take gentoo, you'll spend all day updating (and most of the night). I suggest Arch linux, for: a, Binary repos b, Easy packaging c, Source install tracking d, Up to date repo's (relatively) e, Rolling release distribution f, Packages are easy to mark out of date

Re:Switch distros? (2, Informative)

Lord Ender (156273) | more than 5 years ago | (#28787769)

Why on earth would you need to update all the time? If it were me, I would install gentoo once, then only update those packages on the DoD's list.

Re:Switch distros? (1)

Bert64 (520050) | more than 5 years ago | (#28788999)

Gentoo lets you build binary packages too, build the packages on one box and send binaries to the rest... That way you can update what you need to and leave what you don't, with binary packages dependencies often have to be replaced too... For example, something built against glibc 2.8 will require glibc 2.8 at runtime, even if its perfectly capable of being compiled against a much older version.

Re:Switch distros? (2, Informative)

dpilot (134227) | more than 5 years ago | (#28788071)

One addendum to the Gentoo thing...

If you're running a "real shop", in other words many boxes that you want to keep in sync, dedicate one or a few as "binhost servers". Compile there, and the rest of the machines just fetch binaries.

Only problem is that it defuses the usual "waiting to compile" Gentoo jokes.

Re:Switch distros? (1)

arndawg (1468629) | more than 5 years ago | (#28788273)

One addendum to the Gentoo thing...

If you're running a "real shop", in other words many boxes that you want to keep in sync, dedicate one or a few as "binhost servers". Compile there, and the rest of the machines just fetch binaries.

Only problem is that it defuses the usual "waiting to compile" Gentoo jokes.

Also you have no excuse to slack off because "you're compiling". But yeah. That's what i do. Hardened gentoo. Local Rsync, BINHOST and DistCC. Compiling time is a none-issue. :) Oh and remember to add glsa-check to your cron and mail when something important comes up. :) I also have a "staging" server with all the services installed. Just to see that all is working before distributing everything to the other servers.

Re:Switch distros? (1)

bcong (1125705) | more than 5 years ago | (#28788353)

Neither Gentoo nor Ubuntu is on the certified products list....and therefore DoD won't/can't use it. Welcome to the Government, the land of red tape. http://www.niap-ccevs.org/cc-scheme/vpl/ [niap-ccevs.org]

security and stability (0)

Anonymous Coward | more than 5 years ago | (#28787335)

How do you balance security with stability?

Those who give up a little security for temporary stability deserve neither. -Ben F. Ranklin

Wrong (1, Informative)

Anonymous Coward | more than 5 years ago | (#28787351)

DOD does not mandate software versions for the most part. The notion that DOD requires kernel 2.6.30 right now is completely wrong.

They mandate patching specific vulnerabilities, but that doesn't require upgrading to the latest software version. RHEL is a great example of a distribution that patches vulnerabilities without updating to the latest major versions of specific software, and RHEL is widely used by the government and military.

*shrug* (1)

forgottenusername (1495209) | more than 5 years ago | (#28787361)

You're going to need time (or a team) and some custom solutions. You're looking for something like pkgsrc methodology where you can push the same packages out on different machines regardless of their distro, and some really great management software for it all.. like puppet or something along those lines.

This all sounds like a kludge and the Wrong Thing to Do(tm).

If the Linux distros in question are the same, you could probably leverage the distros package management system. For instance it wouldn't be all that difficult in Debian realistically, depending on which packages they were worried about. Desktop, forget it, nightmare city.

I foresee a lot of testbed work!

Something seems wrong though, I'd be surprised if there wasn't either a secure internal repo or a more sane way that "always get the latest!! omgz".

euh? (0)

Anonymous Coward | more than 5 years ago | (#28787425)

'I'm hoping that there are 100s of DoD Linux administrators reading this who can bombard me with solutions.'

So you guys don't speak to each other? No mailing list, nothing?

Surprising??? (1)

croddy (659025) | more than 5 years ago | (#28787429)

The surprising part is that these are very fresh versions which are not included in many distributions.

that's not surprising, or you're not paid to administer linux systems.

really, now.

I take exceptions! (3, Informative)

SoupIsGood Food (1179) | more than 5 years ago | (#28787451)

Get ready for paperwork! You will need to apply for exceptions for everything that's out of compliance... I've worked in similar institutions, tho not the DoD, but most places run this the same way. The list of software in compliance is usually generated by the infosec team, and it's more of a wish-list than a demand... but to pass your audit, you will need to have permission to run out-of-spec software, and document why it's out of spec (vendor doesn't support that ver) and what you're using instead (the ver. the vendor supports). This is generally so the pen-test, NIDS and Intrusion Response people know what they're dealing with.

Have a chat with your info security shop - they'll walk you through it, and they're secretly envious of unix admins. They yearn for your aura of splendor and awe.

Easiest answer (1)

kyliaar (192847) | more than 5 years ago | (#28787471)

The biggest problem that I think you are experiencing is that you seem to have an expectation that mandated requirements in a governmental sphere are completely sane and workable. I am trying to see how I can phrase this without just making a sweeping generalization about the inefficiency and beauracracy that is attached to things run by the state. In general, I would say that the primary reason for this is that, in the public sphere, it is easier to attempt to solve a problem (real or imagined) by taking another thing on top of the pile rather sorting through issues and finding the actual root cause and resolving that.

So, having said that, don't expect all policies to make sense while working for DoD. If you are fine with that, just do what you are told as best you can with plenty of CYOA. If you are not fine with it, don't try to fight it. Go work elsewhere.

Roll yer own packages (2, Informative)

drspliff (652992) | more than 5 years ago | (#28787489)

Back when I was managing SuSE systems we had our own local mirror of the main updates repository, and another repository of custom packages rolled in-house. The documentation ( http://en.opensuse.org/Creating_YaST_Installation_Sources [opensuse.org] ) covers this pretty well.

Either way there's no excuse to be compiling packages on each server and managing the usual /usr/local & /opt mess, not to mention with autoyast iirc you can configure it to update packages at specific times of the day unless there's a reboot necessary (and even to reboot automagically for new kernels)

The Solution! (1)

iYk6 (1425255) | more than 5 years ago | (#28787529)

Run Debian Stable. Have a few members of DOD join the Debian Security Team. Everybody wins/profits!

I understand (1)

HomelessInLaJolla (1026842) | more than 5 years ago | (#28787571)

The desired effect is not what you think it is. The desired effect is not to ensure that the particular update releases of packages are whatever they are; that is a secondary and obligatory requirement. The desired effect is to ensure that anyone who is attempting to deploy a Linux type solution in the DoD has the requisite skills and understanding to create a stable system beginning with those requirements.

Imagine if the spec was "use distro XYZ". Great. Installers have become fairly streamlined and even newbs are able to install a given distro. If the spec was for older, more stable releases, then there would be little incentive to fill positions with people who are motivated to advance the technologies. The specs do not need to be completely bleeding edge and, for the sake of conceptual security and practical updates, the specs should be a little behind the latest releases hot off the press.

Tarballing on this many systems is nightmare and even then some things just don't seem to work.

Obviously I, as a homeless man, would be much more qualified for the position than you. I enjoy the challenge of inventing my own systematic solution for situations that are "nightmares" or "just don't seem to work". My skill set is likely to be precisely what they are looking for.

But DoD cannot have me. I work only for God. DoD is free to give me money, they are free to provide a place for me to live, they are free to provide an office and systems for me to use... but the very first moment that my manager tries to pull any of that political office crap where he covers up his complete blithering idiocy by invoking his age or the level of his academic degree then they would have to kiss my beautiful a$$ because I would walk out the door on a dime and not even bother to leave a single penny in change. Eff 'em to the end.

So, no matter how much more highly qualified I am than any other candidate for any given position, the fact that I refuse to put up with political bullsh*t from old men who feel that their age, combined with their white hair and their funny moustaches, entitles them to do whatever they want means that employers will happily accept a less qualified, but weaker willed, candidate.

The loss is theirs.

Just email him (1)

Hadlock (143607) | more than 5 years ago | (#28787667)

Find the guy's email address of who writes those specs (located somewhere on the doc, I'm sure), or it's on the server that hosts those docs, and email him and ask him where your local depository for the latest .mil approved packages are.

Weigh each vulnerability individually (5, Informative)

Bryan_Casto (68979) | more than 5 years ago | (#28787757)

There are many, many ways to deal with this, but fortunately while DoD says "update to this specific version," what they really mean is "close this specific vulnerability." Get used to hearing about IAVMs and VMS (Vulnerability Management System).

Taking the case of OpenSSL specifically, it's not uncommon for there to be patches released for vulnerabilities affecting a previous version. If you're using a vendor like Redhat (and in the mind of DoD, Redhat/SuSE = Linux, and nothing else) what you'll end up with is a version of OpenSSL that appears vulnerable, but in fact has a backported patch applied to the vulnerable distribution. Once you've applied the updated RPM, you can say in good conscience that you've mitigated the vulnerability, and you can close the finding.

Where it gets stickier is where you have code that depends on a specific version of a library that might be vulnerable. In that case, you need to dig in and understand the specific uses and how you might be able to mitigate the vulnerability by turning off a publicly listening service or applying some strict file controls, or maybe you don't exercise the vulnerable function in the library and can justify it that way.

Ultimately, you have to be able to convince your DAA (Designated Approving Authority) to accept the risk. If you can't immediately close the issue, you have the option of doing a POAM (Plan of Action and Mitigations) that will outline how you're going to mitigate the issue until you can close it.

There are a ton resources, but specifically I'd start here:

http://iase.disa.mil

You also might find this interesting as a way to secure Redhat machines:

http://people.redhat.com/jnemmers/STIG/

Feel free to contact me if you have more specific questions as well.

trust the vendor (3, Interesting)

OlRickDawson (648236) | more than 5 years ago | (#28787765)

First of all, if you work for the Navy, the distribution must be within DADMS, so you can't just run any random distribution. I also run a few linux machines for the DoD (the Navy specifically). The rules are enforced by the scanners. I take the vendor's (RedHat in my case) backported patch at their word, that they have fixed it. If you read their patch documentation, when the security alert is issued, that they have implemented the patch. The network security scanner doesn't pick up that you have patched it, because the version number doesn't match. I submit the RedHat's patch document with the report, as evidence that I have done it. It satisfies the auditors, because, to them, it's no worse than trusting Microsoft that they have patched their stuff. I don't have the time to investigate and test to see if the vendor actually fixed the problem with their backported patch. I leave that for the security exports to ping on them if they failed to do their job. Besides, that's what I'm paying RedHat for. I don't have the time to make sure that Microsoft fixed all of their stuff either. I patch and go, and document it what I have done. As long as their is a paper trail to prove that you have been patching, all is well.

Re:trust the vendor (4, Interesting)

idiotnot (302133) | more than 5 years ago | (#28788557)

DADMS is DoN-only for a reason; nobody else has the NMCI problem, and it didn't exist prior to NMCI. It's somewhat disconcerting to sit in on a meeting for a joint POR system, and have flag officers wonder WTF the Navy isn't implementing. "Uh, it's not in DADMS, sir." Sparks fly to say the least.

That said, the procedure is pretty simple, and since DITSCAP/DIACAP provide for it, you run specific vendor patches for whatever vendor-supported OS you're running (sorry Gentoo fanboys, roll-your-own isn't allowed in production systems). The Unix SRR script *should* be able to figure out if the backport is applied in a vendor-supplied patch, and pronounce it okay.

(The SRR scripts are publicly-available to everyone; if you're not running a commercial distro, you'll probably get some weird results, but it's still pretty good at picking out possible problems, even on systems that aren't officially-supported. I've run it on everything from Debian, including GNU/Hurd to OS X. http://iase.disa.mil/stigs/SRR/index.html [disa.mil] )

If something is revealed that's not accurate, you document:
a) why you can't fix it (i.e. whatever system is running on top ceases to work, the vendor refuses to fix, the vendor is tango uniform, it's Wednesday and you don't feel like it, etc.),
b) why the scanner goofed up and picked out a problem that doesn't exist (yes, this version is different, but the vendor backported the fix [with proper vendor reference] to this, which is applied).
or
c) the fix hasn't been released and fully tested yet.

Cases a and c are what a POA&M is for, which is normally submitted along with the accreditation package, and updated periodically.

It's a trap! (2, Insightful)

bugnuts (94678) | more than 5 years ago | (#28787771)

I'm hoping that there are 100s of DoD Linux administrators reading this who can bombard me with solutions. How do you balance security with stability?"

Computer security configuration data is on a need-to-know basis. Anyone revealing UCI will be receiving a call or visit from an armed person who had his sense of humor surgically removed. :-)

/workedtoolongforDOE

Simple: (1)

alexborges (313924) | more than 5 years ago | (#28787793)

1) Go to redhat.com
2) Contract them for a largish consulting period and have them do a package channel for you guys
3) Dump suse
4) live happily ever after.

If you need fresh RPMs on RHEL use koji (1)

Nicolas MONNET (4727) | more than 5 years ago | (#28787805)

RHEL5 is getting a little stale and we often need more recent versions for various reasons; I found that downloading SRPMs from koji.fedoraproject.org and recompiling them on RHEL usually worked. The only annoying thing is that from F11 on the RPM compression has changed and RHEL can't unpack them; so I have to unpack them on my Fedora system first.
Then I just build them, sign them with our GPG key, and copy them over to our loca repo, and just run "createrepo." It's not that big a deal.

Re:If you need fresh RPMs on RHEL use koji (1)

salimma (115327) | more than 5 years ago | (#28788547)

Or get the sources straight from <a href="http://fedoraproject.org/wiki/Using_Fedora_CVS">CVS</a> -- the downside is you won't know whether a particular revision results in a successful build or not, without checking Koji.

Just Stick to Vendor Packages and Document It All (0)

Anonymous Coward | more than 5 years ago | (#28787857)

You install the latest security patch packages from your distribution vendor (on a reasonable schedule) and that's it. (Never install a non-vendor package if you can help it.) As IAVAs are published, do the quick research to determine if it even applies to the vendor's package and, if so, what update is necessary (for most IAVAs, it should be pretty simple to trace it back to an advisory from your vendor): then you'll have the documentation when needed to present to your IAO or DAA. (For bonus points, share this information on Intellipedia to help others :-)

Where are you finding these "requirements"? (5, Informative)

SpaFF (18764) | more than 5 years ago | (#28787869)

I am a Linux administrator at a DoD site. I have never seen anything that says that you must run kernel 2.6.30 or anything like that. Can you please provide a link to where you read this? (links to CAC-authenticated websites are ok)

DoD I-8500.2 requires you to run an OS that is EAL certified at a certain level depending on your classification. The only Linux distributions I know of that have EAL certification are SLES (9 and 10) and RHEL (4 and 5). I keep hearing about people that run things like Fedora, CentOS, and Ubuntu on DoD networks, but I have no idea how they get away with that.

As far as software versions go, what versions you must be at are dictated by IAV-A, IAV-B, and IAV-T notices. The IAV-A may say that there is a vulnerability that affects kernel versions = 2.6.30 and that you must go to 2.6.30 to be compliant, but as long as your vendor's kernel version addresses the CVEs that the IAV-A references then you are covered.

Re:Where are you finding these "requirements"? (1)

Arakageeta (671142) | more than 5 years ago | (#28788443)

What about STIGs (http://iase.disa.mil/stigs/stig/index.html)? Complete STIG compliance is a pain in the ass. Bastille Linux (is it dead?) doesn't even get you there half of the way.

Re:Where are you finding these "requirements"? (1)

JimmytheGeek (180805) | more than 5 years ago | (#28788597)

Yep - STIG compliance is a pain, esp. if your linux box is an appliance, not a general-purpose multi-user box. I do think it cool they appear to care about securing their systems, though.

Re:Where are you finding these "requirements"? (0)

Anonymous Coward | more than 5 years ago | (#28788883)

In my humble experience running sites for the DOJ, which for the most part follows NIST recommendations, they'll take anything as long as you pay a consultant to come in and certify the system.

In my cases, I follow the current EAL3 configuration guidelines and submit the configuration for certification. $27,000 and 1 day of futile attempts to compromise the system later, it's approved and I can start rolling it out.

While official EAL certification is only available on a few distributions, the things they do to make those distributions compliant are publicly documented, and you can replicate the configuration on any distribution.

a what path? (1)

AliasMarlowe (1042386) | more than 5 years ago | (#28787887)

I've got several Linux systems, and not one of them has a lib/etc/opt/local/share directory!

It's simple, really (2, Insightful)

KGBear (71109) | more than 5 years ago | (#28787937)

In this, like in many other things, the Windows way of thinking has poisoned the issue. The way Windows people think, reinforced by Microsoft's implementation of Patch Tuesday, has been picked up by systems auditors and managers and bureaucrats everywhere. So the mantra today is that you must patch. Hurry! There's a new version! If you don't install it now we're all gonna die! This comes from the fact that that is a pretty simple metric that can be written in policies and checked during audits.

If you lose data or your system gets abused and you're patched to the latest version you're off the hook. If you don't have the latest patch however you're fired. Even if the latest patch fixes a local privilege escalation on libgd2 and all your server does is DHCP and it was actually exploited by someone cleverly guessing your co-worker's password.

Same thing with firewalls: if all you run is a web server, I say you make sure nothing else is running that opens any ports. It's no use to setup a firewall, because the thing that is most vulnerable, port 80, will need to be open anyway. But get caught without a firewall in some places and you're fired.

It's a lot easier to write a meaningless list of requirements than to think about needs and policies and design the requirements

It's a lot safer to follow some dumb list of requirements than to try to understand what your systems are doing and configure accordingly

It's a lot easier for an auditor to check a list of requirements against the output of some version-checker than to actually know what these things do

It's the dumbing down of engineering that passes for systems administration these days. It's the Windows way of thinking.

Easy Solution (0)

Anonymous Coward | more than 5 years ago | (#28788013)

Why is this a problem in the first place? Whoever the contractor is suppliying the software should be responsible for keeping it up to date, even if it means producing its own software packages and providing them in a secure manner. Isn't that in the freakin' contract? If not, why not? And if you're the "contractor", just do your job. problem solved.

Backports FTW (2, Interesting)

jwriney (16598) | more than 5 years ago | (#28788109)

Congratulations. It's now your job to check every *single* *freaking* *package* where the DISA specs proscribe a particular version, and see whether or not your vendor backported the security fix. Usually the DISA specs will contain a vulnerability id (CVE-ID or similar) that you can reference against. Google is your friend. The overall process is murder. It's a big reason why I got out of government IT. On a related note, I find the Linux vendor practice of keeping old version numbers, but backporting new fixes into their own trees (Red Hat's "version x.y.z-ELsomeothernumber" system for example) to be categorically infuriating, but that's a different rant. --jwriney

Check out Security Blanket (0)

Anonymous Coward | more than 5 years ago | (#28788201)

Have you checked out Security Blanket yet (http://www.trustedcs.com/securityblanket)? Currently they support RHEL/CentOS/OEL 4 & 5 (x86, 32 and 64 bit), and Solaris 10 (x86 and SPARC). I believe support for Fedora 10 is due shortly, and SUSE support is also on the roadmap. The tool can scan a particular box for compliance with various security guidelines, and if any issues are found can automatically remediate the problem, including undoing this remediation at a later date. There are pre-built compliance 'profiles' to address guidelines such as CIS, DISA STIG, PCI DSS, and others. Each profile is composed of individual modules (such as a minimum number of characters in a password), so custom profiles may be built.

I feel your pain... (2, Informative)

The Mighty Bill (210350) | more than 5 years ago | (#28788423)

As a former DoD Linux admin (one of the first for that organization), the best way I've found to keep everything in sync is to build updates yourself (essentially, you're doing the vendors work for them). I know of the guidelines you speak of and the regular advisories and it was quite a task to implement something reasonable. In the end though, the only way I could both satisfy both the security concerns and maintain the rpm database integrity was to build updated versions of the vulnerable software myself and install them.

`rpmbuild` is definitely your friend. Build a template spec, then as you need to update versions, you just modify a few details and away you go.

I worked primarily with Red Hat at the time (though I am working with SuSE now) and had the same problems you've described. They (the vendors) typically do not update quickly enough and if you ask them for direct support, you usually get the run around. The "minimum" version issue is particular painful, as it will show up, even if the vendor backports (I'm assuming you're catching these when running the "unix" scan util).

So long as the updated rpm "provides" everything the old version did, you should have no dependency issues. Good luck.

Do it once, distribute it with M23 (1)

burni (930725) | more than 5 years ago | (#28788453)

I think it can be adapted for Suse

http://en.wikipedia.org/wiki/M23_software_distribution_system

Here's a solution (1)

lwsimon (724555) | more than 5 years ago | (#28788493)

Holy crap, I have an answer for this.

Run ArchLinux - pacman is *perfect* for this role. Just set up a local repository and have your client image include only it. Set up a cron job on the image to do a "pacman -Syu" nightly - that's "update your package list from the repo, and install any newer versions"

Then you have a test system that you can test new versions on, and when you're ready to launch, update that package in your local repo. That night, all your clients will update to the new version.

The only thing this wouldn't address is adding packages to the systems en masse - but even this could be done in a slightly hackish way - just add the new packages as dependencies for the new version of an existing package - or better yet, roll you own PKGBUILD that installs nothing, but has all the dependencies for packages not part of the ghost image.

Arch is pretty up-to-date on package versions, and since pacman compiles from source, you can roll your own if you need something before it comes out in the official repos.

Security takes precidence (1)

Xanthvar (1046980) | more than 5 years ago | (#28788623)

The reason that you are required to use version x.y.z or newer is because, there are security vulnerabilities with the earlier versions, and (generally speaking) if it is connected to NIPRNET and publicly facing, it is a matter of WHEN it gets hit, not IF. This is why there is a STIG, and why you need to periodically run it against your production boxes to keep them current.

If you are a DoD admin, then you have been briefed on why you need to do this, I'm not going to waste time talking about it here. Failure to remain current is a reason for DISA to shut off your connection.

The scenario that there is a vulnerability, but there isn't a fix for it available yet, and you are at the mercy of volunteers to fix it, is the one of the nightmares of DoD policy makers. This is why they often argue for non open source software, because the idea is if they pay for it, then they have someone's feet they can hold to the fire(not literally, but figuratively, anyway) to get it updated! (Yes, I realize that this isn't really the case often, and closed source can take forever to close a hole, but this is the argument... facts don't always come into play when lobbyists get involved).

I always thought DoD would be the perfect place for open source software, where they could build an approved flavor of Linux, set up an approved distro site, and then hash everything to make sure that you were running version that was blessed by security to help alleviate trying to support everyone's own custom setup. Unfortunately, there are several major problems that I see with this:

1. You are beholden to the vendor of your product, and what they say they support. This is part of the bane of COTS. Not everything is developed to run on Trusted Solaris. You use whats out there in the world, not what DoD has hardened. This makes sense for budgetary purposes, but is sometimes at odds with security. "Oh, we realize that there is a vulnerability in the subsystem, but we don't support the upgrade because it breaks out system." This is also why there are so many system still running IE6.. because the java apps that were written by the tons don't work on IE7 or later (or better yet, a non M$ browser) because they don't want to update the code (or can't because the guy who cobbled the original together is no longer there, and no one else understands what the heck he did...)

2. DoD or at least the military, doesn't want to be in the development business. They only have a finite amount of bodies, which they can devote to war fighting, and don't want to waste them on support roles (try not to laugh to hard, I know they don't do a good job of this either, but that is the concept anyway). They get around this by hiring civilians and contracting support roles out, but often, this leads to enormous amounts of oversight and administrative overhead (and don't forget about the opportunity to line the PORK barrel while you are at it), and suddenly what was an inexpensive concept is not a multi-million dollar monster with a life of its own.

3. It's far easier to find vulnerabilities that it is to fix them. Also, systems have gotten so complex, and with so many components, and at times a house of cards looks more stable than a server (DCTS, I'm looking at you).

I think China might have the right idea. Mandate your own OS, and only let it be used for official purposes. This is a great idea on paper, but in practice it would run afoul of the issues mentioned above. It might work for China if they don't have a lot of modernization or a bunch of legacy systems already, that would need to be converted. They may have the willpower to want to spend the money needed to make everything happen, but I don't see the US doing this anytime soon. It is probably going to take some very painful lapses to occur before this will take place.

I apologize if I seem like for the over use of acronyms, but hey, this is about a DoD system :)

As far as the OP goes, you might talk to some guys who are maintaining *nix systems on networks other than NIPRnet, to see if they have created their own distros, repos, or if they are doing something else. I do feel your pain, as I recall the days of STIGing Solaris 8, when it came with BIND 8 embedded in it, and even though you weren't running a DNS server on it, it would still flag as a vulnerability (No version of BIND 8 was considered secure, you had to use 9... but you didn't want to install 9 unless you were running a DNS server...what a great circular arguments were had over this), and if you got a new guy doing the STIG, you had to educate him all over about it.

Slightly OT, but one of the current issues that the US DoD faces, is that NIPRnet was supposed to be an administrative, non mission critical network, that has evolved into something more, but hasn't been protected like it needs to be. You can't just put its functions on a classified network, because the date simply is important or sensitive, but not classified. (You realize this when you have to get an UNCLASS downtime, and you get more push back on it, than you do on "other" networks, because some yahoo in the command center doesn't want be deprived of his sports score updates).

And the other age old problem is there isn't an admin out there that isn't fighting to get enough time to keep everything up to date (if there is, they're department is in danger of being downsized), and dealing with all the other day to day problems.

Good Luck

Arch Linux (1)

NaNO2x (856759) | more than 5 years ago | (#28788723)

I'd recommend checking out Arch, it is a bleeding edge distro that also makes recompilation quite easy. There are a lot of smart people working on it and the documentation is quite good. Arch follows the KISS principle and keeps their repositories fairly light while letting the community handle the masses of programs.

Anyway, I recommend checking it out here: http://www.archlinux.org/ [archlinux.org]

Submit a Waiver (1)

vldragon (981127) | more than 5 years ago | (#28788825)

When working for the DoD, no matter what you problem is the their is a waiver process for it. If anything it will give you more time to figure out a solution.

Obey the rules. (1, Funny)

irregular_hero (444800) | more than 5 years ago | (#28788889)

First rule about DoD security and stability? Don't talk about DoD security and stability. :>

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?