Re: LYNX-DEV securing Lynx for boxed-in environments.

[William Yang]

Klaus Weide wrote something like:

> On Sat, 13 Sep 1997, William Yang wrote:

[On the topic of reducing the risk of "breaking out of the box" in
certain kinds of specialized Lynx environments].

>> So... I'm curious as to how interested the collective Lynx developers
>> would be, in making sure that the necessary hooks for this kind of
>> add-on functionality get integrated into the code (I'll do the work,
>> but want to be sure it's going to get utilized)?  Namely, create
>> something like LYrunotherprogs.h and LYrunotherprogs.c to centralize
>> all the calls that execute/fork/spawn other programs.  The functions
>> would be dummy functions, which just call the original (by default,
>> wrapped_popen would just invoke popen, for instance).

> Wouldn't it make more sense to just replace the function in those places
> where you want the additional checks?  

Well, that would certainly be more straightforward (and may even what
I end up doing).  The problem is that I don't trust the programs
potentially being called by Lynx, which is why I want to restrict what
programs CAN be called by Lynx.  This does go beyond LynxExec,
LynxProg, and LynxCGI -- Lynx invoke tools like 'sendmail' (which is,
honestly, the single most likely point of security failure on any UNIX
box).

> I don't think one size fits all makes much sense
> here - It would be better to add your checks on a case-by-case basis.

The underlying assumption I'm making is that all code outside of Lynx
and the kernel is potentially broken.  Because Lynx developers are so
responsive to problems, I'm thinking that Lynx may be a sturdy
cornerstone of a viable boxed-in environment.

As it turns out, what I'm really interested in doing is restricting
*all* programs which are run by my users, at all times.  In a boxed-in
environment, this gives a tremendous number of advantages (better
auditing, easier tracking of problems, and knowing *exactly* what's
going to happen, even when there are bugs in a package (sometimes,
things have bugs, y'know?).

> Anyway, if you really want to replace all occurences of e.g. system() -
> there already is a LYSystem.h which redefines system() (although currently
> that is only done for VMS; the actual implementation is in LYCurses.c).
> You could follow the same path - make some function with the same calling
> convention as system(), or popen() etc., and then just #define.  That way
> you won't have to do many changes throughout all source files (execpt
> making sure that the .h file gets included).  But I am not convinced
> that it is useful; maybe you could give an example of what you would put
> in such a non-trivial wrapper.

Lynx invokes, what, a half dozen or a dozen programs, from "normal"
utilities like '/bin/mv' to tools like 'gzip', downloading and
printing methods, an editor, what have you.  I don't remember offhand,
but I seem to recall Lynx even invoking 'sendmail.'

I've been coding replacements and wrappers for most of these tools,
which introduce a level of security before we deal with filesystem
security under the UNIX operating system (that is, if a program
attempts to work on files which are not located in /tmp or the user's
home directory (exempting certain files, such as the .lynxrc), the
program simply exits, out of hand.  This is part of a
on-and-off-funded research project which should result in the
development of turn-key, community access (Free-Net style) system
software.  The problem is that system administrators who understand
security who are willing to work for extremely low (or non-existant)
pay on community access systems are few and far between... so one of
my site's sponsor, the Ohio Supercomputer Center, has expressed
interest in developing systems which minimize the level of skill
required to operate a fairly safe system.

This particular idea is really an outgrowth of the 'smrsh' package
from sendmail -- potentially, arbitrary programs can be run from
within Lynx... and that feature is something I'd like to prevent
(because I'm, in a word, paranoid ;-).

> There are very few places where a user-entered command can get executed -
> basically the one mentioned above for lynxexec:/lynxprog:, then LYCgi.c
> if you compile with LYNXCGI_LINKS - that's about it, AFAICS.  Unless you
> allow the users to define their editor, or allow '!', or give them a
> DOWNLOADER etc. which prompts for a command - but I don't you would do
> that :).  So you probably just should change those few places.

Which I'm certainly willing to do.  I'm looking toward the long-term
viability of this kind of modification, not just "making it work" in
the short run (my career path may diverge from working on Free-Nets
and public sector computing issues at some point in the next two
years... and I want to be sure that the work I do doesn't end up in
the bit bucket because nobody can (easily) maintain it.

By getting the support of the people doing the major portions of Lynx
development, it's going to be more supportable, which is why I asked.

Well... let's not forget that I'm only asking Lynx-Dev to integrate a
layout change to the code.  Namely, I would like to see Lynx using
intenral declarations for all calls which invoke external programs,
instead of simply using system-supplied calls, so that it's
straightforward for someone like me to add this kind of functionality
(I certainly don't think that outside the "boxed-in" environments of
systems like a Free-Net or other public-access sites, this would be
all that useful).

> If you don't trust the Lynx code to do everything right (like escaping of
> weird filenames, or buffer overruns) - that's another story, in that case
> a global change of all system()s etc. would make sense (but could be done
> with a global #define).

Ah, on the contrary... what I don't trust are the programs being
executed by Lynx -- that's why I want to place an additional check on
what CAN be run by Lynx.  I'm focusing on the WEAK link (the outside
programs), and seeing a straightforward fix (making sure that the weak
link isn't used from within Lynx, which has shown itself to be an
extremely responsive and reliable software package).

        -Bill
-- 
William D Yang                          The Greater Columbus Free-Net
address@hidden          System Administration & Operation

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;