[TAG] (forw) Re: (forw) Re: (forw) Re: lpr works for user not root in Basiclinux 2.1

[Rick Moen]

Quoting Sindi Keesan (keesan at grex.cyberspace.org):

> I am not a guy.

OK, apologies about my limited knowledge of names; I keep trying to
learn them from additional countries, but have a great many I've not yet
studied -- and the English language is hopelessly ill-equipped for
dealing with non-specified gender.  (Finnish and Turkish are better.)

Of course, if I were wandering around Tirana, I'd learn some Albanian
names and conventions, quickly.  ;->

(FWIW, American informal English increasingly uses "guys" to refer to
both sexes, this being a tangle that cannot be undone in any clean
fashion.)
 
> Do I need to test firewalls when I don't have one?

No.  You might be curious about the results, though.  I included that
third command because those are the three I always run -- and the third
one doesn't take significant time.

> Do I need a firewall if I am not running servers and use a modem?

What security measures you take, generally, should be dictated by your
assessment of threats and your resulting security policy.  (The lack of
an explicit policy results in a default policy.)

A "firewall" script (set of IP/port blocking rules) is a device to
counter some particular anticipated threat.  It comes with disadvantages
in interference with open connectivity and system complexity that should
be obvious upon reflection.  Whether those disadvantages are warranted
depends on your local policy, and on the particulars of that script and
your situation.

> I found 30 pages online at
> www.yiluda.net/manual/linux/rute/node29.html, of which the first 5 are
> semiunderstandable without a dictionary.

I like RUTE very much, and highly respect your enterprising spirit in
tackling it, but can't help thinking it probably exceeds the needs of
your current situation.

> ifconfig:  ifconfig was not compiled with interface status display
> support Part of busybox that I compiled.  I should compile it again
> with this support.  The older /bin/busybox ifconfig that I replaced
> gives ppp0 inet addr which looks like my IPLOCAL address.

Sounds right.

> >I didn't tell you to run nmap.
> 
> Someone on the TAG list asked about chkrootkit and someone said to
> scan my ports so I downloaded programs to do both, and neither of them
> found any problems or potential problems.  I am at least learning a
> lot.

My apologies for my part in any confusion.  I hope you find the tips
about how to best use nmap useful -- in some future situation, if not
your present one.

> How would someone install a trojanned copy of nmap when I never have
> any ports open to come through?

One way (among many others) might be to somehow convince you to retrieve
and run a trojaned executable.   (If you tell me you won't do that,
that's interesting but it's just one example.)

> If I had a trojanned copy, why did I not find it with 'which nmap',
> which finds any executables on the path, when I renamed the downloaded
> nmap temporarily?

Hyopthetically, an intruder might have replaced your downloaded nmap with 
a trojaned version, between the time you downloaded nmap and some time
you ran it.  That sabotage could be an automated process, left in
background to continue to hide the intruder from a suspicious admin.  
Alternatively, the intruder might have trojaned the console libraries,
such that nmap itself is OK, but the trojaned console libraries censor
its reports.  There are a myriad of other ways:  The point is that,
whenever you use the software of a suspect system to examine the system
itself, you are in some measure trusting software that you have some
reason to distrust.  That is why it is, generally speaking, smarter to
examine a host's network behaviour from a network-wise nearby node
rather than from the host itself.

> How can someone put files on my computer if I am not running a server
> and I don't even download emails to my own computer (I use pine at a
> shell account)?

{sigh}

If indeed (almost) the only network access you make is outbound ssh or
telnet (via PPP or otherwise), and you don't run any network daemons
(except X11, which is reachable from localhost only), and the only
exception to that is a couple of Web browsers that you run "su - user",
and you never fetch and run executables, then it's indeed difficult to 
think offhand of a credible attack vector -- other than a kernel
exploit, which would have us all in trouble.

Because you are running a big heap of code as the root user, including
all of X11, you _are_ setting up a situation where any flaw in that
stack that can be exploited will be fatal to security, as opposed to the
standard security model where the attacker cannot easily attack via
flaws in _pairs_ of codebases for lack of a common set of access
permissions between them, and where the attacker must have the use of
both code flaws and paths to escalate privilege.  You model is thus what
we would call "brittle" in the sense that flaws can cause disaster
overall that normally would affect only a limited subsystem.

Please note that the "su - user" method you use to run Opera/lynx 
still means that the less-trusted browser process is resting on a
fundamental root-user parent process, which may be reachable by remote
attack in ways not possible if there is no underlying root process. 


Anyway, beyond that, I am not kidding:  I am not going to go out of my
way to help someone who insists on routinely using the root account --
and on running X11 as root -- in dealing with other security issues.
I've stated my reasons:  If you don't accept them, that's your
privilege, but helping other people by preference is mine.