lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Klaus Weide
Subject: Re: LYNX-DEV securing Lynx for boxed-in environments.
Date: Sat, 13 Sep 1997 18:21:28 -0500 (CDT)

On Sat, 13 Sep 1997, William Yang wrote:

> Hi. 
> 
> I operate a fairly sizable Free-Net (20,000+ users), and am working
> with patches from early August 1997 to Lynx 2.7.1.
> 
> I've been working in the Lynx code a bit, and have a couple of
> thoughts about making the code base more friendly to sites that want
> to customize Lynx to their specific purposes.  For instance, I want to
> use LynxExec links at my site... but I think that the current
> mechanism is too open for my environment (but is certainly okay in
> most environments).
> 
> So, I figure I should just go into the code, and replace all exec
> family calls, all system calls, and all calls to popen with my
> modified versions that restrict what execution paths are permitted --
> I can box a user in to code I'm moderately certain is secure, by
> providing one directory that they're allowed to call programs from,
> which has rigorously tested code).
> 
> But, if I do this, it's actually going to get fairly involved to keep
> up with patches and updates (which, I've noticed, do happen
> frequently).
> 
> 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?  For example, for just lynxexec:
and lynxprog:, that is only one place (two calls of system(), actually)
in LYGetFile.c AFAICS.  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.
For example, you probably should allow execution of gzip -d for automatic
uncompression of "Content-Encoding: gzip" HTML docs (HTFWriter.c), but you
may want to disallow manual execution of gzip.  Or you want to allow
execution of /usr/sbin/sendmail where it is needed (for sending mail :))
but of course not mainual execution of that.

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.

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.

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).

> This will allow easier maintenance of add-on functions in unusual
> environments, without making too much of a mess of the code base.
> 
> While I've written a good path-checking function, I haven't integrated
> it into Lynx yet, because I'd really like to keep this easy to
> maintain....
> 
> Is there interest in this kind of thing, or am I on my own here?

I have 0 users, so I can't know execatly what's good in your situation...

  Klaus

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]