[7272] in bugtraq
Re: ncurses 4.1 security bug
daemon@ATHENA.MIT.EDU (Alexander Kjeldaas)
Wed Jul 15 12:24:14 1998
Date: Wed, 15 Jul 1998 11:33:32 +0200
Reply-To: Alexander Kjeldaas <astor@GUARDIAN.NO>
From: Alexander Kjeldaas <astor@GUARDIAN.NO>
X-To: Warner Losh <imp@VILLAGE.ORG>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <199807102007.OAA21641@harmony.village.org>; from Warner Losh on
Fri, Jul 10, 1998 at 02:07:54PM -0600
On Fri, Jul 10, 1998 at 02:07:54PM -0600, Warner Losh wrote:
>
> And you have no way of knowing if they get called in such a ways as to
> put libc at risk.
>
> I see two solutions to this problem:
>
> 1) set?id programs need to be modified. They need to come up
> with their privs disabled and explicitly enable them for
> the work they need to do. This is definitely a change in
> the traditional behavior of how set?id works. It would buy
> a few things at the cost of a few other things. I'm
> surprised that I've need seen references to this in the
> literature.
>
The POSIX.6 features implemented in Linux 2.1 supports this [the
filesystem support for this will not be integrated into 2.2 so you
can't use this "out-of-the-box"]. What basically happens is that each
executable has an allowed set which states which capabilities(*) the
program is allowed to obtain, a set of forced capabilities which it
will obtain regardless of whether the executing process has them in
its inheritable set, and an effective bit which indicates whether the
executable is capability "smart" or "dumb". An executable that is
capability smart will start with capabilities only in its allowed set,
not in its effective set. It will therefore explicitly have to raise
the individual capabilities when it wants to use them. A capability
dumb program will start with effective=permitted capabilities.
* These are POSIX.6-style capabilities which is similar to VMS or
Trusted Solaris privileges, not KeyOS or _real_ capabilities. It is
a bitmask [or, actually 3: inheritable, permitted and effective]. In
Linux 2.1 all privilege checks in the kernel use these
capabilities instead of checking for whether the euid==0 or
not. uid==0 is simply emulated in the set*id calls by setting the
appropriate capability bits.
astor
--
Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway
http://www.guardian.no/
