×

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!

Using OpenBSD's chrooted Apache

Hemos posted about 11 years ago | from the learning-what-to-do dept.

Operating Systems 101

BSD Forums writes "OpenBSD recently changed the mode of operation for the Apache webserver from the normal non-chrooted operation to chrooted operation. This enhances the security of the server on which Apache is run but it imposes a few challenges to the system administrator. In this article Marc Balmer discusses selected aspects of running a chrooted HTTP daemon and present strategies on how to set up a chrooted environment for more complex applications like database access or using CGI-scripts."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

101 comments

Frost post! (-1, Offtopic)

Anonymous Coward | about 11 years ago | (#5678140)

F!rst p0st 37337!!!!

Re:Frost post! (-1, Offtopic)

Anonymous Coward | about 11 years ago | (#5678167)

"37337" ?

Dude, you are so not 31337! :)

YOU FAIL IT!! (-1, Offtopic)

Anonymous Coward | about 11 years ago | (#5678169)

ur b0x is 0wnz0r3d!
ur a looser!

fp!@ (-1, Offtopic)

Anonymous Coward | about 11 years ago | (#5678141)

shoutz to the gcs crew! --sq

Challenges? (0, Flamebait)

Anonymous Coward | about 11 years ago | (#5678144)

Challenges for the system administrator? Look, each day, billions of people are starving to death worldwide, and Slashdot has an article about the challenge of chrooting a web server or something. Way to go.

All those dead children have you to blame, Taco.

Re:Challenges? (0)

Anonymous Coward | about 11 years ago | (#5678204)

Yeah, we should just sit back and do nothing and die, just to feel sorry for those others, right?

Re:Challenges? (1)

Pholostan (79534) | about 11 years ago | (#5680044)

No, you should offer your body to be eaten by them. You die, but they live.

Just kidding. It is interesting though, that people die very day who most really wants to live, but are unable to do anything to survive. All those people willing to live, while I have practically everything but can't get out of bed in the morning, mutch less summon any will to live. Ironic.

Slashdotness... (1)

st0rmcold (614019) | about 11 years ago | (#5678145)


My peave with pdf's is the size, slashdotted in 15secs instead of 45secs.

Dramatic in the slashdot community.

recently? (1)

jdew (644405) | about 11 years ago | (#5678149)

this was done with the introduction of 3.2. 3.3 will be out shortly. As in May 1st. ._.

Security v. ease of use (3, Insightful)

unterderbrucke (628741) | about 11 years ago | (#5678153)

Security should always win, but it never does.

Just my .02 cents.

Re:Security v. ease of use (0)

Anonymous Coward | about 11 years ago | (#5678251)

Above post moderated as troll? Come on, guys..

Anyways, I agree with your statement, but enhancing security is always a good thingie. I doubt that the OpenBSD crew claims that this apache patch is the ultimate security solution, but I'm pretty sure they think it's more secure than what's default.

The guys behind OpenBSD are SERIOUSLY GOOD programmers who really know what they're doing!

Re:Security v. ease of use (0)

Anonymous Coward | about 11 years ago | (#5679049)

"The guys behind OpenBSD are SERIOUSLY GOOD programmers who really know what they're doing!"

Yea with regards to security. At the same time the rest of the distro suffers with zero effort put into ease of use.

Who cares if its the most secure thing going if it takes a genius to operate it? Most people would be better off using Red Hat and selecting "High Security".

Until one/any of the BSD's actually makes an effort to cater to someone else besides the snobbish elite users it caters to now, it will continue to miss out will linux will continue to dominate it.

You bsd users are always saying how much better bsd it compared to linux, but do nothing to try to compete. Maybe its the fear that if you make easier to use someone will just steal your work and redistribute it?

There is more to modern computing then just being secure or stable.

Re:Security v. ease of use (1)

0ptix (649734) | about 11 years ago | (#5679336)

just migrating from linux -> openbsd and all i have to say is: cd /usr/ports/bla/foo make install or maybe just pkg_add foo.tgz i dont know. doesnt get much easier then that. i think its just a matter of what one is familier with. about the only complaint i have with (open)bsd so far is the instalation (mainly the formating of the HD was not intuitive). that really is kinda crude, but apart from that.... not so evil really. but please correct me if i am wrong. lets have examples mind you... not just vague complaints or comments... after all i do wanna learn! :-) (actualy i am just trying to decided between a grsecurity enhanced linux box and an openbsd box for a secure firewall, gateway and webserver... so this is pretty relevant. the point is it should be maintainable by a nonexpert as well once setup properly...)

Re:Security v. ease of use (0)

Anonymous Coward | about 11 years ago | (#5679340)

http://www.openbsd.org/goals.html

There is nothing on there about ease of use or competing with Linux or replacing any other system.

"Maybe its the fear that if you make easier to use someone will just steal your work and redistribute it?"

There is no need to steal it. That is one of the great parts of FREE software.

Re:Security v. ease of use (2, Insightful)

Ruzty (46204) | about 11 years ago | (#5679345)

Competing is the not the goal. The goal is a highly secure OS capable of doing everything the development team and core user base want it to do. Having others able and desiring to use OpenBSD is a secondary concern driven by a need for funding to continue development.

OpenBSD does not cater to "Joe User" nor does it claim to. You are correct, Joe User should be using something that gives more direction and simplifies their experience such as RedHat.
-Rusty

Re:Security v. ease of use (1)

mivok (621790) | about 11 years ago | (#5678790)

Now I'd have thought that in this case, it is security that is winning out over the ease of use of having older httpd.conf files work.

Re:Security v. ease of use (1)

baywulf (214371) | about 11 years ago | (#5678874)

"Security should always win, but it never does."

If that were really true then why don't you shut down you computer? It would certainly make it much more secure at the expense of ease of use?!

Re:Security v. ease of use (0)

Anonymous Coward | about 11 years ago | (#5679667)

If that were really true then why don't you shut down you computer? It would certainly make it much more secure at the expense of ease of use?!

You're confusing "ease of use" with "use".

For any given project, you need strict goals to guide your decision making process. "we will have apache in tree, it will be capable of doing cgi, virtualhosts, etc. We will have strong security.". Implement that but it gets more confusing to admin correctly, other OS's might say "ok, forget security", OpenBSD says "ok, forget admins unwilling to Work and Learn".

Re:Security v. ease of use (1)

Marillion (33728) | about 11 years ago | (#5679084)

I agree with that right up to the point where the difficulty in use prevents an administrator from doing the right thing.
Security should be easy to implement and difficult to circumvent.

Re:Security v. ease of use (1)

ClayDowling (629804) | about 11 years ago | (#5679285)

Security is important and all, but the choice between security and usability isn't an absolute. The greatest security for my web site would be to burn it onto a CD and chroot the server to that CD. That's not practical though when I'm using the website to demonstrate and sell content management systems. So I need to compromise my security a bit to allow the server and the CGI programs that it spawns to write to certain files or directories. It's less secure than my burned-on-a-cd option, but fits my needs better.

KNOWN OUTWAR POSTER! MOD PARENT DOWN!! (0)

Anonymous Coward | about 11 years ago | (#5679505)

Re:Security v. ease of use (1)

chrisseaton (573490) | about 11 years ago | (#5680408)

"Just my .02 cents."

That's not a lot of cents. I really love it when people go as far as to put

"Just my USD $0.02"

Wankers.

site is /.'ed (2, Informative)

rf0 (159958) | about 11 years ago | (#5678171)

So as I can't comment on the article itself I thought that it might be mentioning that chroots are good but no infalliable. If someone can get root permission inside a chroot you can break out [bpfh.net]

Rus

Re:site is /.'ed (5, Informative)

jolan (187075) | about 11 years ago | (#5678265)

Yes, if someone gets root, then they can most likely break out of chroot.

Thankfully, under OpenBSD even the apache parent process does not run as root:

www 2376 0.0 0.3 1120 1440 ?? Ss Wed08PM 0:05.56 httpd: parent [chroot /var/www] (httpd)
www 12097 0.0 0.2 1196 1008 ?? I Wed08PM 0:00.02 httpd: child (httpd)

This means "remote root exploit" in Apache becomes "remote www-user-in-chroot exploit" for OpenBSD.

It's a very nice feature. I wrote a document on how to get CVSWeb running within the Apache chroot environment recently. I'm guessing Marc's paper is somewhat similar in nature.

http://marc.theaimsgroup.com/?l=openbsd-misc&m=1 04 900672827459

Re:site is /.'ed (0)

Anonymous Coward | about 11 years ago | (#5678314)

What do you have to do to get Apache's parent to drop root if you're not fortunate enough to be running OpenBSD? I always wondered what it's doing with those permissions once it's already started up and bound the privileged port.

Re:site is /.'ed (1)

tdemark (512406) | about 11 years ago | (#5678341)

Set the 'User' config param to a non-root user:

User apache
Group apache

Apache will bind as root and then drop privs to the named user.

Re:site is /.'ed (3, Informative)

Anonymous Coward | about 11 years ago | (#5678412)

Apache will bind as root and then drop privs to the named user.

No, it won't. Build it from source, put that in the config, start it as root, and look again. The parent is still running as root.

root 1040 0.0 0.2 2644 156 ? S 2002 0:00 /usr/local/apache/bin/httpd

It needs to bind port 80. OK, so bind the port and then drop privs. It needs to control the logs so that the evil children don't touch it. OK, so change to a different user (other than the network-listeners). Anything but root!

I realize there are other uses for root in Apache. Maybe you want to play games with running CGI programs as different users. That's all well and good, but that's still no reason to default to running as root.

Don't think Apache's priv-sep situation is perfectly sound, either. There was an odd little hole last year that let the unprivileged children whack arbitrary processes with SIGUSR1 through their privileged parent. No root = fewer worries.

Re:site is /.'ed (1)

tzanger (1575) | about 11 years ago | (#5678852)

If someone can get root permission inside a chroot you can break out [bpfh.net]

Sure, but then again who in their right mind runs a web browser, ftp server, cvs site, news server, name server or practically any server as root anymore?

Breaking a Chroot (3, Informative)

elemur (7613) | about 11 years ago | (#5679237)

I couldn't say if it protects against the exact source code listed on that site, but there is a set of kernel security modules which *greatly* protects against these sorts of attacks. The modules are at http://www.grsecurity.org/, and are a wonderful addition to any linux server.

It protects against raw devices, special chroot attacks, UID escalation attacks, many buffer overflows, and other problems. In addition, it adds a whole ACL (Access Control List) system for protecting applications and the overall environment. For a full list of features go to http://www.grsecurity.org/features.php.

I've used this on many different servers with no problems at all. It certainly make you feel better on those servers directly connected to the net.

Re:site is /.'ed (1)

Ded Bob (67043) | about 11 years ago | (#5679346)

The site reports that the code to break out works on Solaris and Linux. No mention is made of OpenBSD. It does say that FreeBSD is not vulnerable to the attack.

Hey - you guys broke my httpd.conf file! (5, Interesting)

dragonfly_blue (101697) | about 11 years ago | (#5678176)

I admittedly hadn't been paying much attention to the changes, but this one crept up and bit me on the ass last week while I was setting some new web servers for our ISP.

It seems the chrooted Apache configuration in 3.2 is turned on by default, and it prevents cgi mappings from working properly under VirtualHosts directives. I was kind of aggravated; it took a while to figure out what was wrong.

It's documented in the OpenBSD FAQ [openbsd.org] , but I couldn't pinpoint the problem to OpenBSD specifically (and the error log was mysteriously unhelpful at diagnosing the problem), so I spent quite a while reading up on Apache directives before I figured it out.

It was frustrating, but I know Apache considerably better now, so I guess it was worth it. I agree that security is very admirable, which is why I use OpenBSD in the first place, but I think certain options should be turned off by default, especially if they break common services like VirtualHosts cgi ScriptAliases.

Realistically, are most web servers going to be set up just to host one web site? Or am I the only one who uses VirtualHosts on most of my servers?

Re:Hey - you guys broke my httpd.conf file! (1)

rf0 (159958) | about 11 years ago | (#5678201)

I use virtualhosts a lot. Due to the relativtly scarce number of IP addresses left people like Arin and RIPE aren't that happy about issues a unique IP address for each site. The only time you really need it is if you are using SSL

Rus

Re:Hey - you guys broke my httpd.conf file! (4, Informative)

ostiguy (63618) | about 11 years ago | (#5678223)

Honestly, this is one of the most touted changes to OpenBSD 3.2 - it was absolutely everywhere on the misc@ list, it is in the FAQ, it is the #3 bullet point under the "What's New" page for the 3.2 release. There is really no excuse for not knowing it was coming, and thus knowing it would be a likely reason for old configs to not work

ostiguy

Re:Hey - you guys broke my httpd.conf file! (1)

dolmant_php (461584) | about 11 years ago | (#5681093)

There's also a fairly obvious comment in rc.conf:
# use -u to disable chroot, see httpd(8)
httpd_flags=NO # for normal use: "" (or "-DSSL" after reading ssl(8))

Re:Hey - you guys broke my httpd.conf file! (1)

pkplex (535744) | about 11 years ago | (#5678273)

I installed my first public OpenBSD server yesterday :) Never gave thought to the VirtualHosts side of it, I would imagine its straight forward to impliment though.. a bit of re-partitioning and re-mountage I guess.

What I really wanted to say though, Is that I like OpenBSD very muchly :) Anyone interested in a quality, clean, correct, warm and fuzzy OS should try OpenBSD. It kicks ass.

Re:Hey - you guys broke my httpd.conf file! (2, Funny)

psxndc (105904) | about 11 years ago | (#5678392)

but I think certain options should be turned off by default

If you want a web server that has security features disabled by default, there are other options [microsoft.com] .

;-P

psxndc

Re:Hey - you guys broke my httpd.conf file! (0)

Anonymous Coward | about 11 years ago | (#5680191)

I think certain options should be turned off by default

It takes two characters to turn it off.

Defaults should be set for the majority of users. If the majority of users don't use VirtualHosts (probably), why should their security be lowered by default for the few of you that do?

Marc's Bro (3, Funny)

Anonymous Coward | about 11 years ago | (#5678216)

Marc must be such a disappointment to his big brother Steve...

Or kid (0)

Anonymous Coward | about 11 years ago | (#5678348)

I was thinking maybe that was Steve's rebellious teenage son, trying to spite his old man like so many kids do.

*BSD is dying (-1, Offtopic)

Anonymous Coward | about 11 years ago | (#5678225)

It is official; Netcraft now confirms: *BSD is dying

One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last [samag.com] in the recent Sys Admin comprehensive networking test.

You don't need to be a Kreskin [amazingkreskin.com] to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.

FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.

Let's keep to the facts and look at the numbers.

OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.

All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.

Fact: *BSD is dying

Re:*BSD is dying (-1, Flamebait)

Anonymous Coward | about 11 years ago | (#5678298)

...and so are you - care to place a bet as to which holds out longer?

Re:*BSD is dying (1, Insightful)

usotsuki (530037) | about 11 years ago | (#5678695)

Opinion: BSD is dying

Let's put it this way, BSD will not die as long as MacOS X exists. Plus note, it's not about the market share if you can grok the source code!

-uso.
BSD r0x0r!

(Yeah, I know, I'm -1 Offtopic.)

Are *you* a Microsoft Zealot? (-1, Troll)

Anonymous Coward | about 11 years ago | (#5678245)

If you are, thank you for spending your money on inferior software which will be totally useless in two years. Over here at redmond, we thank you and we hope you'll keep up the zealotry.

Without your support our company would be dead.

Steve.

I would have liked to read the document... (1)

HogGeek (456673) | about 11 years ago | (#5678272)

But due to the really slow down load, and then then file being corrupt (according to my pdf reader).

I'm not trying again...

This is not a good example to follow (-1, Offtopic)

Anonymous Coward | about 11 years ago | (#5678307)

Hello,

Recently I've been introduced to an operating system known as Linux.

Lured by its low cost, I replaced Windows 98 on my computer with Linux. Unfortunately the more I use it the more I fear that this "Linux" may be an insidious way for the Dark One to gain a stronger foothold here on Earth. I know this may be a shocking claim, but I have evidence to back it up!

To begin with, Linux is based off of an older, obsolete OS called "BSD Unix". The child-indoctrinatingly-cute cartoon mascot of this OS is a devil holding a pitchfork. This OS -- and its Linux offspring -- extensively use what are unsettingly called "daemons" (which is how Pagans write "demon" -- they are notoriously poor spellers: magick, vampyre, etc.) which is a program that hides in the background, doing things without the user's notice. If you are using a computer running Linux then you probably have these "demons" on your computer, hardly something a good Christian would want! Furthermore in order to start or stop these "demons" a user must execute a command called "finger". By "fingering" a "demon" one excercises an unholy power, much the same way that the Lord of Flies controls his black minions.

Linux contains another Satanic holdover from the "BSD Unix" OS mentioned above; to open up certain locked files one has to run a program much like the DOS prompt in Microsoft Windows and type in a secret code: "chmod 666". What other horrors lurk in this thing?

Consider some of these other Linux commands: "sleep", "mount", "unzip", "strip" and "touch". All highly suggestive in a sexual nature. I know that our Lord cannot approve of these, and I urge them to be renamed to something appropriate to the Christian community. Interestingly "CONTROL-G" (the sixth key from the left of the keyboard) does an abort. To write files a "VI" editor is included. All these are to ensnare the unsuspecting christian who could get tempted by typing "VIVIVI" all day long.

Fourth, Linux uses a flavor of DOS known as Bash. Bash is an acronym for "Bourne Again Shell". On the surface this would appear to be supportive of the Lord. However, remember that even Satan can quote the bible for his own purposes! While I believe Linux may be born-again, its obvious by the misspelling of "born" that its not born-again in an Christian church. Will the lies ever cease?

Additionally, one of the main long-haired hippies involved with the GNU Free Software Foundation supports communism, contraception and abortion. He has consistently supported 60's counter-cultural "values", and his web site even advocates government support of contraception. He also wears fake halos, and has quips about his made-up church that relates to his free software. I find such blasphemy to be extremely unsettling.

One must also remember that the creator of Linux, a college student named Linux Torvaldis, comes from Finland. I'm sure all the followers of Christ are aware of the heritical nature of the Finnish: from necrophilia to human sacrifice, Finnish culture is awash in sin. I find little reason to believe anything good and holy could arise from this evil land.

Finally, let us remember that there is an alternative to using the Satan-powered Linux. I think history has shown us that Microsoft is quite holy. I'm told that its founder, William Gates is a strong supporter of our Lord and I encourage my fellow Christians to buy only his products to help keep the Devil at bay.

I wish I had more time to expound upon my findings. Unfortunately a family of Jews has moved in across the street and I must go speak to them of Jesus Christ before they are condemned to eternal hellfire.

Please investigate this as you see fit and I'm sure you'll reach the same conclusions that I have.

Developer laments: What Killed FreeBSD (-1)

Anonymous Coward | about 11 years ago | (#5678312)

The End of FreeBSD

[ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]

When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.

Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.

FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.

It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.

So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.

Discussion

I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.

From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.

There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.

Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.

Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?

Shouts

To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.

To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. It's when you get distracted by the politickers that they sideline you. The tireless work that you perform keeping the system clean and building is what provides the platform for the obsessives and the prima donnas to have their moments in the sun. In the end, we need you all; in order to go forwards we must first avoid going backwards.

To the paranoid conspiracy theorists - yes, I work for Apple too. No, my resignation wasn't on Steve's direct orders, or in any way related to work I'm doing, may do, may not do, or indeed what was in the tea I had at lunchtime today. It's about real problems that the project faces, real problems that the project has brought upon itself. You can't escape them by inventing excuses about outside influence, the problem stems from within.

To the politically obsessed - give it a break, if you can. No, the project isn't a lemonade stand anymore, but it's not a world-spanning corporate juggernaut either and some of the more grandiose visions going around are in need of a solid dose of reality. Keep it simple, stupid.

To the grandstanders, the prima donnas, and anyone that thinks that they can hold the project to ransom for their own agenda - give it a break, if you can. When the current core were elected, we took a conscious stand against vigorous sanctions, and some of you have exploited that. A new core is going to have to decide whether to repeat this mistake or get tough. I hope they learn from our errors.

Future

I started work on FreeBSD because it was fun. If I'm going to continue, it has to be fun again. There are things I still feel obligated to do, and with any luck I'll find the time to meet those obligations.

However I don't feel an obligation to get involved in the political mess the project is in right now. I tried, I burnt out. I don't feel that my efforts were worthwhile. So I won't be standing for election, I won't be shouting from the sidelines, and I probably won't vote in the next round of ballots.

You could say I'm packing up my toys. I'm not going home just yet, but I'm not going to play unless you can work out how to make the project somewhere fun to be again.

= Mike

--

To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt

Recently ? (4, Informative)

dnaumov (453672) | about 11 years ago | (#5678330)

This isn't exactly a recent change, I believe this happened over 6 months ago...

Apache 2 (1)

zmcgrew (265718) | about 11 years ago | (#5678413)

I kept the chrooted Apache availible, I just don't ever start it or use it.
Instead, I installed Apache 2.
But considering I'm not doing any mission critical stuff -- I'm really not too worried.
Perhaps all I have to worry about now is getting the speed of my CGI scripts up... But maybe that's just because they're running on a Pentium 100. =)

Rock on OpenBSD!

Performance hit? (2, Interesting)

mnmn (145599) | about 11 years ago | (#5678426)


I wonder if this inflicts a performance hit, or more memory is required as a result. I know more disk space is needed, but with the smallest IDEs these days being 40GB, I'm not worried there.

If theres really no performance hit, I wonder if all daemons can be run in seperate chroots, indeed could an inetd be developed that chroots all its daemons. Necessary readonly stuff like libc might be hard-linked rather than copied to save space, unless that would be too much of a security breach.

My very-lazily setup FreeBSD server never gave me problems, and I wouldnt be implementing this in my production server yet, but its nice to HAVE DONE stuff like this to:
(1) boast
(2) print on resume
(3) profit!

Re:Performance hit? (3, Informative)

QuMa (19440) | about 11 years ago | (#5678776)

This is where linux bind mounts come in handy, you can bind mount your /lib and /usr/lib into all your chroots (just make sure they don't contain suids or anything :) ), that way all libraries will only go into memory once, even when used from multiple chroots. (of course you can olso have all your fake roots on the same filesystem and hardlink, but this is a lot nicer)

Re:Performance hit? (1)

stab (26928) | about 11 years ago | (#5679741)

The OpenBSD Apache chroot()s after its been run, so it loads all the libraries and modules as normal; no need for fancy mounts or copying libraries into the chroot.

Re:Performance hit? (2, Informative)

Skapare (16644) | about 11 years ago | (#5680051)

Even bind mounts are not secure. They can be remounted read/write, assuming they were read-only to begin with. One way to be sure that can't happen is to have the filesystem so mounted be a loopback to a file which resides on a filesystem which is mounted read/only. That underlying filesystem cannot be changed from inside the chroot (because there is no mount point therein to reference it), so even if the loopback mounted filesystem is made read/write, write attempts should ultimately fail (but even this could be exposed by a bug I don't know about, if one exists).

Modular programming (and dynamically loaded libraries are a form of modularity) just doesn't mix well with security.

Re:Performance hit? (1)

QuMa (19440) | about 11 years ago | (#5680720)

If the attacker has root you're dead anyway,
mkdir foo; chroot foo; cd ..

Running it chrooted isnt allways a useful option. (2)

geesus (545118) | about 11 years ago | (#5678477)

At home I run the chrooted version under 3.2, and it would be good for doing a standalone, non cgi single site delio. when you start to add more vhosts and what not, you have to make sure that they are in the chroot as well. this isnt allways desireable, especially from an ISP point of view for customers sites, most ISP's I know keep thier customers sites in ~/public_html/ . But it just goes to show that openbsd's whole secure by default persona is in effect.

Broken chroot implementation? (0)

Anonymous Coward | about 11 years ago | (#5678487)

Hi guys.

Just wondering, it seems the OBSD chroot implementation can be broken out of.

I first noticed it here. [grsecurity.net]

And the concept code, which is pretty standard, is here. [grsecurity.net]

Please explain!

Re:Broken chroot implementation? (0)

Anonymous Coward | about 11 years ago | (#5678677)

what a [i][b]secure[/b][/i] os!

Re:Broken chroot implementation? (1)

Skapare (16644) | about 11 years ago | (#5679963)

There are certain things that have to work inside chroot for it to remain usable for the things it was originally designed for, which includes building new systems. Those things that are designed to fail (e.g. pass the test) in grsecurity's system, which fail the test (e.g. the code still works) on the others, are needed for many use that chroot is used for. For example you can't make a new system without being able to use mknod and use the device made in that run. And that's a capability which can be abused.

The problem is people are trying to take something that seems like it might have been intended for security (chroot), which never was, and trying to impose on it a more complete set of semantics that would force it to be usable for security, breaking the original purpose. Instead, what should be done is create an entirely new tool. FreeBSD has the jail feature which is a sort of "chroot on steroids". And Linux has "User Mode Linux" which allows running a whole kernel in user process space.

My point is, chroot was never intended to be secure. Shame on those who ever expected it to be so.

Why BSD? (2, Insightful)

Anonymous Coward | about 11 years ago | (#5678531)

(No this isn't a lame BSD troll). Chrooted Apache might be the default on OpenBSD, but this is still information everybody can use. However, judging by the number of posts, as soon you label it 'BSD' it seems most of the (probably Linux-centric) Slashdot readers eyes glaze over, and they never read it (or they post several copies of the 'BSD is dying troll..)

Yes, it is their loss -- but generally applicable topics that just happen to be demonstrated on a BSD really should not be tagged 'BSD' in the Slashdot topic heading IMHO. They should be tagged according to the topic (Say, Apache, in this case).

Re:Why BSD? (2, Informative)

Nickus (10876) | about 11 years ago | (#5678873)

AFAIK this is not information everybody can use since this feature only exists on OpenBSD. Apache is patched to chroot() to it's own folder. The -u flag does not exist on standard Apache [apache.org] .

*BSD is dying (-1)

Anonymous Coward | about 11 years ago | (#5678575)

It is official; Netcraft now confirms: *BSD is dying

One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a mere fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last [samag.com] in the recent Sys Admin comprehensive networking test.

You don't need to be a Kreskin [amazingkreskin.com] to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.

FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.

Let's keep to the facts and look at the numbers.

OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.

All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.

Fact: *BSD is dying

Does anyone have a bittorrent of the pdf? (2, Insightful)

Idimmu Xul (204345) | about 11 years ago | (#5678588)

Doing something like this in future as standard could conciderably reduce the /. effect!

MOD PARENT UP!!! (-1)

Anonymous Coward | about 11 years ago | (#5678745)

HERE HERE!

openBSD features (2, Funny)

pzilla (530382) | about 11 years ago | (#5678629)

Neat! I hope FreeBSD and NetBSD use this feature when they all merge [slashdot.org] .

Looking forward to it. ;)

Why don't the various Linux Dists... (4, Interesting)

Greyfox (87712) | about 11 years ago | (#5678780)

I've always wondered why the various linux dists don't contain -chroot packages of the various servers that support the chroot environment. Running that way would at least make it a bit more difficult to compromise your system when those inevitable remote exploits are found. If you package them separately, the administrator could choose which ones to run (Though that's not always a good thing.)

Re:Why don't the various Linux Dists... (1)

jdew (644405) | about 11 years ago | (#5678894)

Same deal with propolice really..

from what im told:
gentoo comes with propolice, but its turned off by default "because some things break"

in openbsd 3.3, propolice is turned on by default "because some things break"

=D

Re:Why don't the various Linux Dists... (1)

Dausha (546002) | about 11 years ago | (#5679221)

Sounds like we need to create a distribution called 'OpenLinux' . . .

Re:Why don't the various Linux Dists... (1)

the-dude-man (629634) | about 11 years ago | (#5680759)

Well alot of the various linux distros really blow hard.

The only one that dosnt, is gentoo. Its actually on a pretty level playingfield as freeBSD.

Gentoo uses the ports collection, so you can get your chrooted packages off of there. But alot of times they dont run chrooted by default. This is changing at a good rate (in gentoo at least). When i do an overnight emerge, when i merge in etc-update i am finding that my chroot config directives are getting overwritten by the new config data more and more now.

But then agian, if you install a service avialable to the world, and just go with the default configureation without at least checking to make sure its good.....you deserve what you get :)

Re:Why don't the various Linux Dists... (0)

Anonymous Coward | about 11 years ago | (#5682070)

I've always wondered why the various linux dists don't contain -chroot packages of the various servers that support the chroot environment.



Linux distributions aren't designed to be secure by default. Most Linux distributions are focused on being easy to use (a mistake, IMNHSO).

The myth of chroot security (1)

Python (1141) | about 11 years ago | (#5682467)

Aside from all the very valid reasons everyone else has pointed out as to why various distributions do not chroot more services, there is one more: chroots, on many OSes (OpenBSD, Solaris, FreeBSD and default Linux kernels) are actually not that hard to escape from. With this in mind, some may consider chroots to have marginal value at best and at worst, they can create a false sense of security.

For instance, there are several ways to get out of a chrooted environment that have been known for years. Futhermore, the means to correct many of these problems has also been known and available in patch form for years. Yet, all of the afore mentioned UNIXes have failed to make these fixes part of their vanilla kernel trees. Thankfully, there are external patches that fix these problems for some OSes (Linux for instance), but they are not fixed in the default kernels of many distributions, including OpenBSD 3.2, Solaris, FreeBSD and Linux. Here is just a partial list of the known ways of escaping or circumventing a chroot:

double chroot
fchdir
Attaching to shared memory outside of the chroot, that can be fun.
mknod (Oh boy! Make whatever you want inside the chroot!)
And of course, Raw I/O. Nothing stops you from doing that in a chrooted environment.

So, before you assume that chrooting something will add X amount of security to your system, understand that most kernels (Solaris, BSD and Linux) allow for many widely known ways of escaping a chrooted environment and even making the chroot environment irrelevant by still affording an attacker too much control over the box.

Its still admirable to see more services being configured to run in a chrooted environment, but until more kernels are modified to make chroots stronger and to close these holes, the security they create can just be an illusion at best. I'm not advocating that services not be chrooted, but rather that OSes fix many of these issues and that users understand the limitations of chroots as a security tool until that happens.

They do (1)

leonbrooks (8043) | about 11 years ago | (#5691361)

I've always wondered why the various linux dists don't contain -chroot packages of the various servers that support the chroot environment.

Mandrake have begun to.

huh huh huh (0)

Anonymous Coward | about 11 years ago | (#5678797)

you said... root

Elegy for *BSD (-1, Troll)

Anonymous Coward | about 11 years ago | (#5679102)


Elegy For *BSD


I am a *BSD user
and I try hard to be brave
That is a tall order
*BSD's foot is in the grave.

I tap at my toy keyboard
and whistle a happy tune
but keeping happy's so hard,
*BSD died so soon.

Each day I wake and softly sob
Nightfall finds me crying
Not only am I a zit faced slob
but *BSD is dying.

TH30 DE R@@DT IZ A L33CH!!! (-1, Troll)

Anonymous Coward | about 11 years ago | (#5679455)

WHEN HAVE U EVA HEARD OF OPENBSD contributing TO THE OSS COMMUNITY. TH3Y L33CH3d NETBSD CODE, THEN THEY L33CH3D GNU CODE. BUT NEVER GAVE NE THING BACK!!

BOYCOTT OPENBSD...IF ONLY BECAUSE TH30 IS AN A$$H0L3!!!!!!

--
jk;asdjf kjk;jiup kl;jiopu kjiou jasdf uipukl;j
jk;jiu uiu jk;jio jklasdf y k uipyu kl;iu j ;kla
asdf pu k;lui l; iou jkl; uipo adf iu m,.mk uip u
jiopu jkkuip u/,mou asdf uipkluip ;kuiop

Why is there an "Apache" user? (3, Interesting)

mcrbids (148650) | about 11 years ago | (#5679503)

The basic problem isn't that Apache runs as "userX" or "userY" or even "root", it's that it ONLY runs as user "apache"!

If I have 100 clients using a web server, there's no way for me to protect their stuff from each other. NONE.

It doesn't matter what permissions I apply. I can run PHP in "safe" mode, and apply bandaids to the problem to mitigate this weakness, but it's still there.

Maybe make apache run under xinet.d. (Gee, there goes the "must run as root" problem!) Maybe just have a connection process that connects to an actual daemon for performance reasons.

But Apache should run as the user that owns the site being accessed!

Imagine this in your httpd.conf:

<VirtualHost *>
ServerName www.clientsite.com
ServerAlias clientsite.com
DocumentRoot ~client/html
RunAsUser client ... logging, etc.
</VirtualHost>

If done right, you should be able to chroot user "client" and have the DocumentRoot be relative within the chrooted file system!

This is a feature of 2.x that is the *only* feature I'm looking forward to. And yet, for some reason, it's on the back burner. It's "unstable", or "in progress". In short, it still sucks.

So we continue to run in an inherently lame-brained environment with security leaks all over the place, with this "unpriveledged user" (typically "nobody") that has more permissions than any other user save root.

Ugh.

Re:Why is there an "Apache" user? (1)

larien (5608) | about 11 years ago | (#5679579)

Yes, it would be very nice but very difficult to implement given Apache's model and how that runs under Unix.

Essentially, by the time you've figured out which vhost the client is requesting, you're bound to a specific httpd process which normally runs as www/nobody or whatever you've configured it as. As those users cannot setuid to the RunAsUser, you can't modify the uid/euid at that stage, only root can do that and you don't want root handling that part of the negotiation!

The alternative is to run with different config files binding to different IPs or ports and run multiple versions of Apache at the same time, but that loses you some advantages of load balancing between virtual hosts.

Something like a proper trusted base allowing a user (www) to setuid to other users (vhost1, vhost1 etc) but that requires a version of Unix that supports it; dunno if Trusted Solaris, OpenBSD or SELinux supply that functionality or not.

Re:Why is there an "Apache" user? (3, Informative)

cras (91254) | about 11 years ago | (#5680168)

Essentially, by the time you've figured out which vhost the client is requesting, you're bound to a specific httpd process which normally runs as www/nobody or whatever you've configured it as. As those users cannot setuid to the RunAsUser, you can't modify the uid/euid at that stage, only root can do that and you don't want root handling that part of the negotiation!

You use multiple processes then. You can pass the socket file descriptor to another process via UNIX sockets. Or you could just keep proxying the connection to another process if you want portability.

For example you could have a few "connection broker" processes which would parse the initial request. That process would figure out who exactly should be handling the request. Once that's done, it sends very simple request to very small master process which runs as root, consisting of wanted url handler (file, directory, whatever). The root running process verifies the handler is valid, and then either returns error or forwards the connection to the actual handler process (either exec + setuid(), or reuse existing process).

Something like a proper trusted base allowing a user (www) to setuid to other users (vhost1, vhost1 etc) but that requires a version of Unix that supports it; dunno if Trusted Solaris, OpenBSD or SELinux supply that functionality or not.

There's at least kchuid [nimh.org] which could do that.

Re:Why is there an "Apache" user? (1)

mcrbids (148650) | about 11 years ago | (#5682316)

I see a number of comments in this thread.

Anybody who says "it can't be done" is simply wrong. It can obviously be done, in a number of ways, with minimal repurcussions.

I'd almost give a left nut for something like this that actually worked.

So why hasn't it been done?

Re:Why is there an "Apache" user? (1)

cras (91254) | about 11 years ago | (#5682432)

So why hasn't it been done?

Want to pay for it? ;) I've thought a few times that this would be interesting to do, but I already have other projects and I don't actually need it.


Re:Why is there an "Apache" user? (0)

Anonymous Coward | about 11 years ago | (#5683915)

I'd almost give a left nut for something like this that actually worked

Depending on your definition of "work", it's exactly what IIS does.

WRT running as root, solution is easy (1)

leonbrooks (8043) | about 11 years ago | (#5691327)

Bind Apache to (say) port 8765 and NAT the incoming connections from port 80 to there.

And for an encore?

Change your user skeleton so public_html becomes a link to /var/www/users/$USERNAME (which useradd or whatever makes), add a group called ap_$USERNAME with each new user, add Apache to the group and chown said directory to $USERNAME:ap_$USERNAME and chmod it g+rx and make it sticky. Don't give Apache write access to anything. You still have a few issues left (if ap_$USERNAME isn't the users' default group, for example), but most of your problems are pushing up daisies. A bit cumbersome for a squillion users, but bearable for up to a few hundred.

Re:Why is there an "Apache" user? (1)

Skapare (16644) | about 11 years ago | (#5679891)

I've always set up Apache so CGI runs as the user who owns the site. The problem is, that requires retaining the permission to switch to that user somewhere, even if just within the "suexec" file (is suid root).

The problem with Apache is that it is so large, and so much code would run as root, that it is unsafe to allow that. So the usual course is to run Apache non-root, and let "suexec" do the permission switch. Supposedly it can verify if it is being run correctly from the Apache process (as opposed to from any other) by means of a passed random number it can read from a file only Apache could write. But I never have really verified how that works, and shame on me for not doing so.

At some point we just have to trust some code to do the right thing with the permissions granted to it. I for one can't grant that trust without being able to read and understand the code. And Apache is just too much for that.

Perhaps the whole model of a multi-user shared daemon is all wrong. Maybe users should have to each run their own instance of Apache on separate IP addresses (they have to if they want to run an HTTPS secured web site, anyway).

Re:Why is there an "Apache" user? (1)

thx2001r (635969) | about 11 years ago | (#5681613)

Maybe users should have to each run their own instance of Apache on separate IP addresses (they have to if they want to run an HTTPS secured web site, anyway).

Of course, this negates the whole point of IPv4 address conservation that name-based virtual hosts afford.

What if you could do name-based virtual hosting with each user running their own instance of Apache (using a single IP for Port 80 virtual hosts (machine-wide), which is probably most of what is on the server anyhow)? Port 443 virtual hosts will need their own IPs anyhow.

Anyone know if that's doable, and if so, how?

Of course, the other option is to run all web sites as "users" (http://yoursite.net/~username/) instead of virtual hosts. Then you can force users to run cgis through a cgi-wrapper like CGIWrap [unixtools.org] . Needless to say, this is not suitable for an ISP environment and for people / organizations that own their own domain names.

Re:Why is there an "Apache" user? (1)

Skapare (16644) | about 11 years ago | (#5682220)

Sure, it is doable to have a single IP working HTTP requests by name and have each site or group of sites (same user) have a dedicated server. I don't know how easy it could be retrofitted into Apache, but certainly one way to do this is to have a front end like a proxy that checks the host of the request and routes the request accordingly. Maybe that could be routed to a different port number according to a configured map. But I would be more inclined to route the requests to a named pipe in the filesystem.

It's nice but.... (2, Insightful)

Lagos (67371) | about 11 years ago | (#5680158)

I've been setting up an OpenBSD web server for the past few days now, and had some time to finagle with chroot Apache. I've found it to be a wonderful idea that I've had to disable.

Why? No fault of OpenBSD, really. Simply that in order to do anything really interesting, I had to disable the chroot of httpd. Take perl scripts, for example: If a CGI script is supposed to be interpreted by /usr/bin/perl (as indicated with #!) it will fail unless you've placed a copy of the perl interpreter in the chroot environment. You can get around this with mod_perl to embed a perl interpreter directly into Apache, but one still will have to preload any shared libraries mod_perl uses (see section four of the paper).

As another example, PHP's mail() function [which is fairly important, I feel] relies on the presence of sendmail. Sendmail then, must be accessible from the chroot directory in order to work.

Someone above has commented that you can mount /usr in the chroot environment to solve most of these problems. But of course, as the paper says, the more binaries in the environment, the lower the security, so one must make sure there is no setuid binary available.

Ultimately, the paper does describe ways around this, basically preloading any shared library your Apache modules might need and populating the chroot jail with any binaries you want for CGI and their shared libraries. This mirroring however requires a good deal of maintenance and waste of space (following OpenBSD partitioning recommendations, /var and /usr will be on seperate partitions so hardlinks won't work. Symlinks can't break out of chroot). At this point, I think a lot of us will be unwilling to sacrifice simplicity (read: stability, maintainability) for this measure of security. The argument that this only affects those who CGI scripts is very correct, but ultimately a trivial point: To do anything interesting (like Slashdot) requires CGI.

The situation will get better, though, and they'll find a simple elegant maintenance system, as OpenBSD always has. Some things have to change: For example /etc/rc.conf is currently insufficient for preloading libraries. It should have an additional directive called httpd_preload for shared libraries. Also, apachectl may need to be modified or supplemented on OpenBSD.

Breaking in (1)

leonbrooks (8043) | about 11 years ago | (#5691340)

Symlinks can't break out of chroot

True, but they can `break in'. Move the real files to /var but outside the jail(s), put symlinks in their places, and hardlink yourself silly. Of course, I habitually mount /var as nosuid,nodev, so I don't expect much joy from suidperl, for instance. (-:

*BSD is a zoo! (-1)

SlashdotTroll (581611) | about 11 years ago | (#5680896)

That explains why there as so many genera of *BSD Unix. It's obviously a animal that is evolving.

Marc Balmer (Steve's brother?)
You wanna bannana? Here you go--woop, almost got it! O-K, you can have--woop, you didn't reach fast enough!

*leaves 2nd monkey boy throwing a fit...walks over to food stand*

Can I have some milk? Woo! Give me that!
Y0U M34N 7H1S?
Yuh! Woo! Giff muh mil-k!

Nice for some (2, Interesting)

the-dude-man (629634) | about 11 years ago | (#5680931)

I kind of like this idea. It moves more towards having a seperate enviornment from the operating system enviornment. Wich i like because i like to keep my http users as far away from the system as possible.

Using grsecurity kernel patch, i can use trusted path execution and take execution privlages away from the apache group, and set its gid = 1005 (or whatever you specified under trusted path execution for the untrusted group in the grsecurity options) and then only give apache execute rights on specific things...(ie pearl, java...etc). Howrever, this way, i only need to give apache execute rights on basically just apache, and run everything else from within the chroot. It makes my life much simplier. Not having to go and find all the intpretures that it needs access to, or the vms, giving them those rights, and then playing around with the directory structure to make sure apache cant just freely roam the system.

It does take more space, but i think its worth it. When i set up a webserver for a client, my biggest worrys are not known exploits, i can write a script to go and patch that for me. Hell in gentoo i write a line of bash and put it in my crontab and i never worry about known exploits agian. What i am more worried about is someone hitting me with a exploit that is not known. So if some sort of bufer overflow happens. At worst, i will lose the http service. But i can have a replication service running if its really a concern. So thats not much of an issue. However, what is an issue is people getting outside of the http service with buffer overflows. the grsecurity kernel patch, enforcing non executable pages and stacks, is nice, and does a good job at stopping buffer overflows, however, this chroot thing i find intergrates nicely into the extra levels of security i put in.

Emergency Closing (1, Funny)

Anonymous Coward | about 11 years ago | (#5708095)

Did you mean:

To the University of Maryland Community:
The University of Maryland will shut down in its entirety for Friday, April 11th.

As the deadline for the submission of University's final budget to the state has approached, it has become clear that we are suffering from a large budget shortfall. Because of this, we are forced to shut down the entire campus for a full day. We apologize for the short notice of this cancellation.

Dining services will still be running so that students may eat, and the student union will remain open. However, all classes are cancelled and most professors will not be on campus. A reduced number of shuttles will still be running.

Students may be curious as to why this shortfall has occurred. On March 15th, the Maryland House Appropriations Committee proposed a further $37 million cut to the university system for the 2004 budget year, on top of a $67 million reduction in the current budget. Unfortunately, this proposal was approved, which left us with a drastically reduced budget for 2004. In order to have enough money to continue operations in full in 2004, we must shut do

Thanks to everyone for your patience. Your understanding is appreciated. To the residents of Maryland, be sure to pay careful attention to the candidates you vote for in the upcoming elections, so that we can avoid this situation in the future.

Colonel Cathcart
Director, University Relations
University of Maryland, College Park

********************
This note was authorized for distribution to University of Maryland Community by: Colonel Cathcart, Director University Relations
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...