/usr/lib/tiger/html/background.html is in tiger 1:3.2.4~rc1-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 | <HR><PRE>
</PRE><HR>
<CENTER><H2> Documents for background</H2></CENTER>
<A NAME="rationale"><P><B>Code [rationale]</B><P>
<P>
The primary rationale behind many of the checks performed by `Tiger'
is to protect the super-user account. The assumption made is that any
other account or any group can be accessed. The goal is to protect
`root' from all accounts, even system accounts.
<P>
The reasons for these assumptions are varied, but they all fall back
to one thing. The `root' (uid=0) account is the only account that is
normally given special protection by services. Examples:
<P>
(In the following discussion, a network is considered to be a set of
machines, networked together, with trusted host facilities such as
/etc/hosts.equiv or NFS.)
<P>
o The Berkeley r-cmds (rlogin, rsh) will not honor /etc/hosts.equiv
for the super-user account. This protects a network of trusted
machines should one of them be compromised.
<P>
o NFS (Network File System, SMI) translates requests from super-user
accounts to requests from `nobody' (although this can be overridden).
As before, this attempts to protect a network of NFS'd machines should
one of them be compromised.
<P>
Other accounts are not protected in this way, including system
accounts such as `bin' and `daemon'. Once one of the accounts is
compromised on one machine on a network, the account is compromised on
all of the machines in the network. Often these system accounts are
considered safe and are trusted to own system executables, directories
and files. This is not true in a networked environment. Note that
simply disabling the account, or even deleting the account will not
remove the problem.
<P>
Hence, `Tiger' will report anything not owned by `root' which root
accesses, especially executables. One of the problems with this is
setuid executables which are setuid to a userid other than root. The
ownership can not be changed (if it is, it will no doubt create worse
security problems). A solution to this problem will be provided in
the future.
|