Slashdot Mirror
Using OpenBSD's chrooted Apache
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."
does this PDF have a mirror, or an HTML link ?
F!rst p0st 37337!!!!
shoutz to the gcs crew! --sq
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.
My peave with pdf's is the size, slashdotted in 15secs instead of 45secs.
Dramatic in the slashdot community.
Posting useless rant since 2003.
this was done with the introduction of 3.2. 3.3 will be out shortly. As in May 1st. ._.
Security should always win, but it never does.
.02 cents.
Just my
ur b0x is 0wnz0r3d!
ur a looser!
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
Rus
Cheap UK and US VPS
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, 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?
Free music from Jack Merlot.
Marc must be such a disappointment to his big brother Steve...
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 in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin 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
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'm not trying again...
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.
[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'
This isn't exactly a recent change, I believe this happened over 6 months ago...
I was thinking maybe that was Steve's rebellious teenage son, trying to spite his old man like so many kids do.
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!
Location: Mt. Xinu
Spotted this on the list: U.S. Military helps fund Calgary Hacker
try { do() || do_not(); } catch (JediException err) { yoda(err); }
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!
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
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.
Gnome wasnt built in a day.
Hi guys.
Just wondering, it seems the OBSD chroot implementation can be broken out of.
I first noticed it here.
And the concept code, which is pretty standard, is here.
Please explain!
The government chroots YOU!
Join Tor today!
(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).
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 in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin 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
Doing something like this in future as standard could conciderably reduce the /. effect!
The problem with slashdot is that most of its users were bullied and stuffed into lockers as kids!
YOU FAIL IT!
Neat! I hope FreeBSD and NetBSD use this feature when they all merge.
Looking forward to it. ;)
--
Karma is overrated, whoring is ok.
HERE HERE!
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.)
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
you said... root
mirror
What good is a used up world, and how could it be worth having? --Sting
I've put up a mirror here
Rus
Cheap UK and US VPS
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.
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!!
;kla ;kuiop
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
asdf pu k;lui l; iou jkl; uipo adf iu m,.mk uip u
jiopu jkkuip u/,mou asdf uipkluip
The basic problem isn't that Apache runs as "userX" or "userY" or even "root", it's that it ONLY runs as user "apache"!
... logging, etc.
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
</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.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
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.
/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).
/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.
/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.
/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.
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
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
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,
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
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!
I am the nightmare of nightmares.
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.
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.
Python
Bind Apache to (say) port 8765 and NAT the incoming connections from port 80 to there.
/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.
And for an encore?
Change your user skeleton so public_html becomes a link to
Got time? Spend some of it coding or testing
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. (-:
Got time? Spend some of it coding or testing
Mandrake have begun to.
Got time? Spend some of it coding or testing
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