RE: WORA Considered Evil ;-)

[Steve Brewin <sb...@synsys.com>]

Stefano,

> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: 28 June 2003 20:07
> To: James Developers List
> Cc: community@apache.org
> Subject: Re: WORA Considered Evil ;-)
>
> Reading your post that dismiss the UNIX sysadm fears as a
> "think of the
> past",

and

> "get modern and stop the crap"

These are unrepresentative paraphrases of what I said. I don't believe that
the post actually said or implied either of these things.

I did say "I'm sure that everyone is in favour of hardening James as much as
possible. Its just that we should approach it from a Java perspective, not a
C on Unix one. The issues are different."

Why? Because the potential vulnerabilities and the optimum measures to
eliminate them are not the same for the two environments. To take an
approach that assumes that they are the same will result in a less hardend
solution. Examining the risks as they exist in James' Java environment
deployed on physical OSes such as Unix will achieve a maximally hardened
solution.

Achieving sysadm trust is not the same as achieving a maximally hardened
solution. Perhaps James could achieve a level of trust from some Unix
sysadms by making it possible to mirror the deployment environments that
they trust. Fine. But as developers we shouldn't be blind to the fact this
is a minor detour on the road to a maximally hardened solution.

I don't view this as an appeal to ignore anyone. I don't make a habit of
considering anyones views as "crap".

-- Steve


---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

Re: WORA Considered Evil ;-)

[Santiago Gala <sg...@hisitech.com>]

Serge Knystautas escribió:
> Santiago Gala wrote:
> 
>> I think a good equilibrium point between the "marketing" view of 
>> security (making sysadms trust) and purist java technical view would 
>> be to allow James not having to run as root under Unix (to handle 
>> protected ports like 25, 110, etc.) and then securing the rest of the 
>> processing through java security declarations.
> 
> 
> Since people here know qmail and sendmail a lot better than I do... how 
> do they bind to those ports without running as root?
> 

It is done, AFAIK, having a small program running as root, which just 
opens the server socket(s), listens to them. Every time a connection is 
accepted, this driver forks and spawns a different program under lesser 
privileges, passing it the socket as file descriptor. (Don't take this 
as a precise description)

A small auxiliary process (a minimalistic and security conscious C 
program) doing this and using some kind of IPC to communicate with a 
James+JNI process could do the job in a way that is both portable and 
can be trusted by sysadms. Please correct me if I'm wrong, as I'm not a 
POSIX wizard at all. I don't know how much of this applies to Windows, 
although sandboxing Windows services does not look like a bad idea.

Similar to what Costin and Pier discussed about some days ago re: 
communicating Apache with Tomcat, in a thread named "How ASF membership 
works and what it means".

P.S.) ASF membership means you can speak about those difficult issues 
and (some) people will actually listen :-P (For those blunt enough, this 
is a disclaimer)

Regards
-- 
Santiago Gala
High Sierra Technology, S.L. (http://hisitech.com)
http://memojo.com?page=SantiagoGalaBlog



---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

Re: WORA Considered Evil ;-)

[Ben Hyde <bh...@pobox.com>]

On Wednesday, July 2, 2003, at 10:46 AM, Serge Knystautas wrote:

> Santiago Gala wrote:
>> I think a good equilibrium point between the "marketing" view of 
>> security (making sysadms trust) and purist java technical view would 
>> be to allow James not having to run as root under Unix (to handle 
>> protected ports like 25, 110, etc.) and then securing the rest of the 
>> processing through java security declarations.
>
> Since people here know qmail and sendmail a lot better than I do... 
> how do they bind to those ports without running as root?

A guiding principal of qmail is no process should do more than the 
absolute minimum and it certainly shouldn't have any more rights than 
the absolute minimum.  Living up to those principals demands having 
lots of user accounts, each with exactly the minimum number of rights, 
and then using fork to create safe bubbles - you setting the user 
before forking to create the bubbles, and then cleverly passing just 
the right stuff to these processes to give them the right capabilities. 
  So for example a process that's root has the right to create a 
listener, but that process can then fork a process passing it that 
listener to give the capability to process/user with much more 
restricted rights.

We used to have a patch for HTTP that allowed a short lived root 
process to create the HTTP listener and then pass that open file handle 
to the server (notifying it were to find it via a parameter).  That 
enabled the entire server to run in user space.   It fell off the wagon 
at some point.

I know nothing about sendmail, makes you jealous doesn't it?

  - ben


---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

Re: WORA Considered Evil ;-)

[Thom May <th...@apache.org>]

* Ask Bjoern Hansen (ask@perl.org) wrote :
> On Wed, 2 Jul 2003, James Duncan Davidson wrote:
> 
> > By changing their id after they launch as root. setuid. Pretty common
> > thing to do. See man setuid.
> 
> With qmail it's even more separated. There's a small program that
> opens the port and then drops root.  The smtpd itself never has any
> special access.
> 
> The qmail mail system is one of the most beautiful pieces of
> software around; making another mail system without looking at qmail
> carefully is silly.
> 
To some extent I'd agree. However, there is a distinct lack of defensive
programming in qmail *itself*. So while the security aspects are totally
laudable, and there are definitely a lot of good ideas, you shouldn't go
looking at qmail as the be all and end all of mail servers.
(For people wanting specific pointers, /var/qmail/queue/lock/trigger is an
accident waiting to happen; and we've seen qmail-send just silently stop
delivering mail a few times. Also, having individual mails tied to inodes is
an absolute nightmare for disaster recovery. Oh, and the way the remote
queues can get hung up waiting because a site has fallen off the net is a
pain. (Yes, I can keep going like this for some time ;-) ))
And the fact it isn't Free really really bugs me.
Mind you, we do run qmail on ~300 servers, so I guess we are a limit case
for seeing qmail break in weird and wonderful ways.
So I guess this email is "take all the paranoia from qmail you can, but then
look at postfix too." :-)
Cheers
-Thom

