[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LYNX-DEV Improvement on /tmp code fix?
From: |
Bela Lubkin |
Subject: |
Re: LYNX-DEV Improvement on /tmp code fix? |
Date: |
Mon, 14 Jul 1997 00:50:15 +0000 |
For the System V lineage, everything being discussed is "new". Sticky
directories are new as of SVR4. fchmod() is new as of SVR4. Symbolic
links are new as of SVR4. Many other non-BSD, non-SysV OSes exist which
will likewise have some arbitrary mix of features.
Each of these features has been added by various vendors, over time, to
their various earlier-than-SVR4 OSes, so in the real world you can find
all sorts of combinations. e.g. SCO Unix 3.2v4.2 supports symlinks and
sticky directories, but not fchmod(). OpenServer Release 5 (still
SVR3.2-based) supports all 3. Other SysV-pre-4-based OSes include AIX,
HP-UX, A/UX (Apple), older releases of IRIX, etc. Unless you intend to
exclude older versions of those OSes, you have to restrict yourself to
pretty basic OS features.
The *ONLY* safe method I know of is to invent a filename, open it with
O_CREAT | O_EXCL, and use it without ever closing it. This requires
neither sticky directories (and a walk-from-the-root to confirm them)
nor fchmod(), and it's proof against symlinks.
Exception: I know that there do in fact exist systems where O_CREAT |
O_EXCL follows symlinks (sigh). Fortunately, (A) these are very rare /
old, and (B) their security is already so hopelessly compromised, Lynx
would not really be adding to the problem. [No, I cannot name such a
system, but a security person that I trust tells me he's seen them.]
To apply this to stdio, it is necessary to use fdopen() (and again,
never close the file until you're done with it).
Coping with systems that don't have 3-argument open() probably requires
#ifdefs, or (possibly) a sequence of:
umask(restrictive);
x = open(2 args);
umask(previous);
[Jonathan Sergent:]
> (and confirm that they're all owned by a uid <100 [i.e. system directories
> of some sort] or the user)...
You can't assume uid < 100 == "system". (The least supportable part of
that assumption is that uid >= 100 != system.)
Regarding mythical systems: I have successfully compiled Lynx (a 2.5FM
code set, a while back) for SCO Xenix, which does not support any of
symlinks, sticky directories, or fchmod(). ["I successfully compiled"
!= "compiles on": it was a one-off with a considerable amount of
kludging in the source, which was not fit to be handed back to the dev
team.]
=============================================================================
This is not a comment on Fote's current code, which I have not seen.
Just a general comment on balancing the desire to write secure code
against the desire to write portable code.
>Bela<
;
; To UNSUBSCRIBE: Send a mail message to address@hidden
; with "unsubscribe lynx-dev" (without the
; quotation marks) on a line by itself.
;
- Re: LYNX-DEV Improvement on /tmp code fix?, (continued)
- Re: LYNX-DEV Improvement on /tmp code fix?, Foteos Macrides, 1997/07/13
- Re: LYNX-DEV Improvement on /tmp code fix?, Jonathan Sergent, 1997/07/13
- Re: LYNX-DEV Improvement on /tmp code fix?, Klaus Weide, 1997/07/13
- Re: LYNX-DEV Improvement on /tmp code fix?, Jonathan Sergent, 1997/07/13
- Re: LYNX-DEV Improvement on /tmp code fix?, Jonathan Sergent, 1997/07/13
- Re: LYNX-DEV Improvement on /tmp code fix?, Klaus Weide, 1997/07/13
- Re: LYNX-DEV Improvement on /tmp code fix?, Jonathan Sergent, 1997/07/13
- Re: LYNX-DEV Improvement on /tmp code fix?, Klaus Weide, 1997/07/14
- Re: LYNX-DEV Improvement on /tmp code fix?, Jonathan Sergent, 1997/07/13
- Re: LYNX-DEV Improvement on /tmp code fix?, Klaus Weide, 1997/07/13
Re: LYNX-DEV Improvement on /tmp code fix?,
Bela Lubkin <=