You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Mr. Tomcat" <to...@mobile.mp> on 2002/09/16 03:47:52 UTC
Solved! Tomcat on port 80 without root, on Linux
"Can I run Tomcat on port 80 not as root?" seems to come up with some
regularity on this list. Web servers have to be able to safely process
untrusted, dangerous data from any host on the Internet. Obviously,
they should run at the lowest possible privilege level, so that if the
server is compromised, the attacker will be limited in what he can do.
Java minimizes this problem. Triggering a buffer overflow with some
kind of input to Tomcat would be extremely difficult. However, a web
app might have a bug that allows an attacker to trick it into writing to
a file which it shouldn't write to, or something like that. The fewer
things that the JVM itself can do, the better. Hence, running the
server as a special user with limited access is smart. Running it as
root is not smart, if it can possibly be avoided.
There has been a long-standing misfeature in Unix that only root can
bind to ports less than 1024 ("privileged ports"). Usually, this means
that Tomcat standalone must run as root, or the Linux NAT tools must be
used to map port 80 to some higher port. Running as root is obviously
undesirable. Using NAT may be a good idea, but it would be nice to have
another option: Why not tweak the kernel to remove the "security
feature"?
If you want to build a custom kernel that lets all users bind to low
ports, edit this file in the kernel: include/net/sock.h, and change
PROT_SOCK from 1024 to 0. Recompile, install, and now any user can bind
process to any port.
Before you do this, make sure you think through all the implications of
it. If you have untrusted users on the machine with this modified
kernel, they will now be able to run any kind of network services they
want to. This is obviously bad, so don't use this kind of kernel on any
machine with untrusted users. It could have other implications, too, so
use this modification at your own risk.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Solved! Tomcat on port 80 without root, on Linux
Posted by Chuck Amadi <ch...@breconbeacons.org>.
Nikola Milutinovic wrote:
> Mr. Tomcat wrote:
>
>> "Can I run Tomcat on port 80 not as root?" seems to come up with some
>> regularity on this list. Web servers have to be able to safely process
>> untrusted, dangerous data from any host on the Internet. Obviously,
>> they should run at the lowest possible privilege level, so that if the
>> server is compromised, the attacker will be limited in what he can do.
>
>
> Every server should run at the lowest possible level, preferably in
> CHROOT. The dissadvantage is the overhead and duplication of files.
> Some of the most popular can be run this way, BIND, OpenSSH, (Sendmail
> ?), Cyrus IMAP (just user part),...
>
>> Java minimizes this problem. Triggering a buffer overflow with some
>> kind of input to Tomcat would be extremely difficult. However, a web
>> app might have a bug that allows an attacker to trick it into writing to
>> a file which it shouldn't write to, or something like that. The fewer
>> things that the JVM itself can do, the better. Hence, running the
>> server as a special user with limited access is smart. Running it as
>> root is not smart, if it can possibly be avoided.
>
>
> True. Although, perhaps it is better to run a robust front-end in
> heavy loaded environments, like Apache.
>
>> There has been a long-standing misfeature in Unix that only root can
>> bind to ports less than 1024 ("privileged ports").
>
>
> This a flaming material - watch out! Every UNIX admin (like me) will
> scream at the mention of this being a misfeature. If ports < 1024 are
> considered reserved for some services, then I really wouldn't want an
> unpriviledged process to bind to any of them. That would mean that
> even if I have a CHROOT-ed unpriviledged process, say DNS, that got
> compromized, it could turn my server into a platform for any kind of
> service, not just the one that got compromized.
>
>> Usually, this means
>> that Tomcat standalone must run as root, or the Linux NAT tools must be
>> used to map port 80 to some higher port. Running as root is obviously
>> undesirable. Using NAT may be a good idea, but it would be nice to have
>> another option: Why not tweak the kernel to remove the "security
>> feature"?
>
>
> Because we got used to UNIX semantics. Only "root" can bind to
> priviledged ports and we either like it or got used to it.
>
>> If you want to build a custom kernel that lets all users bind to low
>> ports, edit this file in the kernel: include/net/sock.h, and change
>> PROT_SOCK from 1024 to 0. Recompile, install, and now any user can bind
>> process to any port.
>>
>> Before you do this, make sure you think through all the implications of
>> it. If you have untrusted users on the machine with this modified
>> kernel, they will now be able to run any kind of network services they
>> want to. This is obviously bad, so don't use this kind of kernel on any
>> machine with untrusted users. It could have other implications, too, so
>> use this modification at your own risk.
>
>
> No user is trusted, as far as I'm concerned. Except fo "root".
>
> Anyway, thanks for posting this to the "knowledge base". Anybody doing
> this better be sure (s)he knows what (s)he's doing.
>
> Nix.
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
Interesting topic as I have always stuck to the logic to run everything
above 1024 Now I have got a clearer reason why.
Nice One!!
--
Regards
Chuck Amadi
ICT Dept Systems Programmer
Rhaglenydd Systemau Adran ICT
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: OT - Java variables - a copy or a reference?
Posted by neal <ne...@yahoo.com>.
Cool. Thanks for the explanation! :)
Neal
-----Original Message-----
From: Willis Boyce [mailto:wboyce@panix.com]
Sent: Monday, September 16, 2002 12:00 AM
To: Tomcat Users List
Cc: wboyce@panix.com
Subject: Re: OT - Java variables - a copy or a reference?
Neal,
Java creates references. In other words this code:
Object a = new Object();
Object b = a;
creates one Object instance and two references that point to it. That's
why it's sometimes misleading to "name" an object by its reference. You
could say that the Object instance in this example is called "a," but it
might be equally valid to call it "b" depending on the circumstances.
This code is functionally identical:
Object a = new Object();
myServletContext.setAttribute("a",a);
Object b = myServletContext.getAttribute("a");
If you really want to make a *copy* then you should make the class
implement Cloneable and create a public clone method that invokes
super.clone. Here is my standard Cloneable implementation:
class MyCloneableClass implements Cloneable
{
public Object clone()
{
try
{
return super.clone();
}
catch (CloneNotSupportedException x)
{
// super.clone throws this if this class does not implement
// Cloneable, but obviously this one does, so we can consume
// it here to avoid putting it in the throws clause of this
// method.
}
}
}
Avoid the tempation to implement clone yourself by doing new
MyCloneableClass and copying each field individually. That will make it
difficult for others to inherit from your class, as its clone method only
creates instances of MyCloneableClass and not instances of
MyCloneableSubclass. The clone method of Object (invoked via super.clone)
does the right thing for subclasses.
W
On Sun, 15 Sep 2002, neal wrote:
> Does anyone know exactly what Java is doing when one creates a new
variable
> by referring to an existing variable? Does it simply create a reference to
> the original object, or does it completely copy the object referred to?
And,
> is the answer the same when dealing with Application-scope variables?
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: OT - Java variables - a copy or a reference?
Posted by Willis Boyce <wb...@panix.com>.
Neal,
Java creates references. In other words this code:
Object a = new Object();
Object b = a;
creates one Object instance and two references that point to it. That's
why it's sometimes misleading to "name" an object by its reference. You
could say that the Object instance in this example is called "a," but it
might be equally valid to call it "b" depending on the circumstances.
This code is functionally identical:
Object a = new Object();
myServletContext.setAttribute("a",a);
Object b = myServletContext.getAttribute("a");
If you really want to make a *copy* then you should make the class
implement Cloneable and create a public clone method that invokes
super.clone. Here is my standard Cloneable implementation:
class MyCloneableClass implements Cloneable
{
public Object clone()
{
try
{
return super.clone();
}
catch (CloneNotSupportedException x)
{
// super.clone throws this if this class does not implement
// Cloneable, but obviously this one does, so we can consume
// it here to avoid putting it in the throws clause of this
// method.
}
}
}
Avoid the tempation to implement clone yourself by doing new
MyCloneableClass and copying each field individually. That will make it
difficult for others to inherit from your class, as its clone method only
creates instances of MyCloneableClass and not instances of
MyCloneableSubclass. The clone method of Object (invoked via super.clone)
does the right thing for subclasses.
W
On Sun, 15 Sep 2002, neal wrote:
> Does anyone know exactly what Java is doing when one creates a new variable
> by referring to an existing variable? Does it simply create a reference to
> the original object, or does it completely copy the object referred to? And,
> is the answer the same when dealing with Application-scope variables?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
OT - Java variables - a copy or a reference?
Posted by neal <ne...@yahoo.com>.
Does anyone know exactly what Java is doing when one creates a new variable
by referring to an existing variable? Does it simply create a reference to
the original object, or does it completely copy the object referred to? And,
is the answer the same when dealing with Application-scope variables?
I have created a hash on init of my application and placed transformer
objects in it for all my XSLT files thereby caching those my XsLT. This is
then placed into the application object:
ServletContext application = getServletContext();
application.setAttribute(...);
Now, in order to refer to these items, in subsequent servlets I must refer
to the application object again. If I do this on each page:
ServletContext application = getServletContext();
Hashtable myHash = application.getAttribute("myHash");
Am I simply creating a refernce to that object, or creating a temporary
copy? Will this create a local copy or is it still a reference to the
Application Singeton instance?
Thanks.
Neal
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Solved! Tomcat on port 80 without root, on Linux
Posted by Nikola Milutinovic <Ni...@ev.co.yu>.
Mr. Tomcat wrote:
> "Can I run Tomcat on port 80 not as root?" seems to come up with some
> regularity on this list. Web servers have to be able to safely process
> untrusted, dangerous data from any host on the Internet. Obviously,
> they should run at the lowest possible privilege level, so that if the
> server is compromised, the attacker will be limited in what he can do.
Every server should run at the lowest possible level, preferably in CHROOT. The
dissadvantage is the overhead and duplication of files. Some of the most popular
can be run this way, BIND, OpenSSH, (Sendmail ?), Cyrus IMAP (just user part),...
> Java minimizes this problem. Triggering a buffer overflow with some
> kind of input to Tomcat would be extremely difficult. However, a web
> app might have a bug that allows an attacker to trick it into writing to
> a file which it shouldn't write to, or something like that. The fewer
> things that the JVM itself can do, the better. Hence, running the
> server as a special user with limited access is smart. Running it as
> root is not smart, if it can possibly be avoided.
True. Although, perhaps it is better to run a robust front-end in heavy loaded
environments, like Apache.
> There has been a long-standing misfeature in Unix that only root can
> bind to ports less than 1024 ("privileged ports").
This a flaming material - watch out! Every UNIX admin (like me) will scream at
the mention of this being a misfeature. If ports < 1024 are considered reserved
for some services, then I really wouldn't want an unpriviledged process to bind
to any of them. That would mean that even if I have a CHROOT-ed unpriviledged
process, say DNS, that got compromized, it could turn my server into a platform
for any kind of service, not just the one that got compromized.
> Usually, this means
> that Tomcat standalone must run as root, or the Linux NAT tools must be
> used to map port 80 to some higher port. Running as root is obviously
> undesirable. Using NAT may be a good idea, but it would be nice to have
> another option: Why not tweak the kernel to remove the "security
> feature"?
Because we got used to UNIX semantics. Only "root" can bind to priviledged ports
and we either like it or got used to it.
> If you want to build a custom kernel that lets all users bind to low
> ports, edit this file in the kernel: include/net/sock.h, and change
> PROT_SOCK from 1024 to 0. Recompile, install, and now any user can bind
> process to any port.
>
> Before you do this, make sure you think through all the implications of
> it. If you have untrusted users on the machine with this modified
> kernel, they will now be able to run any kind of network services they
> want to. This is obviously bad, so don't use this kind of kernel on any
> machine with untrusted users. It could have other implications, too, so
> use this modification at your own risk.
No user is trusted, as far as I'm concerned. Except fo "root".
Anyway, thanks for posting this to the "knowledge base". Anybody doing this
better be sure (s)he knows what (s)he's doing.
Nix.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Solved! Tomcat on port 80 without root, on Linux
Posted by "Julian C. Dunn" <jd...@verticalscope.com>.
On Mon, 16 Sep 2002, Kwok Peng Tuck wrote:
> I was of the assumption that tomcat can run on port 80 without being
> root, using the same way as apache does that is with
> the user nobody. If that's true I don't see the need for anyone to
> modify the kernel.
Apache -does- run as root on port 80, but forks children to handle
incoming requests with the privileges of the local WWW user. So this isn't
a solution.
- Julian
--
Julian C. Dunn, B.A.Sc <jd...@verticalscope.com>
Senior Software Developer, VerticalScope Inc.
Tel.: (416) 341-8950 x236 Fax: (416) 341-8959
WWW: www.verticalscope.com
"Windows NT encountered the following error:
The operation was completed successfully."
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Solved! Tomcat on port 80 without root, on Linux
Posted by Kwok Peng Tuck <pe...@makmal.com>.
I was of the assumption that tomcat can run on port 80 without being
root, using the same way as apache does that is with
the user nobody. If that's true I don't see the need for anyone to
modify the kernel.
Mr. Tomcat wrote:
>"Can I run Tomcat on port 80 not as root?" seems to come up with some
>regularity on this list. Web servers have to be able to safely process
>untrusted, dangerous data from any host on the Internet. Obviously,
>they should run at the lowest possible privilege level, so that if the
>server is compromised, the attacker will be limited in what he can do.
>
>Java minimizes this problem. Triggering a buffer overflow with some
>kind of input to Tomcat would be extremely difficult. However, a web
>app might have a bug that allows an attacker to trick it into writing to
>a file which it shouldn't write to, or something like that. The fewer
>things that the JVM itself can do, the better. Hence, running the
>server as a special user with limited access is smart. Running it as
>root is not smart, if it can possibly be avoided.
>
>There has been a long-standing misfeature in Unix that only root can
>bind to ports less than 1024 ("privileged ports"). Usually, this means
>that Tomcat standalone must run as root, or the Linux NAT tools must be
>used to map port 80 to some higher port. Running as root is obviously
>undesirable. Using NAT may be a good idea, but it would be nice to have
>another option: Why not tweak the kernel to remove the "security
>feature"?
>
>If you want to build a custom kernel that lets all users bind to low
>ports, edit this file in the kernel: include/net/sock.h, and change
>PROT_SOCK from 1024 to 0. Recompile, install, and now any user can bind
>process to any port.
>
>Before you do this, make sure you think through all the implications of
>it. If you have untrusted users on the machine with this modified
>kernel, they will now be able to run any kind of network services they
>want to. This is obviously bad, so don't use this kind of kernel on any
>machine with untrusted users. It could have other implications, too, so
>use this modification at your own risk.
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Solved! Tomcat on port 80 without root, on Linux
Posted by Josh G <jo...@gfunk007.com>.
Perhaps running a kernel modified in this way in usermode linux?
----- Original Message -----
From: "Mr. Tomcat" <to...@mobile.mp>
To: <to...@jakarta.apache.org>
Sent: Monday, September 16, 2002 11:47 AM
Subject: Solved! Tomcat on port 80 without root, on Linux
> "Can I run Tomcat on port 80 not as root?" seems to come up with some
> regularity on this list. Web servers have to be able to safely process
> untrusted, dangerous data from any host on the Internet. Obviously,
> they should run at the lowest possible privilege level, so that if the
> server is compromised, the attacker will be limited in what he can do.
>
> Java minimizes this problem. Triggering a buffer overflow with some
> kind of input to Tomcat would be extremely difficult. However, a web
> app might have a bug that allows an attacker to trick it into writing to
> a file which it shouldn't write to, or something like that. The fewer
> things that the JVM itself can do, the better. Hence, running the
> server as a special user with limited access is smart. Running it as
> root is not smart, if it can possibly be avoided.
>
> There has been a long-standing misfeature in Unix that only root can
> bind to ports less than 1024 ("privileged ports"). Usually, this means
> that Tomcat standalone must run as root, or the Linux NAT tools must be
> used to map port 80 to some higher port. Running as root is obviously
> undesirable. Using NAT may be a good idea, but it would be nice to have
> another option: Why not tweak the kernel to remove the "security
> feature"?
>
> If you want to build a custom kernel that lets all users bind to low
> ports, edit this file in the kernel: include/net/sock.h, and change
> PROT_SOCK from 1024 to 0. Recompile, install, and now any user can bind
> process to any port.
>
> Before you do this, make sure you think through all the implications of
> it. If you have untrusted users on the machine with this modified
> kernel, they will now be able to run any kind of network services they
> want to. This is obviously bad, so don't use this kind of kernel on any
> machine with untrusted users. It could have other implications, too, so
> use this modification at your own risk.
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Solved! Tomcat on port 80 without root, on Linux
Posted by Willis Boyce <wb...@panix.com>.
Wow, this seems like a pretty drastic measure to resolve a relatively
trivial problem! Aside from the inconvenience of having to compile it in
the first place, running a custom kernel also makes it more difficult for
you to take advantage of kernel patches, some of which may be
security-related; the custom kernel may ultimately wind up making your
system *less* secure instead of more.
Also, you should be aware that some Unix utilities, such as rsh, consider
a source port less than 1024 as evidence that a connection is originating
from a trusted process. If an intruder got access to your machine through
*any* means, even if he was unable to get root access, then he could use
his ability to bind to supposedly secure ports to attack other machines on
your network. Admittedly this is a pretty remote possibility, but there
may be other consequences of allowing user access to ports less than 1024
that you've not identified.
Is it really so hard to use NAT, or run Apache in front of Tomcat? If you
took the latter route then you could utilize some of the nice features of
Apache, such as URL rewriting and load balancing.
Willis
On 15 Sep 2002, Mr. Tomcat wrote:
> There has been a long-standing misfeature in Unix that only root can
> bind to ports less than 1024 ("privileged ports"). Usually, this means
> that Tomcat standalone must run as root, or the Linux NAT tools must be
> used to map port 80 to some higher port. Running as root is obviously
> undesirable. Using NAT may be a good idea, but it would be nice to have
> another option: Why not tweak the kernel to remove the "security
> feature"?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>