cernrules.txt

一个可用于linux下的命令行音乐播放器

# lynx.cfg (or with command line options), and there are various levels
# of control, too much to go into here.  It is assumed in the following that
# lynxexec has been enabled to the degree necessary (allow /usr/bin/man
# execution) but hopefully not too much.
# What needs to be prevented is that allowing local execution of the man
# command might unintentionally open up unwanted execution of other commands,
# possibly by some trick that could be exploited.  For example, redirecting
# man:* as above, the URL "man:lynx;rm -r *" could result in the command
# "man lynx;rm -r *" executed by the system, with obvious disastrous results.
# (This particular example won't actually work, for several reasons; but
# for the purpose of discussion let's assume it did, there may be similar
# ones that do.)
# Because of such dangers, redirection to a lynxexec: is normally never
# accepted by lynx.  We need at least a PermitRedirection rule to override
# this protective limitation:
#   PermitRedirection man:*
#   Redirect          man:*  "lynxexec:/usr/bin/man *"
# But now we have potentially opened up local execution more than is
# acceptable via the man: scheme, so this needs to be examined.
# There are two aspects to security here: (1) restricting the user, and (2)
# protecting the user.  The first could also be phrased as protecting the
# system from the user; the second as preventing lynx (and the system) from
# doing things the user doesn't really want.  Aspect (1) is very important
# for setups providing anonymous guest accounts and similarly restricted
# environments.  (Otherwise shell access is normally allowed, and trying to
# protect the system in lynx would be rather pointless.)  As far as access
# to some URLs is concerned, the difference can be characterized in terms of
# which sources  of URLs are trusted enough to allow access: for (1), only
# links occurring in a limited number of documents are trusted enough for
# some (or all) URLs, user input at 'g'oto prompts and the like is not (if
# not completely disabled).  For (2) and assuming a user with normal shell
# privileges, the user may be trusted enough to accept any URL explicitly
# entered, but URLs from arbitrary external sources are not - someone might
# try to use them to trick the user (by following an innocent-looking link)
# or lynx (by following a redirection) into doing something undesirable.
#
# In the following we are concerned with (2); it is assumed that providers
# of anonymous accounts would not want to follow this path, and would have
# no need for additional schemes that imply local execution anyway.  (For
# one thing, with the man example they would have to carefully check that
# users cannot break out of the man command to a local shell prompt.)
#
# Getting back to the example, it was already mentioned that lynx does not
# allow redirections to lynxexec.  In fact this continues to be disallowed
# for real redirection received from HTTP servers.  But we have introduced
# a new man: scheme, and the lynx code that does the redirection checking
# doesn't know anything about special considerations for man: URLs, so
# an external HTTP server might send a redirection message with "Location:
# man:<something>", which lynx would allow, and which would in turn be
# redirected by our rule to "lynxexec:/usr/bin/man <something>".  Unless
# we are 100% sure that either this can never happen or that the lynxexec
# URL resulting from this can have no harmful effect, this needs to be
# prevented.  It can be done by checking for the "redirected" condition,
# either by putting something like (the first line is of course optional)
#   Alert  man:*  "Redirection to man: not allowed" if redirected
#   Fail   man:*                                    if redirected
# somewhere before the Redirect rule, or, reversing the logic, by adding
# a condition to the redirection rules, i.e. they become
#   PermitRedirection man:*                             unless redirected
#   Redirect          man:*  "lynxexec:/usr/bin/man *"  unless redirected
# (actually, putting the condition on either one of the rules would be
# sufficient).  The second variant assumes that the attempted access to
# man: via redirection will ultimately fail because there is no other way
# to handle such URLs.
#
# The above should take care of rejecting man: URLs from redirections, but
# what about regular links in HTML (like <A HREF="man:...">)?  As long as
# it can be assumed that the user will always inspect each and every link
# before following it, and never follow a link that can have harmful effect,
# no further restrictions are necessary.  But this is a very big assumption,
# unrealistic except perhaps in some single-user setups where the user is
# is identical with the rule writer.  So normally most links have to be
# regarded as suspect, and only URLs entered by the user can be accepted:
#   Alert  man:*  "Redirection to man: not allowed" if redirected
#   Fail   man:*                                    if redirected
#   Alert  man:*  "Link to man: not allowed"        unless userspecified
#   Fail   man:*                                    unless userspecified
#
# With these restrictions we have limited the ways our new man: scheme can
# be used rather severely, to the point where its usefulness is questionable.
# In addition to 'g'oto prompts, it may work in Jump files; also, should
# links to man:<something> appear in HTML text, the user could retype them
# manually or use the ELGOTO ('E') command with some trivial editing (like
# adding a space) to "confirm" the URL.  Even if the precautions outlined
# above are followed: THIS TEXT DOES NOT IMPLY ANY PROMISE THAT, BY FOLLOWING
# THE EXAMPLES, LYNX WILL BE SAFE.  On the other hand, some of the precautions
# *may* not be necessary: it is possible that careful use of TRUSTED_EXEC
# options in lynx.cfg could offer enough protection while making the new
# scheme more useful.
#
# If all this seems a bit too scary, that's intentional; it should be noted
# that these considerations are not in general necessary for "harmless" URL
# schemes, but appropriate for this "extreme" example.  One last remark
# regarding the hypothetical man scheme: instead of implementing it through
# "lynxexec:" or "lynxprog:", it would be somewhat safer to use "lynxcgi:"
# instead if it is supported.  A simple lynxcgi script would have to write
# the man page to stdout (either converted to text/html or as plain text,
# preceded by an appropriate Content-Type header line), and all necessary
# checking for special shell characters would be done within the script -
# lynx does not use the system() function to run the script.
#
# Other Limitations
# =================
# First, see CAVEAT above.  There are other limitations:
#
# 1. Applicable URL schemes
# -------------------------
# Rules processing does not apply to all URL schemes.  Some are
# handled differently from the generic access code, therefore rules
# for such URLs will never be "seen".  This limitation applies at
# least to lynxexec:, lynxprog:, mailto:, LYNXHIST:, LYNXMESSAGES:,
# LYNXCFG:, and LYNXCOMPILEOPTS: URLs.  You shouldn't be tempted
# to try to redirect most of these schemes anyway, but this also
# makes it impossible to disable them with "Fail" rules.
#
# Also, a scheme has to be known to Lynx in order to get as far as
# applying rules - you cannot just define your own new foobar: scheme
# and then map it to something here, but see Application 9, above,
# for a workaround.
#
# 2. No re-checking
# -----------------
# When a URL is mapped to a different one, the new URL is not checked
# again for compliance with most restrictions established by -anonymous,
# -restrictions, lynx.cfg and so on.  This can be regarded as a feature:
# it allows specific exceptions.  Of course it means that users for
# whom any restrictions must be enforced cannot have write access to a
# personal rules file, but that should be obvious anyway!
# This limitation does not applies if "Redirect" is used, in that case
# the new URL will always be re-examined.
#
# 3. Mappings are invisible
# -------------------------
# Changing the URL with "Map" or "Pass" rules will in general not be
# visible to the user, because it happens at a late stage of processing
# a request (similar to directing a request through a proxy).  One
# can think of two kinds of URL for every resource: a "Document URL" as
# the user sees it (on INFO page, history list, status line, etc.), and
# a "physical URL" used for the actual access.  Rules change only the
# physical URL.  This is different from the effect of HTTP redirection.
# Often this is bad, sometimes it may be desirable.
#
# Changing the URL can create broken links if a document has relative URLs,
# since they are taken to be relative to the "Document URL" (if no BASE tag
# is present) when the HTML is parsed.
#
# This limitation does not apply if "Redirect" is used - the new location
# will be visible to the user, and will be used by lynx for resolving
# relative URLs within the document.
#
# 4. Interaction with proxying
# ----------------------------
# Rules processing is done after most other access checks, but before
# proxy (and gateway) settings are examined.  A "Fail" rule works
# as expected, but when the URL has been mapped to a different one,
# the subsequent proxy checking can get confused.  If it decides that
# access is through a proxy or gateway, it will generally use the
# original URL to construct the "physical" URL, effectively overriding
# the mapping rules.  If the mapping is to a different access scheme
# or hostname, proxy checking could also be fooled to use a proxy when
# it shouldn't, to not use one when it should, or (if different proxies
# are used for different schemes) to use the wrong proxy.  So "just
# don't do that"; in some cases setting the no_proxy variable will help.
# Example 3 happens to work nicely if there is a http_proxy but no
# ftp_proxy.
#
# This limitation does not come into play if a "UseProxy" rule is applied,
# in either of its two forms: with a PROXYURL, proxying is fully under
# the control of the rules author, and with "none", subsequent proxy
# and gateway checking is completely disabled.  It is therefore a good
# idea to combine any "Map" and "Pass" rules that might result in passing
# the changed URL with explicit "UseProxy" rules, if the rules file is
# expected to be used together with proxying; or else always use "Redirect"
# instead of simple passing.
#
# 5. Case-sensitive matching
# --------------------------
# The matching logic is generic string-based.  It doesn't know anything
# about URL syntax, and so it cannot know in which parts of a URL case
# matters and where it doesn't.  As a result, all comparisons are case-
# sensitive.  If (a limited number of) case variations of a URL need
# to be dealt with, several rules can be used instead of one.
# In particular, this makes "UseProxy ... none" in some ways more limited
# than a no_proxy setting.
#
# 6. Redirection differences
# --------------------------
# For some URLs lynx does never check after a request whether a redirection
# occurs; that makes the "Redirect" rule useless for such URLs (in addition
# to those mentioned under limitation 1.).  Some of them are some gopher
# types, telnet: and similar in most situations, newspost: and similar,
# lynxcgi:, and some other private types.  Trying to redirect these will
# make access fail.  You probable don't want to change such URLs anyway,
# but if you feel you must, try using "Map" and "Pass" instead.
#
# The -noredir command line option only applies for real HTTP redirection
# responses, Redirect rules are still applied.  Also for certain other
# command line options (-mime_header, -head) and command keys (HEAD) lynx
# shows the redirection message (or part of it) in case of a real HTTP
# redirection, instead of following the redirection.  Here, too, a Redirect
# rule remains effective (there is no redirection message to show, after all).
#
# 7. URLs required
# ----------------
# Full absolute URLs (modulo possible "*" matching wildcards) are required
# in rules.  Strings like "www.somewhere.com" or "/some/dir/some.file" or
# "www.somewhere.com/some/dir/some.file" are not URLs.  Lynx may accept
# them as user input, as abbreviated forms for URLs; but by the time the
# rules get checked, those have been converted to full URLs, if they can
# be recognized.  This also means that rules cannot influence which strings
# typed at a 'g'oto prompt are recognized for URLs - rules processing kicks
# in later.