[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20041023133004.GA564@openwall.com>
Date: Sat, 23 Oct 2004 17:30:04 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: sudo: why not?
On Sat, Oct 23, 2004 at 12:29:10PM +0200, Nico -telmich- Schottelius wrote:
> Solar Designer [Sat, Oct 23, 2004 at 03:38:23AM +0400]:
> > RSBAC is great, but I feel that you've missed the point. If it would
> > be permitted for a non-root user to su to root, then anyone who could
> > have compromised the user's account[1] would also be able to hijack a
> > su session[2] and then su to root himself. This attack is not affected
> > by kernel policy enforcement in any way.
> >
> > [1] Such a compromise could occur in a variety of ways: Web/FTP/etc.
> > client vulnerabilities, password snooping, etc.
> >
> > [2] For example, edit the user's shell startup scripts to make su an
> > alias for a custom su wrapper program.
>
> Isn't that a problem of any tool, which allows to change to a higher
> security level?
Yes, -- or, more precisely, it's a problem with making use of such
tools. For example, the mere existence of a Windows(*) PC with an SSH
client might not be a big security problem, but as soon as you use it
to SSH into your super secure server, you effectively empower the
Windows system (and not just yourself!) with access to the no longer
secure server.
> I just wanted to point to rsbac, as it at least removes the possibility
> for most users to setuid() and that way to 'exploit' su.
I really do not see how RSBAC is of any help here. You grant group
privileges for su just to those who are supposed to use su (if at all),
whether or not you use RSBAC on the system (for other great purposes).
(*) I used Windows as an example. Unfortunately, the same problem
exists, albeit to a slightly smaller extent, with typical uses of X
Window System desktops where you would use the same X server to run a
web browser and to SSH into supposedly secure remote servers. The use
of a dedicated pseudo-user account for the web browser is a first step
to resolving this, -- but it is not sufficient because of the shared X
server. A solution to this appears to be the use of a filtering X
proxy, through which the web browser will talk to your X server:
http://cons.home.cern.ch/cons/mxconns/
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