---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

Re: WORA Considered Evil ;-)

[Ask Bjoern Hansen <as...@perl.org>]

On Wed, 2 Jul 2003, James Duncan Davidson wrote:

> By changing their id after they launch as root. setuid. Pretty common
> thing to do. See man setuid.

With qmail it's even more separated. There's a small program that
opens the port and then drops root.  The smtpd itself never has any
special access.

The qmail mail system is one of the most beautiful pieces of
software around; making another mail system without looking at qmail
carefully is silly.


 - ask

-- 
http://www.askbjoernhansen.com/ - http://develooper.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

Re: WORA Considered Evil ;-)

[James Duncan Davidson <du...@x180.net>]

On Wednesday, July 2, 2003, at 07:46 AM, Serge Knystautas wrote:

> Santiago Gala wrote:
>> I think a good equilibrium point between the "marketing" view of 
>> security (making sysadms trust) and purist java technical view would 
>> be to allow James not having to run as root under Unix (to handle 
>> protected ports like 25, 110, etc.) and then securing the rest of the 
>> processing through java security declarations.
>
> Since people here know qmail and sendmail a lot better than I do... 
> how do they bind to those ports without running as root?

By changing their id after they launch as root. setuid. Pretty common 
thing to do. See man setuid. There's some source code floating around 
the net to compile a native library for Java that will do a setuid for 
you... We wrote it back in the Java Web Server days so that we could 
start up on port 80 and then bounce to nobody (or whatever user you 
wanted).

It's f'ing insane that it's not a "standard" thing in the platform. 
There's zillions of audio things in there but not a good setuid. Feh.


---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

Re: WORA Considered Evil ;-)

[Serge Knystautas <se...@lokitech.com>]

Santiago Gala wrote:
> I think a good equilibrium point between the "marketing" view of 
> security (making sysadms trust) and purist java technical view would be 
> to allow James not having to run as root under Unix (to handle protected 
> ports like 25, 110, etc.) and then securing the rest of the processing 
> through java security declarations.

Since people here know qmail and sendmail a lot better than I do... how 
do they bind to those ports without running as root?

-- 
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com


---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

Re: WORA Considered Evil ;-)

[Santiago Gala <sg...@hisitech.com>]

Steve Brewin escribió:
> Achieving sysadm trust is not the same as achieving a maximally hardened
> solution. Perhaps James could achieve a level of trust from some Unix
> sysadms by making it possible to mirror the deployment environments that
> they trust. Fine. But as developers we shouldn't be blind to the fact this
> is a minor detour on the road to a maximally hardened solution.
> 

I think a good equilibrium point between the "marketing" view of 
security (making sysadms trust) and purist java technical view would be 
to allow James not having to run as root under Unix (to handle protected 
ports like 25, 110, etc.) and then securing the rest of the processing 
through java security declarations.

I think having to run a big program as root looks always dangerous, as 
it makes far more difficult to know what it is doing or to scan it for 
security problems. Specially if it is extensible or takes third party 
extension modules (mailets, etc.)

This (and better) hardening could be achieved at the "pure" java level 
by granting specific permissions to different codebases/jars, using 
doPrivileged() when needed and running under a security manager, but I 
doubt most sysadms would be convinced if they don't understand java 
security. I, for one, could "buy" a pure java securiy solution, but I'm 
not a typical sysadm.

Regards
-- 
Santiago Gala
High Sierra Technology, S.L. (http://hisitech.com)
http://memojo.com?page=SantiagoGalaBlog



---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

Re: WORA Considered Evil ;-)

[James Duncan Davidson <du...@x180.net>]

Some random thoughts--aside from the personal defense against a 
perceived attack which I'm not wanting to get involved with. :)

On Wednesday, July 2, 2003, at 12:53 AM, Steve Brewin wrote:

> I did say "I'm sure that everyone is in favour of hardening James as 
> much as
> possible. Its just that we should approach it from a Java perspective, 
> not a
> C on Unix one. The issues are different."

The only real issue that is different is that you don't have to worry 
about memory overflows since the VM doesn't allow it. Other than that, 
all of the basic security worries are the same no matter what language 
the system is written in. And since quite a few security holes are 
exploits of the code paths of a program rather than buffer overflows... 
it follows that the issues aren't necessarily different.

> Why? Because the potential vulnerabilities and the optimum measures to
> eliminate them are not the same for the two environments. To take an
> approach that assumes that they are the same will result in a less 
> hardend
> solution. Examining the risks as they exist in James' Java environment
> deployed on physical OSes such as Unix will achieve a maximally 
> hardened
> solution.

The problem is that you can't really examine the risks all the way. A 
large part of being a security weenie is protecting against what you 
can't predict. And that's where the Unix BOFH mentality on security 
comes from--decades of seeing what works and what doesn't. Trying to 
say that the problem doesn't exist or is different using Java isn't 
really helpful.

> Achieving sysadm trust is not the same as achieving a maximally 
> hardened
> solution.

The latter is something that you can't prove, you can only show good 
results with time. The former at least means that you play by rules 
that are known to work well.


---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org