On Mon, 27 Mar 100, T.E.Dickey wrote:
> > But ncurses is a library - that's completely different anyway.
> > The lynx code can find itself running setuid only after someone
> > has explicitly done 'chmod ... /path/to/lynx' or the equivalent,
> > right?
>
> That last BugTraq report used an example that relied on having the
> sysadmin install a corrupt lynx.cfg (if that's going to be the ground
Which one? URL, please?
(I think you may have misunderstood something. I don't think that
that was meant at all, although I may have interpreted it like that
at first, too.)
> rules, I'd like to be able to assert more strongly that lynx will
> behave properly unless someone modifies its source ;-).
What is "properly"?
I assert that "properly" means
- using the effective uid (which is the same as the real uid) normally
(in non-setuid situations); and
- using the effective uid even in setuid situations. Someone wanted
it, it doesn't happen by accident.
Every deviation from this behavior, expected by default of apps, needs
to be documented. It belongs in the man page at least. And there better
be a good reason for it.
And by the way, why is there always the assumption that setuid is used
to *increase* priviledges? If the intention is to switch to a *less*
privileged account, then you may be defeating this!
---
Some related observations:
Emacs happily runs with euid=0 if I make the binary setuid root.
Any user can read root's -rw------- files when running that binary.
And that's as it should be - I ask for it, I get it.
Nobody expects emacs to run in a "safe" fashion (whatever that
means) when it is used in a basically unsafe way. Lynx shouldn't
be any different.
The behavior of shells (and therefore, of shelling out with system()
from emacs, lynx, ...) is a different story. Shells do things that
don't apply to most normal processes. It's documented, and there
are special flags to modify the behavior, for example (for bash):
-p Turn on privileged mode. In this mode, the
$ENV and $BASH_ENV files are not processed,
shell functions are not inherited from the
environment, and the SHELLOPTS variable, if
it appears in the environment, is ignored.
If the shell is started with the effective
user (group) id not equal to the real user
(group) id, and the -p option is not sup-
plied, these actions are taken and the
effective user id is set to the real user
id. If the -p option is supplied at
startup, the effective user id is not
reset. Turning this option off causes the
effective user and group ids to be set to
the real user and group ids.
My system(3) man page says:
Do not use system() from a program with suid or sgid priv-
ileges, because strange values for some environment vari-
ables might be used to subvert system integrity. Use the
exec(3) family of functions instead, but not execlp(3) or
execvp(3). system() will not, in fact, work properly from
programs with suid or sgid privileges on systems on which
/bin/sh is bash version 2, since bash 2 drops privileges
on startup. (Debian uses a modified bash which does not
do this when invoked as sh.)
[ My translation of the first sentence: (to the user:) Do not give
suid or sgid privileges to a program that may call system().
(to the application writer:) Do not use system() from a program
for which suid/sgid is a normal mode of operation that needs to
be safe. It does *not* mean: refuse to run with suid/sgid
privileges in any program that uses system(). ]
The parenthesis at the end indicates that not messing with the
effective privileges is a desirable feature sometimes (desirable
enough for a Linux distribution to "modify bash").
---
If you *really* want to prevent all dangerous uses of lynx, then
let's go all the way and be a pain in the ass like metamail...
METAMAIL(1)
-r This option specifies that it is OK to run as
root. By default, metamail refuses to run if the
real or effective user id is root. You can get
the same effect using the MM_RUNASROOT environment
variable.
Klaus
