Re: Good security related article
From: J. Peter Mugaas (oma00215_at_mail.wvnet.edu)
Date: 05/15/04
- Next message: J. Peter Mugaas: "Re: Good security related article"
- Previous message: J. Peter Mugaas: "Re: Good security related article"
- In reply to: Eugene Mayevski [SecureBlackbox]: "Re: Good security related article"
- Next in thread: QHenrick_Hellstr=F6m_=5BStreamSec=5D=22?=: "Re: Good security related article"
- Reply: QHenrick_Hellstr=F6m_=5BStreamSec=5D=22?=: "Re: Good security related article"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 14 May 2004 20:56:24 -0400
On Fri, 14 May 2004 22:19:34 +0300, Eugene Mayevski [SecureBlackbox] wrote:
>[snip]
> Encryption of the data makes sense when something or somebody can get
> direct access to this data. However in correctly designed system all
> access goes either through remote access where permission control takes
> place or through admin.console.
The big problem I see is that a lot of a servers still need administrative
privileges on many systems just so they can bind to specific ports in the
reserved range (1-1024) because the only person permitted to do that is an
administrator. On many systems, that gives access to everything (this is
true in both Linux and Windows NT). A HTTP server has to bind to port 80,
a HTTPS server has to bind to port 443, and by default and a SMTP server
has to bind to port 25. In Linux, a process can give up root privileges
and then go on running under a restricted user account. In FTP, this is
worse because RFC 959 requires that data channels for PORT transfers have
to come from port 20 on the server (by default) meaning that the daemon has
to keep root privileges. About the only way that you mitigate the damage
is to chroot it so it's confined to a specific part of a hierarchy.
Then you still have a few legacy clients that require administrative
privileges to run such as RSH, LPR (Line printer daemon), and a few older
SSH authentication schemes (host based). Part of that the authentication
process is that those clients have to bind to a low-numbered port (the
presumption is that if it's running on a low numbered port, the username is
correct). In order to run those, you need root privileges and on Linux,
the programs have to be set UID root if a user needs those. Set UID
presents it's own problems because you have to reduce your dependencies to
make the programs as secure as possible and you don't want the program to
get access to everything on the system (that's actually one reason why I
doubt I would support those legacy authentication mechanisms in Linux in a
SFTP program I'm writing). About the only elegant way I've that client
root privilege could be solved is to something like what KPPP does which is
impossible in CLX (that is have the program be SUID, the program forks into
a slave with root privileges and master process that loads the GUI
libraries after giving up root privilleges.
> I.e. you can hardly imagine that the
> data server can be accessed from outside to the extent when raw data can
> be obtained. If this is done, then no encryption will help cause the
> whole system requires redesign
See above.
-- J. Peter Mugaas - Indy Pit Crew Internet Direct (Indy) Website - http://www.nevrona.com/Indy Personal Home Page - http://www.wvnet.edu/~oma00215 If I want to do business with you, I will contact you. Otherwise, do not contact me.
- Next message: J. Peter Mugaas: "Re: Good security related article"
- Previous message: J. Peter Mugaas: "Re: Good security related article"
- In reply to: Eugene Mayevski [SecureBlackbox]: "Re: Good security related article"
- Next in thread: QHenrick_Hellstr=F6m_=5BStreamSec=5D=22?=: "Re: Good security related article"
- Reply: QHenrick_Hellstr=F6m_=5BStreamSec=5D=22?=: "Re: Good security related article"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|