The author (Steven Darnold) and some highly experienced support mailing
list members have not solved this problem in four years.

cat filename > /dev/lp0 works for root, so does gs used CLI without lpr,
or pbmtolj from netpbm.

lpr used from Opera, lpr filename or even cat filename | lpr work for
'user', but for root they do not send anything to the print queue (lpq
shows no entries). No error messages. I just get another prompt.

Permissions for lpr are unchanged from Slackware 7.1:

-r-s--s--x 1 root lp

(Must be s to print as user).

lp0 is crw-r--r-- 1 root root

chmod a+w lp0 did not help (crw-rw-rw-) nor did chmod 777 (crwxrwxrwx).
lp0 works for root except with lpr.

In order to work as user I have had to change permissions on /dev/null
(w), ttyp* and ptyp* (rw), set suid XVESA and anything svgalib (links2,
zgv, gs), make /var/lock writeable, make any scripts suid or executable as
user, etc. An education. I can now suid user (or login as user), dial,
load Xvesa, icewm, and rxvt and Opera and print as user.

ssh still says 'host key verification failed' though telnet works.

I would like to quit struggling with permissions every time I try to work
as user, and be able to print as root. I do know I should not work as
root online but I am not running any servers while online with my modem.
If you scold me please explain why.

Also BL3.40 comes with only root not user, so it would be helpful to print
as root. Both distributions were designed to be used as root, and the
author is therefore not interested in solving the problem.

No other distribution seems to have this problem. I read your knowledge
base and various HOWTOs.

Does lpr depend on some other program, library, or device that I need to
change permissions for? Can YOU print with lpr as root?

Back around 2002 you explained how to use a 2-floppy disk Basiclinux 1
with mdacon when I had no modprobe or telinit. I am typing this on my
dual-head system on the amber TTL monitor. You also helped me with OSS
and I can now record midi files from the 1986 Yamaha electronic piano to
libc5 Rosegarden.

> (I am sending a copy to one of our list members who has tried to figure
> out this lpr problem, as well as to The Answer Gang.

Oops. Did I forget to include the list in my reply? Sorry about that.

> What I want help with is printing as root so I won't need to jump
> through hoops to get every program working as 'user'. I must not
> have made this clear.

I understand that you want to avoid doing things as "root" and prefer
to do things as "user". That is a very good thing

> There is no .perm file listed in the lpr.tgz package which I added.
> I don't think we have LPRng.

I'm still not clear on which print package you have. Perhaps it is
the "classical" BSD lpr package. I don't recall that package
disabling printing as root. However, this may have been added as a
security measure --- explanation follows:

1. Some printing filters like "gs" are interpreters for the
programming language that describes the page that they are
about to print.

2. Files to be printed should then be treated as programs
for these interpreters.

3. Since printing by "root" would lead (possibly
inadvertently) to the execution of these "programs" it is
often disabled.

> >>ssh still says 'host key verification failed' though telnet works.
>
> The key works for root, not user.

I didn't understand this. Which key works? Just a quick explanation
of ssh host keys:

1. Each SSH server has a key called the "host" key.

2. When a client connects to the server it tries to verify
this host key in order to ensure that it is connecting to the
correct server by comparing the key presented to it with the
key in its "known_hosts" file.

>> What I want help with is printing as root so I won't need to jump
>> through hoops to get every program working as 'user'. I must not have
>> made this clear.
>
> I understand that you want to avoid doing things as "root" and prefer
> to do things as "user". That is a very good thing

No, I want to do everything as root (which is how our distributions were
designed to work) and nothing as user, which is much more complicated to
set up. Right now I need to suid user to print with lpr.

>> I don't think we have LPRng.

> I'm still not clear on which print package you have. Perhaps it is
> the "classical" BSD lpr package. I don't recall that package

The lpr man page refers to BSD4.

> disabling printing as root. However, this may have been added as a
> security measure --- explanation follows:
> 1. Some printing filters like "gs" are interpreters for the
> programming language that describes the page that they are
> about to print.
> 2. Files to be printed should then be treated as programs
> for these interpreters.
> 3. Since printing by "root" would lead (possibly
> inadvertently) to the execution of these "programs" it is
> often disabled.

How is it disabled?

gs works as root if I print from the command line. lpr does not.

As root, I can print to a .ps file instead of the printer, and then print
the .ps file with gs. But I am setting up small linuxes for friends who
just want to print formatted files directly with a wordprocessor or
browser, and it is complicated to make our linux work as user for every
program when it is designed to be used as root only.

>>>> ssh still says 'host key verification failed' though telnet works.
>>
>> The key works for root, not user.

After it did not work for 'user' without known_hosts, I copied known_hosts
from /root/.ssh to /home/user/.ssh without changing the permissions.

> I didn't understand this. Which key works? Just a quick explanation
> of ssh host keys:
> 1. Each SSH server has a key called the "host" key.
> 2. When a client connects to the server it tries to verify
> this host key in order to ensure that it is connecting to the
> correct server by comparing the key presented to it with the
> key in its "known_hosts" file.
> 3. Users often ignore ignore this verification by using
> rm ~/.ssh/known_hosts

I tried deleting this file again. It won't work with or without it.
Thanks for the explanation.

> or
> ssh -o UserKnownHostsFile=/dev/null server-name
> Of course this defeats half of the security of SSH
> 4. A better solution is to add the correct host key to the
> known hosts file.

This happened automatically when I went to any new URL as root. I was
asked first whether to add that key. User was not asked whether to add a
key and may not have the right to. Do I need to change permissions on
the known_hosts file from /root/.ssh to use it as user?

> I have simplified this somewhat but perhaps not too significantly!
>
> Hope this helps,

Yes, I am starting to understand ssh, but not lpr ;=(

Running Linux lists a lot of permissions for printing-related files and
user seems to always have more permissions than root. I have been
changing permissions on one or two files at a time in /var/spool. Maybe I
need to change several at once?

> > 3. Since printing by "root" would lead (possibly
> > inadvertently) to the execution of these "programs" it is
> > often disabled.
>
> How is it disabled?

In one of (at least) three ways that I know of:

a. When lpr is run it checks whether it is being run
as root and in that case it just drops the job.
b. When lpr is run it checks whether it is being run
as root and in that case it refuses to use any filters.
c. The filters themselves check to see whether they are
being run as root and in that case they refuse to run.

I believe that (b) is quite common.

> But I am setting up small linuxes for friends who
> just want to print formatted files directly with a wordprocessor or
> browser, and it is complicated to make our linux work as user for every
> program when it is designed to be used as root only.

As Ben has already pointed out: Running everything as root especially
when the users are non-technical is probably not very safe.

> This happened automatically when I went to any new URL as root. I was
> asked first whether to add that key. User was not asked whether to add a
> key and may not have the right to. Do I need to change permissions on
> the known_hosts file from /root/.ssh to use it as user?

Certainly, if the user wants to write to that file. The SSH client
pobably wants to do this on behalf of the user if the user home
directory is set as /root.

If you separated out these issues it might be easier to diagnose and
solve the problems. (a) and (b) may be related but I tend to think
that this is a configuration/program issue rather than a permissions
issue. There may be a relation between (a) and (c) but again this
may be because the $HOME directory of the user is configured in a
non-standard way. (b) and (c) are most probably[*] un-related.

However, here is a general remark. Given the security-related history
of "lpr" and the security-related use of "ssh", both are probably
quite finicky about file permissions and access and will often refuse
to run or give dire warnings (in their default configuration) if they
find something "screwy" like unusual permissions on a directory or
file.

Regards,

Kapil.
[*] I originally wrote "certainly" but the mathematician in me
prevailed to make it "most probably"
--

> Hello,
>
> On Thu, 25 Jan 2007, Sindi Keesan wrote:
>>> 3. Since printing by "root" would lead (possibly
>>> inadvertently) to the execution of these "programs" it is
>>> often disabled.
>>
>> How is it disabled?
>
> In one of (at least) three ways that I know of:
> a. When lpr is run it checks whether it is being run
> as root and in that case it just drops the job.
> b. When lpr is run it checks whether it is being run
> as root and in that case it refuses to use any filters.
> c. The filters themselves check to see whether they are
> being run as root and in that case they refuse to run.
> I believe that (b) is quite common.

I hope it is just a permissions problem.

>
>> But I am setting up small linuxes for friends who
>> just want to print formatted files directly with a wordprocessor or
>> browser, and it is complicated to make our linux work as user for every
>> program when it is designed to be used as root only.
>
> As Ben has already pointed out: Running everything as root especially
> when the users are non-technical is probably not very safe.

I will try to set them up as user. But I can always reinstall the 40MB of
software if they break it (and keep a backup .tgz of it on their drive in
a DOS partition).

>> This happened automatically when I went to any new URL as root. I was
>> asked first whether to add that key. User was not asked whether to add a
>> key and may not have the right to. Do I need to change permissions on
>> the known_hosts file from /root/.ssh to use it as user?
>
> Certainly, if the user wants to write to that file. The SSH client
> pobably wants to do this on behalf of the user if the user home
> directory is set as /root.

known_hosts is -rw------- 1 root root
I copied it to /home/user/.ssh
I did a chown known_hosts user and now my error message is

I do not need to run ssh as user, I was just using it as an example of how
much more complicated it is to make things work as user in our
distribution.

> I still feel that you are conflating a lot of different issues:
>
> a. Permissions (Running as root vs. running as user.)

Not necessary if I can get lpr to run as root.

> b. Problems with lpr.

This is what I wanted help with.

> c. Problems with ssh.
>
> If you separated out these issues it might be easier to diagnose and
> solve the problems. (a) and (b) may be related but I tend to think
> that this is a configuration/program issue rather than a permissions
> issue. There may be a relation between (a) and (c) but again this
> may be because the $HOME directory of the user is configured in a
> non-standard way. (b) and (c) are most probably[*] un-related.

> However, here is a general remark. Given the security-related history
> of "lpr" and the security-related use of "ssh", both are probably
> quite finicky about file permissions and access and will often refuse
> to run or give dire warnings (in their default configuration) if they
> find something "screwy" like unusual permissions on a directory or
> file.

Lots of things in our distribution are screwy. But it boots in 15 seconds
and works well (once you get it working) on old hardware. I am trying to
make the old hardware work for friends who want to print webpages.

> On Thu, 25 Jan 2007, Kapil Hari Paranjape wrote:
> >I understand that you want to avoid doing things as "root" and prefer
> >to do things as "user". That is a very good thing
>
> No, I want to do everything as root (which is how our distributions were
> designed to work) and nothing as user, which is much more complicated to
> set up. Right now I need to suid user to print with lpr.

But you don't need a password to do that. So you can just do something
like

alias lpr 'su user lpr'

and your problem is solved!

As root you can do "su user" whenever you want to do less powerful
things.

As user you can do "sudo" whenever you want to do more powerful
things.

The difference is like that between a democracy, where the chief
executive can occasionally assume emergency powers, and a monarchy,
where the ruler sometimes travels "incognito" to gauge the mood of the
people.

The author of Basiclinux suggested making a script ps-print and filling it
in as 'printer program' in Opera instead of using 'lp' or another filter
used by printcap, and printing with gs but without lpr (or su, or user, or
adduser, or changes in permissions). It works.

> The author of Basiclinux suggested making a script ps-print and filling it
> in as 'printer program' in Opera instead of using 'lp' or another filter
> used by printcap, and printing with gs but without lpr (or su, or user, or
> adduser, or changes in permissions). It works.
>
> gs -q -dSAFER -sDEVICE=deskjet -r300x300 -sPAPERSIZE=letter -sOutputFile=-
> - > /dev/lp0
>
> It worked (even with a missing space after letter).

This may handle printing from Opera, but I doubt that it will handle the
general problem of printing as root. E.g., printing an image or a PDF
isn't going to work with the above method.

> On Thu, Jan 25, 2007 at 11:38:55PM -0500, Sindi Keesan wrote:
>> The author of Basiclinux suggested making a script ps-print and filling it
>> in as 'printer program' in Opera instead of using 'lp' or another filter
>> used by printcap, and printing with gs but without lpr (or su, or user, or
>> adduser, or changes in permissions). It works.
>>
>> gs -q -dSAFER -sDEVICE=deskjet -r300x300 -sPAPERSIZE=letter -sOutputFile=-
>> - > /dev/lp0

> This may handle printing from Opera, but I doubt that it will handle the
> general problem of printing as root. E.g., printing an image or a PDF
> isn't going to work with the above method.

It printed a PDF file with xpdf when I entered ps-print as the printer
command (rather than lp). Should work with Abiword similarly because
Abiword converts to ps to print.

I print images with netpbm's pbmtolj after converting to pbm format. (I
print color photos at the store on rare occasions.) But xv probably also
converts to ps so would work with this script.

I just compiled convertors for Excel and Powerpoint formats to HTML and
Opera can print HTML (via ps). Abiword can display/print RTF. To print
WORD files I used pdfonline (via lynx at the shell account where I get
mail) to convert to pdf first, and then downloaded the pdf files from my
shell account, after Antiword could not handle complex formatting that I
was required to preserve.

Antiword does a perfect job with other character sets in WORD, which WORD
cannot export properly to text.

>
> cat filename > /dev/lp0 works for root, so does gs used CLI without lpr,
> or pbmtolj from netpbm.
>
> lpr used from Opera, lpr filename or even cat filename | lpr work for
> 'user', but for root they do not send anything to the print queue (lpq
> shows no entries). No error messages. I just get another prompt.
>
> Permissions for lpr are unchanged from Slackware 7.1:
> -r-s--s--x 1 root lp
> (Must be s to print as user).
>
> lp0 is crw-r--r-- 1 root root

At least a little different - although that's not necessarily the cause.

> chmod a+w lp0 did not help (crw-rw-rw-) nor did chmod 777 (crwxrwxrwx).
> lp0 works for root except with lpr.
>
> In order to work as user I have had to change permissions on /dev/null
> (w), ttyp* and ptyp* (rw), set suid XVESA and anything svgalib (links2,
> zgv, gs), make /var/lock writeable, make any scripts suid or executable as
> user, etc. An education. I can now suid user (or login as user), dial,
> load Xvesa, icewm, and rxvt and Opera and print as user.

It sounds like BasicLinux still needs a bit of refining.

> ssh still says 'host key verification failed' though telnet works.

The two are, of course, unrelated.

> I would like to quit struggling with permissions every time I try to work
> as user, and be able to print as root. I do know I should not work as
> root online but I am not running any servers while online with my modem.
> If you scold me please explain why.

No scolding, but just a note: as root, one tiny mistype is all it takes
to wipe out your system. As well, any programs you execute that create
an externally-accessible network socket (are you sure you know what all
of those are?) are running with root privileges - meaning that if
someone manages to crack one, they 0wn your system.

So, I'm not going to say "don't do that". I'm just going to note that
the cost of doing so can be rather high.

> Does lpr depend on some other program, library, or device that I need to
> change permissions for?

Maybe - or maybe not, depending on how yours is configured and what
version of "lpr" you're using (in theory, you can minimize external
processing by trying to print a plain text file, e.g., '/etc/passwd'.)
In any case, it's a question that you yourself can answer by executing
"lpr" with "strace", something like this:

> > I would like to quit struggling with permissions every time I try to work
> > as user, and be able to print as root. I do know I should not work as
> > root online but I am not running any servers while online with my modem.
> > If you scold me please explain why.
>
> No scolding, but just a note: as root, one tiny mistype is all it takes
> to wipe out your system. As well, any programs you execute that create
> an externally-accessible network socket (are you sure you know what all
> of those are?) are running with root privileges - meaning that if
> someone manages to crack one, they 0wn your system.
>
> So, I'm not going to say "don't do that". I'm just going to note that
> the cost of doing so can be rather high.

Also, I'd like to point out that the Unix world was ecstatic about the
rise of CUPS specifically because it allowed us to finally get rid of
lpd / lprNG, which was hopeless spaghetti code, derived from ancient BSD
efforts among nameless student coders at University of California at
Berkeley. One of the worst of the many bad aspects of lpd / lprNG is
that its security profile and history were and are utterly dreadful.

Using either BSD lpd or its lprNG offshoot is, by itself, cause for
alarm. Using it on a machine where you purposefully do everything as
root seems to be not only courting catastrophe but also sending out
formal catastrophe invitations and publishing announcements in the
local catastrophe newsletter.

--
"Is it not the beauty of an asynchronous form of discussion that one can go and
make cups of tea, floss the cat, fluff the geraniums, open the kitchen window
and scream out it with operatic force, volume, and decorum, and then return to
the vexed glowing letters calmer of mind and soul?" -- The Cube, forum3000.org

> On Thu, 25 Jan 2007, Benjamin A. Okopnik wrote:
>
> >No scolding, but just a note: as root, one tiny mistype is all it takes
> >to wipe out your system. As well, any programs you execute that create
> >an externally-accessible network socket (are you sure you know what all
> >of those are?) are running with root privileges - meaning that if
> >someone manages to crack one, they 0wn your system.
> >
> >So, I'm not going to say "don't do that". I'm just going to note that
> >the cost of doing so can be rather high.
>
> I have the same system on several computers so can easily restore it.
> My super-duper full-size linux is about 1GB including a lot of music and
> photos and kernel source code. The little one about 100MB.

That's not exactly the point. Skript kiddies aren't interested in
destroying your system - they want your resources. E.g., once they crack
in, they'll set up a mail relay on your machine and use it to broadcast
spam - this is, in fact, how most spam is propagated these days.

> >>Does lpr depend on some other program, library, or device that I need to
> >>change permissions for?
> >
> >Maybe - or maybe not, depending on how yours is configured and what
> >version of "lpr" you're using (in theory, you can minimize external
> >processing by trying to print a plain text file, e.g., '/etc/passwd'.)
> >In any case, it's a question that you yourself can answer by executing
> >"lpr" with "strace", something like this:
> >
> >``
> >ben at Fenrir:~$ su -
> >Password:
> >root at Fenrir:~# strace -o lpr.out /usr/bin/lpr file
> >''
>
> I had to download the strace.tgz package first. Running it from a
> temporary directory without installing the package.
>
> ptrace: umoven: Input/output error (four lines of this).
>
> But it made lpr.out, a couple pages or more.
>
> >After that, read the resulting file ('lpr.out', in the above case) and
> >see where things failed. If you need a baseline for comparison, you can
> >always run the above "strace" line as a non-root user.
>
> I can't make much sense of the results.
> See attached lpr.out (root) and lpr2.out (user).

I'm afraid you forgot to attach them - but attaching large files to list
email is a bad idea anyway. Put them up somewhere (if you don't have web
space of your own, you can use, e.g., http://www.filewind.com/) and send
us the URLs.

>>
>> I have the same system on several computers so can easily restore it.
>> My super-duper full-size linux is about 1GB including a lot of music and
>> photos and kernel source code. The little one about 100MB.
>
> That's not exactly the point. Skript kiddies aren't interested in
> destroying your system - they want your resources. E.g., once they crack
> in, they'll set up a mail relay on your machine and use it to broadcast
> spam - this is, in fact, how most spam is propagated these days.
>

Please explain how they can get into my linux system when I am dialed in
via modem, and set up a mail relay that will work when I don't have
standard mailing programs. We use a 76K 'pmail' which is nonstandard.
I am not running any telnet or ssh servers. Once in a while pure-ftpd or
mini-httpd.

95% of the time I use the internet via ssh to a shell account (or direct
dial to it).

Nobody has hijacked my system in four years. Unless there are some hidden
files I have not run across.

If it were in fact safer to use ssh or browsers as 'user', I would figure
out the permissions for that but probably dial as 'root' first. Is that
okay?

>> I can't make much sense of the results.
>> See attached lpr.out (root) and lpr2.out (user).
>
> I'm afraid you forgot to attach them - but attaching large files to list
> email is a bad idea anyway. Put them up somewhere (if you don't have web
> space of your own, you can use, e.g., http://www.filewind.com/) and send
> us the URLs.

> Nobody has hijacked my system in four years. Unless there are some hidden
> files I have not run across.

Whatever works for you is of course what you should choose.

The following is a suggestion not to you specifically but to all
those who ask questions on lists like this one.

Generally speaking the more "finely localised and tuned" the system,
the harder it is to find someone to diagnose its problems over
e-mail/IRC/Usenet.

For example, someone could make some tweaks to the Linux kernel
so that it ignores access control (both for filesystems and
processes) entirely. A system built with this "feature" might even
be significantly smaller than the existing system as a number of
utilities and library calls would be eliminated. But I think that a
question about such a system could not really be called a "GNU/Linux
system question" as most people answering would be mislead by this
title.

I believe (and it is only a belief since I have not actually tried to
build such a system recently[*]) that it is possible to take "standard"
components of a "standard" distribution like Debian and build a
"small" distribution which is standard-enough so that questions about
it would be answerable by a large number of people and which is small
enough to boot on old hardware.

Regards,

Kapil.

[*] The last time I built such a system was in 1996 when we had a
single floppy boot of an "Xterm on a 386" --- it was built using Debian
0.9x.
--

I'm sure this has been suggested and tried but it would be nice to
know the outcome.

"Can't we just add the user after booting the system?"

> lpr used from Opera, lpr filename or even cat filename | lpr work for
> 'user', but for root they do not send anything to the print queue (lpq
> shows no entries). No error messages. I just get another prompt.

The problem may be that "root" and other system accounts are
prevented from printing. I know that this is possible in some print
systems like LPRng for example. There is ".perm" file that lists
those you are allowed/disallowed.

> ssh still says 'host key verification failed' though telnet works.

This may mean that you have the wrong key in your $HOME/.ssh/known_hosts
or /etc/ssh/known_hosts. You might be able to remove the offending
entry from this file with

ssh-keygen -R "the name of the host you are trying to connect to"

Though all the problems that you list are in one sense or another
"permission problems" they seem to originate from different causes.

>Courtesy copy, just in case you're not on the mailing list (though you
>probably are).

This is the only copy I got of this mail from rick. I am not on a TAG
mailing list.

>
>----- Forwarded message from rick -----
>
>Date: Thu, 25 Jan 2007 13:34:39 -0800
>To: tag at lists.linuxgazette.net
>Subject: Re: [TAG] lpr works for user not root in Basiclinux 2.1
>
>Quoting Benjamin A. Okopnik (ben at linuxgazette.net):
>
>>>I would like to quit struggling with permissions every time I try to work
>>>as user, and be able to print as root. I do know I should not work as
>>>root online but I am not running any servers while online with my modem.
>>>If you scold me please explain why.
>>
>>No scolding, but just a note: as root, one tiny mistype is all it takes
>>to wipe out your system. As well, any programs you execute that create
>>an externally-accessible network socket (are you sure you know what all
>>of those are?) are running with root privileges - meaning that if
>>someone manages to crack one, they 0wn your system.
>>
>>So, I'm not going to say "don't do that". I'm just going to note that
>>the cost of doing so can be rather high.

I don't even know what a network socket is. Nobody in their right mind
would want my system. The software is 8 years out of date (the hardware
is older than that) and the connection is dialup. Should I be worried
anyway?

>Also, I'd like to point out that the Unix world was ecstatic about the
>rise of CUPS specifically because it allowed us to finally get rid of
>lpd / lprNG, which was hopeless spaghetti code, derived from ancient BSD
>efforts among nameless student coders at University of California at
>Berkeley. One of the worst of the many bad aspects of lpd / lprNG is
>that its security profile and history were and are utterly dreadful.

Do I need security to print on my own single-user system?

>Using either BSD lpd or its lprNG offshoot is, by itself, cause for
>alarm. Using it on a machine where you purposefully do everything as
>root seems to be not only courting catastrophe but also sending out
>formal catastrophe invitations and publishing announcements in the
>local catastrophe newsletter.

No catastrophes have occurred among any of our distribution's users yet
that I know of, in 4 years or so, apart from hardware failures. I have
the same files on several computers in case I need to restore everything.

CUPS is said to be useful in a local network that has both linux and
Windows computers. My win98 hard drive died a while ago and I never
printed with Windows.

If I want to switch printers I use a printer switch box, and the deskjet
driver works for both the deskjet and the laserjet. I use the dot-matrix
printer only with plain text files (cat textfile > /dev/lp0 as root). I
print images with pbmtolj (netpbm), as root.

The people we are giving 200MHz computers to don't have networks. But
they do need to print formatted papers for school, and webpages.

That's pretty much my point. The majority of those who run their
machines as root literally have no idea of how exposed and vulnerable
they are.

Sockets and ports are methods by which local and remote clients can
connect to your machine. Try running 'netstat'; this will show you a
list of your currently-open sockets and ports.

> Nobody in their right mind
> would want my system. The software is 8 years out of date (the hardware
> is older than that) and the connection is dialup. Should I be worried
> anyway?

See my earlier point about resources. There are Russian and Polish
companies (and probably lots of others, but those seem to be at the
forefront) who will sell you their spam-distribution services and boast
of "thousands of 'captured' machines" that they use for the purpose.
It's a popular dodge for spammers these days, since it essentially
counters IP blocking.

> >Also, I'd like to point out that the Unix world was ecstatic about the
> >rise of CUPS specifically because it allowed us to finally get rid of
> >lpd / lprNG, which was hopeless spaghetti code, derived from ancient BSD
> >efforts among nameless student coders at University of California at
> >Berkeley. One of the worst of the many bad aspects of lpd / lprNG is
> >that its security profile and history were and are utterly dreadful.
>
> Do I need security to print on my own single-user system?

I don't know how to emphasize this enough, but given that a very large
percentage of system break-ins in the past occurred via 'lpr/lprng', the
answer is a very definite "YES".

> The people we are giving 200MHz computers to don't have networks. But
> they do need to print formatted papers for school, and webpages.
>
> I don't think I need CUPS.

Given the above, why are you using a print server/scheduler at all? I
ran my system with nothing more than 'magicfilter' and a script to send
it to the appropriate filter for a couple of years when I was in a
similar situation, and it worked fine.

> On Fri, Jan 26, 2007 at 02:09:35AM -0800, Sindi Keesan wrote:
>>
>> I don't even know what a network socket is.
>
> That's pretty much my point. The majority of those who run their
> machines as root literally have no idea of how exposed and vulnerable
> they are.
>
> Sockets and ports are methods by which local and remote clients can
> connect to your machine. Try running 'netstat'; this will show you a
> list of your currently-open sockets and ports.

bash: netstat: command not found

You are making too many assumptions about my linux ;=)

>> Nobody in their right mind
>> would want my system. The software is 8 years out of date (the hardware
>> is older than that) and the connection is dialup. Should I be worried
>> anyway?

> See my earlier point about resources. There are Russian and Polish
> companies (and probably lots of others, but those seem to be at the
> forefront) who will sell you their spam-distribution services and boast
> of "thousands of 'captured' machines" that they use for the purpose.
> It's a popular dodge for spammers these days, since it essentially
> counters IP blocking.

I thought they went after broadband. And Windows. How exactly would they
attack a linux machine using dialup internet, without me noticing?

I do most of my browsing and emailing via a shell account to which I ssh
as root. Am I still vulnerable to attack?

>>> Also, I'd like to point out that the Unix world was ecstatic about the
>>> rise of CUPS specifically because it allowed us to finally get rid of
>>> lpd / lprNG, which was hopeless spaghetti code, derived from ancient BSD
>>> efforts among nameless student coders at University of California at
>>> Berkeley. One of the worst of the many bad aspects of lpd / lprNG is
>>> that its security profile and history were and are utterly dreadful.
>>
>> Do I need security to print on my own single-user system?
>
> I don't know how to emphasize this enough, but given that a very large
> percentage of system break-ins in the past occurred via 'lpr/lprng', the
> answer is a very definite "YES".

I had not been using lpr until now and now have a script to print with
using gs directly, tested in Opera and xpdf.

>
>> The people we are giving 200MHz computers to don't have networks. But
>> they do need to print formatted papers for school, and webpages.
>>
>> I don't think I need CUPS.
>
> Given the above, why are you using a print server/scheduler at all? I
> ran my system with nothing more than 'magicfilter' and a script to send
> it to the appropriate filter for a couple of years when I was in a
> similar situation, and it worked fine.

I don't know what magicfilter is, but I have a script that will let me
print from within X programs now, and don't even need a filter. A few
years ago people using our distribution worked out how to use lpr and
printcap, but there is no need for them now. I guess I should stop being
curious why lpr won't work for root.

Now I need to figure out why your email ended up in my spam folder....

> On Fri, 26 Jan 2007, Benjamin A. Okopnik wrote:
>
> >On Fri, Jan 26, 2007 at 02:09:35AM -0800, Sindi Keesan wrote:
> >>
> >>I don't even know what a network socket is.
> >
> >That's pretty much my point. The majority of those who run their
> >machines as root literally have no idea of how exposed and vulnerable
> >they are.
> >
> >Sockets and ports are methods by which local and remote clients can
> >connect to your machine. Try running 'netstat'; this will show you a
> >list of your currently-open sockets and ports.
>
> bash: netstat: command not found
>
> You are making too many assumptions about my linux ;=)

Perhaps you're making too few assumptions about the necessary tools that
belong on a Linux box.

> >> Nobody in their right mind
> >>would want my system. The software is 8 years out of date (the hardware
> >>is older than that) and the connection is dialup. Should I be worried
> >>anyway?
>
> >See my earlier point about resources. There are Russian and Polish
> >companies (and probably lots of others, but those seem to be at the
> >forefront) who will sell you their spam-distribution services and boast
> >of "thousands of 'captured' machines" that they use for the purpose.
> >It's a popular dodge for spammers these days, since it essentially
> >counters IP blocking.
>
> I thought they went after broadband. And Windows. How exactly would they
> attack a linux machine using dialup internet, without me noticing?

None of these attacks would be problems if the user on the system
noticed when they happened. They happen without you noticing *by
definition*. As to how, the answer is "via ports and sockets". For a
longer answer, I teach a five-day security course for Sun Microsystems
on that, $3495 per student. Or you could study up via the resources
available in many places on the Net.

> I do most of my browsing and emailing via a shell account to which I ssh
> as root. Am I still vulnerable to attack?

Are we still talking about your system, or did you just introduce
another one into the equation? Every open port and socket that you have
is a way for other systems to connect to yours. Each of them has its own
pros and cons. I couldn't begin to estimate what your exposure is,
except that everything I've heard from you so far tells me that you're
pretty vulnerable.

> >>The people we are giving 200MHz computers to don't have networks. But
> >>they do need to print formatted papers for school, and webpages.
> >>
> >>I don't think I need CUPS.
> >
> >Given the above, why are you using a print server/scheduler at all? I
> >ran my system with nothing more than 'magicfilter' and a script to send
> >it to the appropriate filter for a couple of years when I was in a
> >similar situation, and it worked fine.
>
> I don't know what magicfilter is, but I have a script that will let me
> print from within X programs now, and don't even need a filter. A few
> years ago people using our distribution worked out how to use lpr and
> printcap, but there is no need for them now. I guess I should stop being
> curious why lpr won't work for root.

You can find out about "magicfilter" by searching for it, and you have a
script that will print some things but not others. I've been answering
the question that you asked initially; since you now appear to have
changed the question in the middle of the discussion, and since I'm not
interested in providing ongoing support for every possible problem in
your system, I'm going to call my end of it finished. Good luck.

>>> Sockets and ports are methods by which local and remote clients can
>>> connect to your machine. Try running 'netstat'; this will show you a
>>> list of your currently-open sockets and ports.
>>
>> bash: netstat: command not found
>>
>> You are making too many assumptions about my linux ;=)
>
> Perhaps you're making too few assumptions about the necessary tools that
> belong on a Linux box.

I did not create this distribution. Why is netstat necessary? Can I look
in some directory under /proc instead? (I do this instead of lspci).

>
>>>> Nobody in their right mind
>>>> would want my system. The software is 8 years out of date (the hardware
>>>> is older than that) and the connection is dialup. Should I be worried
>>>> anyway?
>>
>>> See my earlier point about resources. There are Russian and Polish
>>> companies (and probably lots of others, but those seem to be at the
>>> forefront) who will sell you their spam-distribution services and boast
>>> of "thousands of 'captured' machines" that they use for the purpose.
>>> It's a popular dodge for spammers these days, since it essentially
>>> counters IP blocking.
>>
>> I thought they went after broadband. And Windows. How exactly would they
>> attack a linux machine using dialup internet, without me noticing?
>
> None of these attacks would be problems if the user on the system
> noticed when they happened. They happen without you noticing *by
> definition*. As to how, the answer is "via ports and sockets". For a
> longer answer, I teach a five-day security course for Sun Microsystems
> on that, $3495 per student. Or you could study up via the resources
> available in many places on the Net.

Can you suggest an online primer on ports and sockets?

>> I do most of my browsing and emailing via a shell account to which I ssh
>> as root. Am I still vulnerable to attack?

> Are we still talking about your system, or did you just introduce
> another one into the equation? Every open port and socket that you have
> is a way for other systems to connect to yours. Each of them has its own
> pros and cons. I couldn't begin to estimate what your exposure is,
> except that everything I've heard from you so far tells me that you're
> pretty vulnerable.

I boot into DOS, thence with loadlin into linux, then dial an ISP, and
then ssh to a shell account. Or dial directly to that shell account and
ssh to another shell account. I can kermit files from the second shell
account to my own computer. What part of this setup is vulnerable and why
has nothing bad happened in four years? I am not running any servers
(even lpd) on my own computer that I know of. Is Xvesa a server? I
think it uses a socket.

>> I don't know what magicfilter is, but I have a script that will let me
>> print from within X programs now, and don't even need a filter. A few
>> years ago people using our distribution worked out how to use lpr and
>> printcap, but there is no need for them now. I guess I should stop being
>> curious why lpr won't work for root.
>
> You can find out about "magicfilter" by searching for it, and you have a
> script that will print some things but not others. I've been answering
> the question that you asked initially; since you now appear to have
> changed the question in the middle of the discussion, and since I'm not
> interested in providing ongoing support for every possible problem in
> your system, I'm going to call my end of it finished. Good luck.

I can print any format that I need to now, with gs or netpbm.

Since I no longer need to print as root with lpr it is indeed time to drop
the original discussion. Thanks for all your help, and for pointing out
that lpr is a security risk. I will read online about linux and security
and maybe ssh as user once I figure out how.

> On Fri, Jan 26, 2007 at 01:18:56PM -0500, Sindi Keesan wrote:
> > I thought they went after broadband. And Windows. How exactly would
> > they attack a linux machine using dialup internet, without me noticing?

They would attack a dialup machine in exactly the same way they would attack a
broadband machine. How would they know your machine was on dialup? It's just
another IP address to them.

Being on Linux is no guarantee either. There are enough Linux servers out
there with a lot of bandwidth to be valuable targets and the programs that go
scanning for vulnerable machines neither know, nor care, that yours is a puny
little 200 MHz machine on dialup.

How would they attack without you noticing? Well, how would you notice? Are
you even looking?

Do you monitor the logs? Do you run chkrootkit regularly? Do you monitor
portscans?

>> On Fri, Jan 26, 2007 at 01:18:56PM -0500, Sindi Keesan wrote:
>>> I thought they went after broadband. And Windows. How exactly would
>>> they attack a linux machine using dialup internet, without me noticing?
>
> They would attack a dialup machine in exactly the same way they would attack a
> broadband machine. How would they know your machine was on dialup? It's just
> another IP address to them.

Okay. A friend said they could sniff my packets for my login and
password. But how would they put any files onto my machine? I am not
running lpd, telnetd, ftpd or even httpd. Can they transfer files when I
simply run pppd and ssh or lynx?

> Being on Linux is no guarantee either. There are enough Linux servers out
> there with a lot of bandwidth to be valuable targets and the programs that go
> scanning for vulnerable machines neither know, nor care, that yours is a puny
> little 200 MHz machine on dialup.
>
> How would they attack without you noticing? Well, how would you notice? Are
> you even looking?
>
> Do you monitor the logs? Do you run chkrootkit regularly? Do you monitor
> portscans?

/var/log/ shows which packages were installed not portscan info.
We do not have chrootkit.

I found a Wiki-type entry about portscan, a series of probes sent to one
or more ports of a target system looking for information. Most linux
distributions don't include the tools to monitor them. (Not just ours).

We have an nmap add-on for scanning hosts on the network and determining
which services they are running. Downloaded it. No documentation.
101 pages of man page online. I don't understand much of it.

On or around Saturday 27 January 2007 15:16, Sindi Keesan reorganised a bunch
of electrons to form the message:

> Okay. A friend said they could sniff my packets for my login and
> password. But how would they put any files onto my machine? I am not
> running lpd, telnetd, ftpd or even httpd. Can they transfer files when I
> simply run pppd and ssh or lynx?

If your ssh package provides scp or sftp, then yes, if they've cracked your
machine they would be able to copy stuff onto it.

> > How would they attack without you noticing? Well, how would you notice?
> > Are you even looking?
> >
> > Do you monitor the logs? Do you run chkrootkit regularly? Do you monitor
> > portscans?
>
> /var/log/ shows which packages were installed not portscan info.
> We do not have chrootkit.

It sounds like you wouldn't notice.

> I found a Wiki-type entry about portscan, a series of probes sent to one
> or more ports of a target system looking for information. Most linux
> distributions don't include the tools to monitor them. (Not just ours).
>
> We have an nmap add-on for scanning hosts on the network and determining
> which services they are running. Downloaded it. No documentation.
> 101 pages of man page online. I don't understand much of it.
>
> nmap -A -T4 127.0.0.1 (localhost)
> All 1663 scanned ports are closed.

> On or around Saturday 27 January 2007 15:16, Sindi Keesan reorganised a bunch
> of electrons to form the message:

>> Okay. A friend said they could sniff my packets for my login and
>> password. But how would they put any files onto my machine? I am not
>> running lpd, telnetd, ftpd or even httpd. Can they transfer files when I
>> simply run pppd and ssh or lynx?

> If your ssh package provides scp or sftp, then yes, if they've cracked your
> machine they would be able to copy stuff onto it.

My 'package' consists of ssh.gz and ssh.1 (man page).

>> We have an nmap add-on for scanning hosts on the network and determining
>> which services they are running. Downloaded it. No documentation.
>> 101 pages of man page online. I don't understand much of it.
>>
>> nmap -A -T4 127.0.0.1 (localhost)
>> All 1663 scanned ports are closed.
>
> I'm no expert either, but I would say that's encouraging.

The author of our distribution said to try this while running X (which is
a server) and port 6000 was then open. I don't normally run X while I am
online. Should I unload X before using ssh or lynx from a console? He
advises using our X browser Opera as user. I could also load Xvesa as
user.

> The author of our distribution said to try this while running X (which is
> a server) and port 6000 was then open.

Please see my separate reply to Neil. Starting up the X11 server makes
port 6000 and adjoining ports be reachable from localhost.

> I don't normally run X while I am online.

That's really rather pointless as a security measure, except in the
sesne of minimising the amount of code you're running with root
authority -- but you'd be smarter just not to run X11 as root at all.

> > > Do you monitor the logs? Do you run chkrootkit regularly? Do you
> > > monitor portscans?
> >
> > /var/log/ shows which packages were installed not portscan info. We
> > do not have chrootkit.
>
> It sounds like you wouldn't notice.

Neil, chkrootkit (and/or rkhunter) is probably a good thing to suggest
as a retroactive measure for someone like Sindi who might have reason to
worry about system security. Although I have problems (to be detailed
below) with its general approach, your suggestion is commendable in this
(limited) context.

Sindi, one might describe chkrootkit / rkhunter (both of which you can
easily find and download) as attempts at "paranoia in a can" -- tools
that search your filesystems for patterns of files that typically exist
as artifacts/after-effects of intruder breakin activity, e.g.,
replacements of system facilities with trojaned equivalents, malware
installed that keeps UDP-based backdoor methods of re-entry open, etc.

The problem with enumerating badness is that it comes in vastly too many
varieties, and so you end up knowing only that known, i.e., sloppy and
incompetent badness has been found. Which is better than nothing -- but
should make one wonder if we can't do better.

I would suggest there definitely is -- but that the superior tools in
that area are prospective-looking tools you need to install / configure
when the system is new or at least healthy, i.e. file-based intrusion
detection systems (IDSes), such as AIDE, Prelude-IDS, Samhain, etc.

It would be good if future distros installed with AIDE configured and
issuing daily reports by default -- and less reliance on chkrootkit /
rkhunter, which are in the final analysis just glorified virus-checkers,
and we can sure do better than that. There are an increasing number
of write-ups about how to configure AIDE manually, e.g.,
http://www.debuntu.org/intrusion-detection-with-aide .

My point about chkrootkit/rkhunter as opposed to IDSes in Sindi's
particular situation is that IDSes require a normal-operation baseline
for configuration. If you're already worried about intrusion, it's too
late to set one up.

> > We have an nmap add-on for scanning hosts on the network and determining
> > which services they are running. Downloaded it. No documentation.
> > 101 pages of man page online. I don't understand much of it.
> >
> > nmap -A -T4 127.0.0.1 (localhost)
> > All 1663 scanned ports are closed.
>
> I'm no expert either, but I would say that's encouraging.

Yes. That's a TCP-port scan of localhost (only one of several major
scan modes nmap can do). Ordinarily, I would caution that nmap must
always be run from a nearby-on-network node (which, yes, could be
talking to one's temporary dial-up IP from elsewhere), and never used
by a host to scan itself, because the report would include local-only
network services, which obviously cannot be attacked from remote
locations. (Thus, you tend to think you have remote vulnerabilities
that really don't exist. This is a very common error.)

However, in this case, Sindi's results suggest there are zero
TCP-based network services at all, so whether they're strictly local or
not is entirely moot.

For the record, this is how I tend to do TCP-service, UDP-service, and
TCP ACK Ping scans, respectively, using nmap:

> Quoting Neil Youngman (ny at youngman.org.uk):
>
>>>> Do you monitor the logs? Do you run chkrootkit regularly? Do you
>>>> monitor portscans?
>>>
>>> /var/log/ shows which packages were installed not portscan info. We
>>> do not have chrootkit.
>>
>> It sounds like you wouldn't notice.
>
> Neil, chkrootkit (and/or rkhunter) is probably a good thing to suggest
> as a retroactive measure for someone like Sindi who might have reason to
> worry about system security. Although I have problems (to be detailed
> below) with its general approach, your suggestion is commendable in this
> (limited) context.
>
> Sindi, one might describe chkrootkit / rkhunter (both of which you can
> easily find and download) as attempts at "paranoia in a can" -- tools
> that search your filesystems for patterns of files that typically exist
> as artifacts/after-effects of intruder breakin activity, e.g.,
> replacements of system facilities with trojaned equivalents, malware
> installed that keeps UDP-based backdoor methods of re-entry open, etc.
>
> Taking the longer view for a moment, both tools exemplify a losing
> strategy that Marcus J. Ranum dubs "enumerating badness" in his essay
> "The Six Dumbest Ideas in Computer Security" -- with that concept
> qualifying as one of the six:
> http://www.ranum.com/security/computer_security/editorials/dumb/
>
> The problem with enumerating badness is that it comes in vastly too many
> varieties, and so you end up knowing only that known, i.e., sloppy and
> incompetent badness has been found. Which is better than nothing -- but
> should make one wonder if we can't do better.
>

But if I run chrootkit and it finds nothing, and I am not running any
network services when I go online, can I continue as root without
worrying? I have switched Opera to run as user (in the menu) because it
uses an X server. After inserting modules and dialing as root.

> I would suggest there definitely is -- but that the superior tools in
> that area are prospective-looking tools you need to install / configure
> when the system is new or at least healthy, i.e. file-based intrusion
> detection systems (IDSes), such as AIDE, Prelude-IDS, Samhain, etc.
>
> It would be good if future distros installed with AIDE configured and
> issuing daily reports by default -- and less reliance on chkrootkit /
> rkhunter, which are in the final analysis just glorified virus-checkers,
> and we can sure do better than that. There are an increasing number
> of write-ups about how to configure AIDE manually, e.g.,
> http://www.debuntu.org/intrusion-detection-with-aide .
>
> My point about chkrootkit/rkhunter as opposed to IDSes in Sindi's
> particular situation is that IDSes require a normal-operation baseline
> for configuration. If you're already worried about intrusion, it's too
> late to set one up.
>

I was told if I have no open ports I don't need to worry. I ran telnetd
once for 30 seconds on another computer.

>>> We have an nmap add-on for scanning hosts on the network and determining
>>> which services they are running. Downloaded it. No documentation.
>>> 101 pages of man page online. I don't understand much of it.
>>>
>>> nmap -A -T4 127.0.0.1 (localhost)
>>> All 1663 scanned ports are closed.
>>
>> I'm no expert either, but I would say that's encouraging.
>
> Yes. That's a TCP-port scan of localhost (only one of several major
> scan modes nmap can do). Ordinarily, I would caution that nmap must
> always be run from a nearby-on-network node (which, yes, could be
> talking to one's temporary dial-up IP from elsewhere), and never used
> by a host to scan itself, because the report would include local-only
> network services, which obviously cannot be attacked from remote
> locations. (Thus, you tend to think you have remote vulnerabilities
> that really don't exist. This is a very common error.)
>
> However, in this case, Sindi's results suggest there are zero
> TCP-based network services at all, so whether they're strictly local or
> not is entirely moot.

I told you I had no servers running except sometimes X, and I usually go
online with ssh or lynx.

> But if I run chrootkit and it finds nothing, and I am not running any
> network services when I go online, can I continue as root without
> worrying?

No. Your question is a complete and total non-sequitur to what I just
got through saying, and carrying out online activity as the root user,
or indeed any activity at all that doesn't require root access, remains
reckless and ill-advised for reasons that frankly should be obvious --
completely without regard to whether you're even running network daemons
at all.

The non-sequitur nature of that question suggests to me that you
probably are not really heeding what people are saying, in this thread,
or it seems likely that you would not make such comments.

No, I'm certainly not. For heaven's sake, if you're curious about what
those options mean, they're detailed right in the manpage.

> Should I do the same as above but substitute the IP address
> assigned when I dial the ISP?

You should re-read the explanation of why scanning a host from itself
would normally be pointless.

> I will look for chrootkit.

chkrootkit is a last-gasp but highly fallible attempt to detect security
disasters after all your real defences and precautions have failed.
Your biggest problem is that you're going around defeating precautions
(e.g., insisting on using the root account routinely) and eschewing
defences. That is what should be getting your attention.

>
>>>> Do you monitor the logs? Do you run chkrootkit regularly? Do you
>>>> monitor portscans?

I downloaded (about 40K) chkrootkit.tar.gz, unpackaged and typed make
sense and it produced chkrootkit and some other files.

./chkrootkit wanted netstat. It was a 7 min download in a package and I
extracted it with tar -zxvf tcpicp1.tgz bin/netstat and put into /bin.

chkrootkit then told me I had six infected files:

basename dirname echo env ifconfig and traceroute.

These are all part of busybox 1.1.0 compiled statically against uClibc.
Are they really infected (with what?) or is uClibc confusing chkrootkit?
They are not in the typical locations but are on the path.

telnetd and su in busybox are not infected.

``Checking 'date' ... bash
/bin/csh
INFECTED
''

(I have a /bin/bash but no csh. Command not found.)

How do I interpret the above?

Some things it could not find, some it said were not infected, such as
cron. I don't have a cron. Same for ldsopreload and sshd and write.

chkrootkit is built on an ultimately stupid approach -- stupid by
design: It does pattern-matching in an attempt to, as Marcus J. Ranum
puts it, "enumerate badness", which is an inherently fallible, losing
strategy.

So, you read chkrootkit FAQs and other documentation about known false
positives, if necessary you read the chkrootkit script to determine what
it's checking, and you decide for yourself whether it's talking nonsense
or not.

However, if you've put yourself in a position where you're actually
relying on chkrootkit for anything but a quick cross-check against
your primary security measures, I'd say you have a lot bigger problems.

I ran chrootkit on a small ramdisk version of our distribution with an
older busybox, after mounting the ext2 partition so I could symlink to the
three missing binaries (netstat, awk and echo) and it found the same
infected files except ifconfig was okay. I really doubt any hacker could
have infected my DOS file that contains the files, which load to ramdisk.

Therefore my system, which I have been running as root for four years,
seems not to have been hacked. I can still run Opera as su user just in
case. (And in case I want to print with some other printer on my list of
filters, such as draft or 600 dpi, without changing the custom script).

> chkrootkit is built on an ultimately stupid approach -- stupid by
> design: It does pattern-matching in an attempt to, as Marcus J. Ranum
> puts it, "enumerate badness", which is an inherently fallible, losing
> strategy.

So it found the patterns of some known worms in uClibc-static busybox?

> So, you read chkrootkit FAQs and other documentation about known false
> positives, if necessary you read the chkrootkit script to determine what
> it's checking, and you decide for yourself whether it's talking nonsense
> or not.
>
> However, if you've put yourself in a position where you're actually
> relying on chkrootkit for anything but a quick cross-check against
> your primary security measures, I'd say you have a lot bigger problems.
>

I don't appear to have any security problems. I was warned again not to
run the telnetd that I compiled. I would only do so offline. We have
instructions on using ipchains and default gateways to hook up two
computers now so both can go online over the same modem. (Or I can use a
wireless laptop to pick up our free county wireless signal and a cable to
convey it to a desktop).

I once used in.telnetd and a nullmodem cable and telnet with root access
online for 30 sec to share a connection, but nobody seems to have
successfully hacked my computers. Out little linux is recommended for
making very old computers into terminals, with X.

I can thus make old linux computers for people to use the internet with,
and not worry about them become spammers by accident.

Our author says busybox and uClibc and the lack of expected binaries would
make it difficult for hackers to find their way around even if we did have
open ports, but he goes online with Opera as 'user' in case of any
vulnerabilities in the X server or Opera.

>
> Our author says busybox and uClibc and the lack of expected binaries would
> make it difficult for hackers to find their way around even if we did have
> open ports, but he goes online with Opera as 'user' in case of any
> vulnerabilities in the X server or Opera.

List members suggested online port scanners, but I think the one I used at
http://www.hq42.net/net_tools scanned my ISP though it listed my IPLOCAL
number because it listed about 900 ports including netstat (which I am not
running) and mentioned the name of the nearest large city.

Another list member pointed out that startx allows only local access to
the X server so is also not vulnerable. startxt is vulnerable (it allows
us to use one old computer as a terminal, in X, to another faster one). I
don't run that because I have plenty of 'new' computers now (200MHz and
up).

> > Our author says busybox and uClibc and the lack of expected binaries would
> > make it difficult for hackers to find their way around even if we did have
> > open ports, but he goes online with Opera as 'user' in case of any
> > vulnerabilities in the X server or Opera.
>
> List members suggested online port scanners, but I think the one I used at
> http://www.hq42.net/net_tools scanned my ISP though it listed my IPLOCAL
> number because it listed about 900 ports including netstat (which I am not
> running) and mentioned the name of the nearest large city.

Open ports are not the only security problem. You already got many hints
from the TAG subscribers. Security is not a state that is either
switched on or off by configuration. It is a process and considering the
code people usually run on workstations (graphically or not) it is next
to impossible to predict what code will do in all possible
circumstances.

"Integer overflow on long stylsheet sttribute. Can potentially be
used for hidden malware installation."

A lot of online scanners are woefully incomplete and only check for the
top 10 (100 or 1000) bugs and a good part of them is designed to work
with MS Windows clients. These scanners are only a part of a security
strategy and their output should be treated as such.

> Another list member pointed out that startx allows only local access to
> the X server so is also not vulnerable.

Some GNU/Linux distributions (such as Debian) also deactivate X's port
6000 by default. Of course this doesn't protect you against running an X
session with lots of software (which is not designed to run as root)
with root privileges.

Apologies for repeating things others have said in this thread. The part
about online scanners and Opera 8.52 made a little noise on my email
radar.

> Open ports are not the only security problem. You already got many hints
> from the TAG subscribers. Security is not a state that is either
> switched on or off by configuration. It is a process and considering the
> code people usually run on workstations (graphically or not) it is next
> to impossible to predict what code will do in all possible
> circumstances.

Sometimes even linux crashes.

>> http://bcheck.scanit.be found 0 vulnerabilities in Opera 8.52. [...]
>
> If you try http://www.securityfocus.com/vulnerabilities instead and
> enter "Opera Software" and then "Opera Web Browser" in the search form
> you get a long list of (known) bugs along with their security
> implications and possible fixes or upgrades. A Google search for '"opera
> 8.52" security bugs' has http://security.nnov.ru/soft/8550.html as first
> search result. This page says:
>
> "Integer overflow on long stylsheet sttribute. Can potentially be
> used for hidden malware installation."

Thanks.

> A lot of online scanners are woefully incomplete and only check for the
> top 10 (100 or 1000) bugs and a good part of them is designed to work
> with MS Windows clients. These scanners are only a part of a security
> strategy and their output should be treated as such.

Okay.

>> Another list member pointed out that startx allows only local access to
>> the X server so is also not vulnerable.
>
> Some GNU/Linux distributions (such as Debian) also deactivate X's port
> 6000 by default. Of course this doesn't protect you against running an X
> session with lots of software (which is not designed to run as root)
> with root privileges.

How would this affect online security?

> Apologies for repeating things others have said in this thread. The part
> about online scanners and Opera 8.52 made a little noise on my email
> radar.

Thanks. I have already changed opera to su user. I could do the same for
lynx. Make scripts. And move files that I download from /home/user to
where I want them as root.

I shared your information with my linux list. We are having an
interesting discussion now about security, portscanners, and nmap (which
the author recently compiled for our use). This business of whether to
run as root is important to our distribution. Several people here know
much more than I do about security. (I know next to nothing).

> Therefore my system, which I have been running as root for four years,
> seems not to have been hacked.

Non sequitur. Of course, being both lucky and reckless is certainly not
unheard-of.

> So it found the patterns of some known worms in uClibc-static busybox?

Sorry, you need to review the context in which you're asking me that
question: I regard chkrootkit / rkhunter as a generally foolish
approach, justified only as a last-gasp check when someone has suddenly
woken up to a pattern of negligence and wants a quick'n'dirty check --
with the proviso that the onus is on the user to decide what scan
results make sense, and why.

The "user" in this case would be you, not me.

I am also particularly disinclined to go to any special lengths to help
such a user feel good about inherently bad system usage decisions such
as running routinely as the root user. So, sorry, no, I will not help
you patch up your bad model.

>
>> Therefore my system, which I have been running as root for four years,
>> seems not to have been hacked.
>
> Non sequitur. Of course, being both lucky and reckless is certainly not
> unheard-of.

The system was designed to be safe to run as root, I think. Nobody else
has reported being hacked either. Someone reported attempts at hacking
when they were running some server and some program that logs things and
probably something protective.

>
>> So it found the patterns of some known worms in uClibc-static busybox?
>
> Sorry, you need to review the context in which you're asking me that
> question: I regard chkrootkit / rkhunter as a generally foolish
> approach, justified only as a last-gasp check when someone has suddenly
> woken up to a pattern of negligence and wants a quick'n'dirty check --
> with the proviso that the onus is on the user to decide what scan
> results make sense, and why.

Someone in TAG asked if I had run it so I went and got and compiled and
ran it. I am following instructions, I think.

I am also following instructions from our group to use Opera as user and
run other programs offline as root.

I tried to su user lynx and it would not but I could login as user then
run lynx and then I could not save configuration file settings. I am sure
there is some workaround.

> The "user" in this case would be you, not me.
>
> I am also particularly disinclined to go to any special lengths to help
> such a user feel good about inherently bad system usage decisions such
> as running routinely as the root user. So, sorry, no, I will not help
> you patch up your bad model.
>
>> I don't appear to have any security problems.
>
> Good luck with that. You'll need it.

I don't think I was asking for patches, just grateful for any helpful
info. It is interesting learning about these things.

This remains nonsense, as it's been every other time you've said it,
too. I can only suggest you learn some security, to figure out what the
idea is foolish, as evidently we're not getting through to you -- and
frankly I have more rewarding things to do.

I think I tried making both these files rwx for everyone. Will try again
to match yours.

>
>At least a little different - although that's not necessarily the cause.
>
>>chmod a+w lp0 did not help (crw-rw-rw-) nor did chmod 777 (crwxrwxrwx).
>>lp0 works for root except with lpr.
>>
>>In order to work as user I have had to change permissions on /dev/null
>>(w), ttyp* and ptyp* (rw), set suid XVESA and anything svgalib (links2,
>>zgv, gs), make /var/lock writeable, make any scripts suid or executable as
>>user, etc. An education. I can now suid user (or login as user), dial,
>>load Xvesa, icewm, and rxvt and Opera and print as user.
>
>It sounds like BasicLinux still needs a bit of refining.

Basiclinux is designed to work only as root, and to be small and fast.

>>I would like to quit struggling with permissions every time I try to work
>>as user, and be able to print as root. I do know I should not work as
>>root online but I am not running any servers while online with my modem.
>>If you scold me please explain why.
>
>No scolding, but just a note: as root, one tiny mistype is all it takes
>to wipe out your system. As well, any programs you execute that create
>an externally-accessible network socket (are you sure you know what all
>of those are?) are running with root privileges - meaning that if
>someone manages to crack one, they 0wn your system.
>
>So, I'm not going to say "don't do that". I'm just going to note that
>the cost of doing so can be rather high.

I have the same system on several computers so can easily restore it.
My super-duper full-size linux is about 1GB including a lot of music and
photos and kernel source code. The little one about 100MB.

>>Does lpr depend on some other program, library, or device that I need to
>>change permissions for?
>
>Maybe - or maybe not, depending on how yours is configured and what
>version of "lpr" you're using (in theory, you can minimize external
>processing by trying to print a plain text file, e.g., '/etc/passwd'.)
>In any case, it's a question that you yourself can answer by executing
>"lpr" with "strace", something like this:
>
>``
>ben at Fenrir:~$ su -
>Password:
>root at Fenrir:~# strace -o lpr.out /usr/bin/lpr file
>''

I had to download the strace.tgz package first. Running it from a
temporary directory without installing the package.

ptrace: umoven: Input/output error (four lines of this).

But it made lpr.out, a couple pages or more.

>After that, read the resulting file ('lpr.out', in the above case) and
>see where things failed. If you need a baseline for comparison, you can
>always run the above "strace" line as a non-root user.

I can't make much sense of the results.
See attached lpr.out (root) and lpr2.out (user).

It is supposed to be writing a file to /var/spool/lpd/postscript,
and the permissions on that directory are drwxr-xr-x. Should I change to
drwxrwxrwx?

I probably created the directories after installing linux.

>>Can YOU print with lpr as root?
>
>Yep. I don't recall that ever being a problem, although I've seen the
>opposite happen.
>

>Quoting Sindi Keesan (keesan at grex.cyberspace.org):
>
>>But if I run chrootkit and it finds nothing, and I am not running any
>>network services when I go online, can I continue as root without
>>worrying?
>
>No. Your question is a complete and total non-sequitur to what I just
>got through saying, and carrying out online activity as the root user,
>or indeed any activity at all that doesn't require root access, remains
>reckless and ill-advised for reasons that frankly should be obvious --
>completely without regard to whether you're even running network daemons
>at all.

I mentioned a while ago that I had clones of the same linux on several
computers so I am not concerned about accidentally wiping out files.
And from what various people have told me one cannot hack my system if I
have no network daemons running and X only has local access and Opera has
no vulnerabilities. And chkrootkit found nothing after four years. So
it is not obvious. I am not trying to be intentionally stupid.

>The non-sequitur nature of that question suggests to me that you
>probably are not really heeding what people are saying, in this thread,
>or it seems likely that you would not make such comments.

I don't have enough background to understand 99% of what is in manpages
starting with the vocabulary, and this one was about 100 pages long. I
was rather surprised that I managed to use nmap at all. I am not a
computer professional, just don't like MS or GUIs in general and am
willing to work hard to bypass them. I found a chapter in Running Linux
ver 3 about TCP UDP and ACK which I will read.

>>Should I do the same as above but substitute the IP address
>>assigned when I dial the ISP?
>
>You should re-read the explanation of why scanning a host from itself
>would normally be pointless.

I tried to scan from a website and it listed a lot of things that are
probably at my ISP since I don't have them running here, even though it
was using my IPLOCAL number. My linux list members will explain this.

>>I will look for chrootkit.
>
>chkrootkit is a last-gasp but highly fallible attempt to detect security
>disasters after all your real defences and precautions have failed.
>Your biggest problem is that you're going around defeating precautions
>(e.g., insisting on using the root account routinely) and eschewing
>defences. That is what should be getting your attention.

I understand this is like using f-prot rather than being careful not to
download viruses in the first place.

Our linux was designed to be used as root. The author and other users who
understand security say this is safe in our case. There is no evidence
yet in 4 years that this makes it insecure. It did not come with network
servers (I added the telnetd in busybox). And it is a great deal of
trouble and is more likely to cause problems if I keep changing
permissions on all sorts of things each time I want to use another program
as user.

Which is why I asked for help with lpr.

Is this discussion online so other users of our linux can read it and
comment?

> ----- Forwarded message from Sindi Keesan <keesan at grex.cyberspace.org> -----
>
> I mentioned a while ago that I had clones of the same linux on several
> computers so I am not concerned about accidentally wiping out files.

That depends on the files you backup, and how you clone them. There are
various filesystems out there which operate in this way to do just that.

> And from what various people have told me one cannot hack my system if I
> have no network daemons running and X only has local access and Opera has
> no vulnerabilities. And chkrootkit found nothing after four years. So
> it is not obvious. I am not trying to be intentionally stupid.

Well, the X11 issue comes down to access control (see 'man xhost'). And
it's still a bogus comment since it's not so much access control that's
the issue, as it is having the program run as user root in the first
place.

Take for example, a copy of gvim. Guess what happens if that's started
as root.

-- Thomas Adam

--
"Wanting to feel; to know what is real. Living is a lie." -- Purpoise
Song, by The Monkees.

> [ Hopefully I haven't completely messed up attribution. ]
>
> On Sun, Jan 28, 2007 at 04:21:21PM -0800, Rick Moen wrote:
>> ----- Forwarded message from Sindi Keesan <keesan at grex.cyberspace.org> -----
>>
>> I mentioned a while ago that I had clones of the same linux on several
>> computers so I am not concerned about accidentally wiping out files.
>
> That depends on the files you backup, and how you clone them. There are
> various filesystems out there which operate in this way to do just that.

cp -a /hda1/* /hdc1
ext2

Is there something more suitable for copying 500-1000MB of files? I tried
dd between identical drives, with bs=64k or larger.

I spend time in three places, have 2-3 computers with the same software at
each place, and keep anything I need to access online at a shell account
where I do not have root privileges.

The computers are all free because our friends need newer ones for
Windows. We are setting up linux/Opera for other friends on 500MB drives,
when their 20GB XP drive dies. I will set them up as user for added
security.

>> And from what various people have told me one cannot hack my system if I
>> have no network daemons running and X only has local access and Opera has
>> no vulnerabilities. And chkrootkit found nothing after four years. So
>> it is not obvious. I am not trying to be intentionally stupid.

> Well, the X11 issue comes down to access control (see 'man xhost'). And
> it's still a bogus comment since it's not so much access control that's
> the issue, as it is having the program run as user root in the first
> place.
>
> Take for example, a copy of gvim. Guess what happens if that's started
> as root.

I have never heard of gvim before. I compiled busybox vi but have not
learned to use it. I use pico in console mode and am trying to learn to
write simple rtf, maybe by changing the keycodes for the function keys so
F1 is bold-on and F2 is bold-off, etc., to avoid needing X at all. I
could not find a console wordprocessor for linux, and wordperfect and VDE
don't work correctly in dosemu or qemu.

If I do have to use Opera, does it matter whether I load X and dial as
root or user before using Opera as user?

I have used dd to clone between two identical drives. I experimented
with cloning partitions in order to copy Win98 and it created problems.
(Windows would tell us the drive was full when it was not).

I have used tar -zcvf to copy files via a FAT-formatted USB flash drive
without losing long file names. Or to make one big copy of a file system
that was small enough to fit into a DOS partition on an old laptop. The
gzipping takes a long time but might be worth it if you are copying via
PLIP rather than ethernet.

I normally use cp without gzipping, on individual files or a .tar file,
because the gzip takes longer than the file transfer on our older
computers.

We do not have rsync, dump, or restore. I met TAG in the first place
because we also do not have modprobe or telinit.

Please understand I have nothing particularly to gain from convincing
you, so basically you're going to have to figure this out on your own.

You might wish to read "Firewalls" on http://linuxmafia.com/kb/Security/,
which links to the complete 1994 book text of Cheswick & Bellovin's
classic "Firewalls and Internet Security: Repelling the Wily Hacker",
first edition, which explains basic principles of security such as why
you want to always run processes with the minimum possible authority.

[nmap:]

> I don't have enough background to understand 99% of what is in manpages
> starting with the vocabulary, and this one was about 100 pages long.

Obviously you don't read the whole thing. Looking up and
understanding the options I cited would take you all of 15 minutes.

> >You should re-read the explanation of why scanning a host from itself
> >would normally be pointless.
>
> I tried to scan from a website

That would be pointless for two different reasons: (1) Results would
often be inherently meaningless because of port-blocking, proxying,
etc., between you and the Web site. (2) You have no control or
knowledge of how they're implementing their scans, and cannot know
whether what they're doing is meaningless junk -- as is generally the
case, with, e.g., Gibson Research's "Shields Up" site, for example.

> Our linux was designed to be used as root.

Which is a bad design, ab initio. Again, I have nothing to gain from
convincing you of this. However, I can avoid wasting my time helping
you tweak a setup I regard as misbegotten in the first place.

> Is this discussion online so other users of our linux can read it and
> comment?

Ben would have to explain to you why our mailing list archive isn't
accessible to the general public, since for the life of me I cannot.

> Quoting Sindi Keesan (keesan at grex.cyberspace.org):
>
> [running routinely as root:]
>
>> So it is not obvious.
>
> Please understand I have nothing particularly to gain from convincing
> you, so basically you're going to have to figure this out on your own.
>
> You might wish to read "Firewalls" on http://linuxmafia.com/kb/Security/,
> which links to the complete 1994 book text of Cheswick & Bellovin's
> classic "Firewalls and Internet Security: Repelling the Wily Hacker",
> first edition, which explains basic principles of security such as why
> you want to always run processes with the minimum possible authority.

Thanks.

>
> [nmap:]
>
>> I don't have enough background to understand 99% of what is in manpages
>> starting with the vocabulary, and this one was about 100 pages long.
>
> Obviously you don't read the whole thing. Looking up and
> understanding the options I cited would take you all of 15 minutes.

But I don't understand the words they are using to explain the concepts.
The only computer course I ever took was Fortran IV. I will try to start
with some basic reading. I am not trying to be a system administrator,
just to put together something I can use myself.

>>> You should re-read the explanation of why scanning a host from itself
>>> would normally be pointless.
>>
>> I tried to scan from a website
>
> That would be pointless for two different reasons: (1) Results would
> often be inherently meaningless because of port-blocking, proxying,
> etc., between you and the Web site. (2) You have no control or
> knowledge of how they're implementing their scans, and cannot know
> whether what they're doing is meaningless junk -- as is generally the
> case, with, e.g., Gibson Research's "Shields Up" site, for example.

If I cannot scan from my own computer or while online, how do I scan?

>> Our linux was designed to be used as root.
>
> Which is a bad design, ab initio. Again, I have nothing to gain from
> convincing you of this. However, I can avoid wasting my time helping
> you tweak a setup I regard as misbegotten in the first place.
>
>> Is this discussion online so other users of our linux can read it and
>> comment?
>
> Ben would have to explain to you why our mailing list archive isn't
> accessible to the general public, since for the life of me I cannot.

Okay. If you want to read our discussions of nmap and security bugs
search on basiclinux archives for Jan 2007.

> >_Obviously_ you don't read the whole thing. Looking up and
> >understanding the options I cited would take you all of 15 minutes.
>
> But I don't understand the words they are using to explain the concepts.

-sT (TCP connect() scan)
TCP Connect() scan is the default TCP scan type when SYN scan
is not an option.... This is the same high-level system
call that web browsers, P2P clients, and most other
network-enabled applications use to establish a connection.

Test using the same TCP connection type most apps use.

-sR (RPC scan)
...takes all the TCP/UDP ports found open and floods them
with SunRPC program NULL commands in an attempt to
determine whether they are RPC ports....

So, adds a check for some particular -type- of connection (called
"SunRPC" -- which happens to be, FYI, used primarily for NFS/NIS).

-O: Enable OS detection

Self-explanatory.

-oN ...: Output scan in normal... format....

Self-explanatory.

/tmp/nmap-tcp.log

Where to log to, instead of just echoing to screen.

-n ...: Never do DNS resolution....

Self-explanatory.

157.22.20.227

What IP I, in my particular case, was telling nmap to scan, at that
time.

-sA (TCP ACK scan)
...is used to map out firewall rulesets, determining whether they
are stateful or not and which ports are filtered.

Self-explanatory.

Now, if you'd asked our help in interpreting results of such scans, that
I could have respected. But saying "I can't deal with that" is
difficult to respect.

> If I cannot scan from my own computer or while online, how do I scan?

A second, network-wise "nearby" machine would be best. It could be
something as simple as a borrowed PC running a Knoppix live CD,
connected to yours via a crossover cable between the two machines'
ethernet ports. Or it could be a second dial-in machine connected to
the same ISP point of presence, so that you have minimal circuitry
between the machines.

> Quoting Sindi Keesan (keesan at grex.cyberspace.org):
>
> [nmap:]
>
>>> Obviously you don't read the whole thing. Looking up and
>>> understanding the options I cited would take you all of 15 minutes.
>>
>> But I don't understand the words they are using to explain the concepts.
>
> [Rick reviews the manpage.]
>
> No, that objection really isn't reasonable. Quoting the options'
> explanations:
>
> -v: Increase verbosity level (use twice for more effect)

I understand this part.

>
> Show more detail.
>
> -sT (TCP connect() scan)
> TCP Connect() scan is the default TCP scan type when SYN scan
> is not an option.... This is the same high-level system
> call that web browsers, P2P clients, and most other
> network-enabled applications use to establish a connection.

I never heard of SYN or P2P. I have heard of TCP but don't understand it.

Is P2P the same as pointopoint used by PLIP?

> Test using the same TCP connection type most apps use.
>
> -sR (RPC scan)
> ...takes all the TCP/UDP ports found open and floods them
> with SunRPC program NULL commands in an attempt to
> determine whether they are RPC ports....
>
> So, adds a check for some particular -type- of connection (called
> "SunRPC" -- which happens to be, FYI, used primarily for NFS/NIS).

I never heard of any of this except NFS (something that lets you share
files between computers) and Sun (a type of hardware). I am rather fuzzy
about what a port is other than a number at the end of an IP address.
(I am not asking you for an explanation here, just pointing out why I
cannot make sense of the man pages).

I still don't understand if I am supposed to be scanning my own system
from my own system or from somewhere else or not scanning my own system at
all - lots of apparently conflicting information from various people.

I spent about 15 minutes looking for my temporary IP number in my own
computer. It was not in dmesg. The online site provided it. I was rather
proud of myself for figuring out the local host IP number so I could scan
that.

I do not have any formal computer training except a semester of Fortran
IV. I never had any reason to study TCP stuff before on my own. I am
teaching myself enough linux to do what I want it to do. I feel like I am
usually in way over my head. Our little distribution is friendly to
beginners. I contacted TAG when nobody in four years figured out why lpr
was not working for root, partly because I got an email a year or two ago
asking for new topics from people who had asked for help before, and I
could not find any answers on the web. You are overestimating my
abilities and experience.

I don't know what UDP is other than a word that shows up in dmesg near
TCP.

> -sA (TCP ACK scan)
> ...is used to map out firewall rulesets, determining whether they
> are stateful or not and which ports are filtered.
>
> Self-explanatory.

Not if you don't know what an ACK or ruleset is or what stateful means or
what it means for a port to be filtered or what a port even is.

I have a vague idea what a firewall is because I was given instructions to
type two lines to create one when I was trying to go online with two
computers at the same time without a telnetd.

> Now, if you'd asked our help in interpreting results of such scans, that
> I could have respected. But saying "I can't deal with that" is
> difficult to respect.

I could give you a few sentences to translate from Turkish or Albanian
using an online dictionary if you want to know what it is like to be faced
with pages on pages of text full of words you don't know used for concepts
you know even less about. (I work as a translator and have studied both
languages). All you need to do is look up the words and teach yourself a
bit of grammar and hope you understand the subject matter enough to help
make sense of it all.

>> If I cannot scan from my own computer or while online, how do I scan?

> A second, network-wise "nearby" machine would be best. It could be
> something as simple as a borrowed PC running a Knoppix live CD,
> connected to yours via a crossover cable between the two machines'
> ethernet ports. Or it could be a second dial-in machine connected to
> the same ISP point of presence, so that you have minimal circuitry
> between the machines.

Why would I want to use a live CD rather than two computers with the same
linux on them? I am not familiar with Knoppix and I do know how to use my
own linux to some degree. We have lots of old computers given to us by
friends who can't use them for the latest MS OS. The reason I wanted to
use lpr is because we are setting them up for friends and people on the
local freecycle list to use and most of them want to print from a browser
or wordprocessor, which I never needed to do in linux. Some of them have
had lots of problems with Windows viruses and spyware, etc, and are
willing to try linux instead.

I cannot dial into the ISP from two computers at the same time, if that is
what you are suggesting.

I can try to set up a firewall with ipchains and default gateway again
with crossover cable (if I can find my notes). And dial with the default
gateway. Is that what you meant by 'same ISP point of presence'?

I assign each computer an IP number with ifconfig to establish a local
network (after inserting network modules). The ISP assigns the computer I
dial with another IP number. Do I run a scan on the IP number assigned by
the ISP or the one I assigned to that same computer?

And what would I learn other than that I do not have any open ports
because I am not running any servers (unless a default gateway in my own
local network is a server of some sort)?

I will try to make some sense of the chapter in Running Linux.

I am afraid that you have overestimated my knowledge. I have similar
problems if I pronounce things properly and use the correct syntax in
another language - people talk back to me much too quickly with unfamiliar
vocabulary.

> I never heard of SYN or P2P. I have heard of TCP but don't understand it.

For your purposes, it probably doesn't matter, right? You can look it
up when you need to know. (I could explain, but have no reason to think
you need that information right now.

> Is P2P the same as pointopoint used by PLIP?

In this context (the "-sT" option portion of the nmap manpage), "P2P"
just meant peer-to-peer, a family of Internet applications.

> I never heard of any of this except NFS (something that lets you share
> files between computers) and Sun (a type of hardware). I am rather fuzzy
> about what a port is other than a number at the end of an IP address.

I'm sure you'll learn more when you need to learn more. My point is that
you don't need to understand everything in the nmap manpage to know how
to use it. It should suffice for you to understand that I mentioned
three types of nmap scans you can do, and gave sample syntax for each:
(1) a scan of "TCP"-type services, (2) a scan of "UDP"-type services,
and (3) an "ACK" scan that test firewall rules.

You can use that information without knowing exactly what TCP is or what
UDP is, just using the additional information (also readily
comprehensible by novices from the quoted manpage portions) that
TCP/IP-using applications generally divide between those using TCP
connections and those using UDP connections.

> (I am not asking you for an explanation here, just pointing out why I
> cannot make sense of the man pages).

And I'm saying that's nonsense.

> I still don't understand if I am supposed to be scanning my own system
> from my own system or from somewhere else or not scanning my own system at
> all - lots of apparently conflicting information from various people.

You're a bright guy. Figure it out.

You already know that some network services, if enabled at all, are
reachable only from the machine itself. This should point out to you
the limited usefulness of scanning a machine from itself: It's a bit
like twisting your house's doorknobs from inside the house to
determine whether or not your house is locked. You're not really
seeking to find out if people inside the house can open the doors, but
rather whether people outside can.

> I spent about 15 minutes looking for my temporary IP number in my own
> computer.

/sbin/ifconfig -a

> I feel like I am
> usually in way over my head.

The feeling will eventually come to seem familiar, maybe even welcome.
;->

> Why would I want to use a live CD rather than two computers with the same
> linux on them?

If you don't happen to have that second Linux machine, but can borrow
an other-OS box briefly, possession of a live CD can be extremely handy.

> I can try to set up a firewall with ipchains and default gateway again
> with crossover cable (if I can find my notes).

Sure, if you wish.

I hope you realise that your prior postings indicated that you'd nmapped
the machine (well, for TCP services, anyway) from localhost, and found
nothing at all running. Assuming that is reliable information (e.g.,
that no intruder has installed a trojaned copy of nmap that omits
crucial data), then obviously your host has nothing running (using TCP
ports, anyway), and re-doing that check from a nearby host wouldn't tell
you more.

The reason why nmapping from localhost is a bad idea (leaving aside the
problem of trojaned copies) is that it overreports by including
services reachable only locally, whereas what's actually of interest are
those services that other machines will see and can use.

> Is that what you meant by 'same ISP point of presence'?

A "point of presence" (in this context) is basically a cluster of
dial-in numbers that reach the same ISP router.

> And what would I learn other than that I do not have any open ports
> because I am not running any servers (unless a default gateway in my own
> local network is a server of some sort)?

I didn't tell you to run nmap.

I was just suggesting ways to use it effectively if you have reason to
use nmap -- and also proving to you that, no, you certainly do not need
to understand its 100 pages of manpage, to use it.

> Quoting Sindi Keesan (keesan at grex.cyberspace.org):
>
>> I never heard of SYN or P2P. I have heard of TCP but don't understand it.
>
> For your purposes, it probably doesn't matter, right? You can look it
> up when you need to know. (I could explain, but have no reason to think
> you need that information right now.

I have Running Linux ver 3 and some day will find time to read more of it.
There is a chapter on networking.

>> Is P2P the same as pointopoint used by PLIP?
>
> In this context (the "-sT" option portion of the nmap manpage), "P2P"
> just meant peer-to-peer, a family of Internet applications.

>> I never heard of any of this except NFS (something that lets you share
>> files between computers) and Sun (a type of hardware). I am rather fuzzy
>> about what a port is other than a number at the end of an IP address.

> I'm sure you'll learn more when you need to learn more. My point is that
> you don't need to understand everything in the nmap manpage to know how
> to use it. It should suffice for you to understand that I mentioned
> three types of nmap scans you can do, and gave sample syntax for each:
> (1) a scan of "TCP"-type services, (2) a scan of "UDP"-type services,
> and (3) an "ACK" scan that test firewall rules.

Do I need to test firewalls when I don't have one? I set one up once
when using one computer as a gateway, following simple instructions.
Do I need a firewall if I am not running servers and use a modem?

> You can use that information without knowing exactly what TCP is or what
> UDP is, just using the additional information (also readily
> comprehensible by novices from the quoted manpage portions) that
> TCP/IP-using applications generally divide between those using TCP
> connections and those using UDP connections.
>
>> (I am not asking you for an explanation here, just pointing out why I
>> cannot make sense of the man pages).
>
> And I'm saying that's nonsense.
>
>
>> I still don't understand if I am supposed to be scanning my own system
>> from my own system or from somewhere else or not scanning my own system at
>> all - lots of apparently conflicting information from various people.
>
> You're a bright guy. Figure it out.

I am not a guy.

> You already know that some network services, if enabled at all, are
> reachable only from the machine itself. This should point out to you
> the limited usefulness of scanning a machine from itself: It's a bit
> like twisting your house's doorknobs from inside the house to
> determine whether or not your house is locked. You're not really
> seeking to find out if people inside the house can open the doors, but
> rather whether people outside can.
>
>> I spent about 15 minutes looking for my temporary IP number in my own
>> computer.
>
> /sbin/ifconfig -a

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.

I found my IPLOCAL number in /var/run/pppd.tdb, as the last of many. (It
matched what the website said it was).

>> I feel like I am
>> usually in way over my head.
>
> The feeling will eventually come to seem familiar, maybe even welcome.
> ;->

Translating is like that much of the time. One day I need to understand
the rudiments of mine sweeping or guided missles, another day gamma
globulin or organophosphates. I do a lot of surficial online research.

>> Why would I want to use a live CD rather than two computers with the same
>> linux on them?
>
> If you don't happen to have that second Linux machine, but can borrow
> an other-OS box briefly, possession of a live CD can be extremely handy.

We have the same linux on (let me count) 5 laptop computers, 9 desktops
here, 3 at each of two other locations, and a few test machines and spare
hard drives. I thought I had mentioned having lots of identical setups to
copy between if one failed, which they do once in a while when the hard
drive or motherboard dies. They all came to us free from friends,
neighbors, the curb, dumpsters, etc. We have several other computers that
I want to set up for friends and freecyclers with linux (Opera and
Abiword) instead of Win98 (WORD and IE). I can fit linux nicely into
under 100MB so have also added it to friend's working MS computers.

>> I can try to set up a firewall with ipchains and default gateway again
>> with crossover cable (if I can find my notes).
>
> Sure, if you wish.

> I hope you realise that your prior postings indicated that you'd nmapped
> the machine (well, for TCP services, anyway) from localhost, and found
> nothing at all running. Assuming that is reliable information (e.g.,
> that no intruder has installed a trojaned copy of nmap that omits
> crucial data), then obviously your host has nothing running (using TCP
> ports, anyway), and re-doing that check from a nearby host wouldn't tell
> you more.

That is why I asked if there is any point to doing this, other than for
practice.

How would someone install a trojanned copy of nmap when I never have any
ports open to come through? 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?

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)? I even delete Opera cache on exit and it is not on the path
anyway.

> The reason why nmapping from localhost is a bad idea (leaving aside the
> problem of trojaned copies) is that it overreports by including
> services reachable only locally, whereas what's actually of interest are
> those services that other machines will see and can use.

The X server is my only service, and it is only reachable locally.
So in my case why should I run nmap to scan my system if I am not running
any servers on it besides X?

>> Is that what you meant by 'same ISP point of presence'?
>
> A "point of presence" (in this context) is basically a cluster of
> dial-in numbers that reach the same ISP router.

I cannot dial in twice at the same time to the same ISP without having two
accounts. If I tried they might be annoyed.

>> And what would I learn other than that I do not have any open ports
>> because I am not running any servers (unless a default gateway in my own
>> local network is a server of some sort)?
>
> 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.

> I was just suggesting ways to use it effectively if you have reason to
> use nmap -- and also proving to you that, no, you certainly do not need
> to understand its 100 pages of manpage, to use it.

If I understand correctly, I have no reason to use it unless I want to run
things like ftpd or sshd while I am online. I ran pureftpd once as an
experiment to check if I had a way to transfer files via ethernet to and
from a Windows computer. Offline.

I will, unless someone explains why not to, set up friends to load X and
rxvt as root, insert modules and dial as root, then go online su user with
Opera, just in case Opera can be hijacked somehow to do something nasty on
the computer running it.

9.02 has major security fixes but the two versions I downloaded require a
later glibc, which (from Slackware) requires a later kernel than we have,
which is not impossible. Should I be concerned about the following:

the RSA signature checking problem found in openssl

a URL tag parsing heap overflow that could potentially execute code

My friends do not need the added features - Bittorrent support, Widgets,
or Acid 2, or IMAP mailer code. They mainly want to write webmail.

> I have Running Linux ver 3 and some day will find time to read more of it.
> There is a chapter on networking.

Last I read of this, it just told you how to use the route command to
shunt traffic through another machine. If you really want to learn
about networking there's a whole plethora of books dedicated to it. I
didn't find that chapter particularly enlightening, and given your
somewhat dismissive approach to everything offered to you, I'm probably
not too far off being right, either.

> >> Is P2P the same as pointopoint used by PLIP?

No. P2P is "Peer-To-Peer". Note that PLIP is just one example of
pointopoint.

> Do I need to test firewalls when I don't have one? I set one up once

Test them? No. Just assume they work.

> when using one computer as a gateway, following simple instructions.
> Do I need a firewall if I am not running servers and use a modem?

No, you don't. But then some people like leaving their computers
exposed to potential threats. Maybe you should do the same, and see
what happens.

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

A dictionary wouldn't help you unless you first understand how they work
together. Paradoxically though, you'd have to have a reasonable
assumption about the need for a firewall as well, something you seem
not to want to do. I won't be repeating anything else people have saif
to you already, but most of your counter-questions are ridiculous; play
devil's advocate if you wish, but you won't learn a thing from it.

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

I'm well known for using and having antiquated hardware, but why are you
using busybox? Surely you have a proper distribtion to hand where the
tools in it aren't squashed down so much as to provide very limited
functionality?

> How would someone install a trojanned copy of nmap when I never have any
> ports open to come through? 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?

There's many different ways -- running programs to exploit things like
buffer-overlows, etc.

> 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)? I even delete Opera cache on exit and it is not on the path
> anyway.

By causing arbitrary code execution through things like
buffer-overflows.

[...]

-- Thomas Adam

--
"Wanting to feel; to know what is real. Living is a lie." -- Purpoise
Song, by The Monkees.

> On Mon, Jan 29, 2007 at 05:41:21PM -0500, Sindi Keesan wrote:
>> I have Running Linux ver 3 and some day will find time to read more of it.
>> There is a chapter on networking.
>
> Last I read of this, it just told you how to use the route command to
> shunt traffic through another machine. If you really want to learn
> about networking there's a whole plethora of books dedicated to it. I
> didn't find that chapter particularly enlightening, and given your
> somewhat dismissive approach to everything offered to you, I'm probably
> not too far off being right, either.

All I really want to do is help out a few friends by setting them up with
small linuxes they can use for the internet and wordprocessing, not become
a linux networking expert. One of them wants to pick up his computer
tomorrow, with software on it.

I don't have time to read books on the subject which would probably
require reading other books first. A basic idea of what is going on would
be interesting. I will look at the various intro to linux sites.

>
>> Do I need to test firewalls when I don't have one? I set one up once
>
> Test them? No. Just assume they work.
>
>> when using one computer as a gateway, following simple instructions.
>> Do I need a firewall if I am not running servers and use a modem?
>
> No, you don't. But then some people like leaving their computers
> exposed to potential threats. Maybe you should do the same, and see
> what happens.

That would be interesting. I could set up two minimal linuxes (maybe
ramdisk versions) connected together, one with modem and firewall, and
then repeat this without the firewall and see if anything changed (using
chkrootkit?). I will have more time in about 10 days for this.

Just showing off my newfound knowledge of acronyms that I did not know
yesterday.

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

> A dictionary wouldn't help you unless you first understand how they work
> together. Paradoxically though, you'd have to have a reasonable
> assumption about the need for a firewall as well, something you seem
> not to want to do. I won't be repeating anything else people have saif
> to you already, but most of your counter-questions are ridiculous; play
> devil's advocate if you wish, but you won't learn a thing from it.

We were told to use a firewall only if networking two computers together
to use one as a gateway so we could go online with both. I don't know
what a firewall is but I followed instructions to set one up with
ipchains (after learning to compile a kernel that could use it). Do I
need a firewall if I don't have a local network?

If my questions are ridiculous to you it is only because I really don't
understand much of this. All I was trying to do when I wrote to TAG was
find a way for people to print from Opera and Abiword without having to
learn to change permissions all over the place to run them as user, not to
learn all about networking and firewalls and port scanners. I can't reply
to all these emails right away and still have time to learn all this at
the same time and run a business too and get a friend's computer ready for
tomorrow. I will try to set him up to use opera as user and then do some
more reading.

>> 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.
>
> I'm well known for using and having antiquated hardware, but why are you
> using busybox? Surely you have a proper distribtion to hand where the
> tools in it aren't squashed down so much as to provide very limited
> functionality?

I have a distribution based on busybox, and if something in busybox is not
adequate, for instance when compiling, I replace it. The problem here is
I replaced busybox with a newer version which I compiled myself, to get
a lot of bug fixes and su and vi. The original older busybox ifconfig was
correctly configured. I will fix this next time I compile busybox. (I
also left pdfwrite out of gs).

>> How would someone install a trojanned copy of nmap when I never have any
>> ports open to come through? 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?
>
> There's many different ways -- running programs to exploit things like
> buffer-overlows, etc.
>
>> 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)? I even delete Opera cache on exit and it is not on the path
>> anyway.
>
> By causing arbitrary code execution through things like
> buffer-overflows.

Are you referring to buggy programs on my computer? Can they only do this
if I go online as root?

> We were told to use a firewall only if networking two computers together
> to use one as a gateway so we could go online with both.

There have been many flamewars over such topics, not to mention people
going around having trying to use "firewalls" (by which they mean
IP/port filters, as opposed to other meanings of that term) as a
cure-all talisman to ward off all possible badness, which of course
doesn't work -- so you will perhaps forgive Thomas and me for carefully
avoiding overbroad statements. It really is true that the sort of
filters, if any, that suit your situation depend on your situation.

> If my questions are ridiculous to you it is only because I really don't
> understand much of this.

Not ridiculous, but sometimes a bit scattershot. Technical people tend to
learn over time that a sprinkling of apparently ill-aimed questions are
often a sign of someone who isn't really seeking the information
specified, but rather is just pumping out questions in semi-random
directions in an enegetic attempt to overcome lack of knowledge of the
basics. When technical people spot that pattern, they often react by
ceasing to minutely address the questions as posed, and instead urge the
questioner to master those basics first, so that subsequent questions
can be more focussed, and use everyone's time better.

> All I was trying to do when I wrote to TAG was find a way for people
> to print from Opera and Abiword without having to learn to change
> permissions all over the place to run them as user, not to learn all
> about networking and firewalls and port scanners.

Unfortunately (speaking for myself, at least, possibly others), when
someone tells me "No, it really is OK for me to run routinely as root,
because my system's designed for it", my willingness to help,
particularly with security, goes way down. This naturally is no
reflection on you personally.

On or around Tuesday 30 January 2007 02:17, Sindi Keesan reorganised a bunch
of electrons to form the message:

>
> All I really want to do is help out a few friends by setting them up with
> small linuxes they can use for the internet and wordprocessing, not become
> a linux networking expert.

An admirable idea. There are a number of distributions designed for the sort
of older machines you are using for this. Given what I've heard about
BasicLinux, I can't help thinking that one of the others might be more
suitable.

Even if a distribution designed to be run as root is not vulnerable to direct
attack via the network, it allows many more opportunities for users to shoot
themselves in the foot.

> On or around Tuesday 30 January 2007 02:17, Sindi Keesan reorganised a bunch
> of electrons to form the message:
>>
>> All I really want to do is help out a few friends by setting them up with
>> small linuxes they can use for the internet and wordprocessing, not become
>> a linux networking expert.
>
> An admirable idea. There are a number of distributions designed for the sort
> of older machines you are using for this. Given what I've heard about
> BasicLinux, I can't help thinking that one of the others might be more
> suitable.
>
> Even if a distribution designed to be run as root is not vulnerable to direct
> attack via the network, it allows many more opportunities for users to shoot
> themselves in the foot.
>
> I appreciate that BasicLinux has the advantage of familiarity and it's not
> always easy to change, but I would suggest considering something else from
> http://lwn.net/Distributions/#smalldisk,
> http://lwn.net/Distributions/#special or http://lwn.net/Distributions/#india
>
> Popular small distributions include Damn Small linux and Puppy Linux. you
> would have to check their project sites to determine if they are suitable for
> your needs.

Puppy Linux is a Live CD. I want ext2 linux, to which I can add programs.

DSL is Debian based and much larger than what I am using and would be
slower to boot and require newer hardware. I don't want to learn it.
It has a lot of stuff that people have not asked for, and not Opera which
they have asked for (after using it in Windows). If people later want to
do more than browsing/email/wordprocessing they can get themselves a copy
of DSL and try it.

I prefer to try to make what I have work. I know how to use it and can
support it. Is there anything I would have to do other than get things
working for 'user'? If it is okay to dial as root then use a browser as
user, I am almost set.

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.

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

I have never been there, I only learned Albanian while living in Skopje
for a couple of years. I took to spelling my name this way while living
in Belgrade so that it would be pronounced correctly. Instead of Tsindoo.
And then discovered it has some meaning in some Indian language when a
would-be chatter refused to stop chatting with me in (?) Punjabi.

>(FWIW, American informal English increasingly uses "guys" to refer to
>both sexes, this being a tangle that cannot be undone in any clean
>fashion.)

Only in the plural, and not everywhere in the country. Michigan uses 'you
guys' like other places use 'you all' or 'you uns' or 'youse'. One guy is
only male.

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

I don't know enough to assess these things. Yet. So have been following
the recommendations of others in our support group, which is not to run
things like telnetd online. And to go online with Opera as user because
it might be buggy.

Is the threat that someone will get files onto my computer that will let
them use it to send spam? Or delete my files? (I have lots more copies).
Or steal my online banking info? (I don't have any). The 1991 security
problems were often people stealing the hardware, according to a book I
have on system administration.

>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

Obvious only if I can make sense of it. Which would require more reading.

The two computers are in the same local network as 192.168.1.0 .
Is this specific to using the computer as a default gateway?

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

Can you recommend a good online tutorial about networking and firewalls
and security which is smaller?

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

The more I learn the more confusion ;=)

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

I did not compile nmap, the author of our distribution provided it. I did
compile chkrootkit from what looked like an official site.

I don't see how running as user would prevent the above anyway.

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

Like running f-prot from write-protected floppy disks.

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

I have compiled a few executables which have not attacked me. How would I
know if source code was not to be trusted?

My friends will not even have a compiler. So it appears they are safe,
with su user opera. (Links2 and links cannot be used that way - cannot
exectue binary file - but I can login as user to use them).

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

Sounds like I have been lucky for four years.

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

My list people told me a way to dump people into X when they start
(inittab?) but I have no idea how I could log them in as user and then
start X automatically. I can have them dial from an rxvt as user - would
that help? And run opera as user.

> >(FWIW, American informal English increasingly uses "guys" to refer to
> >both sexes, this being a tangle that cannot be undone in any clean
> >fashion.)
>
> Only in the plural, and not everywhere in the country. Michigan uses 'you
> guys' like other places use 'you all' or 'you uns' or 'youse'. One guy is
> only male.

One guy whom you are familiar with. It has been common to refer to an
unknown person as a "guy", while knowing that the implication of a
particular sex isn't quite right either, and knowing that English has,
in general, hopeless structural problems of the sort that are inevitable
when Latin and German collide and have a violent accident.

The lack of a proper second-person plural is of course another problem,
and "y'all" is frequently heard in the USA even outside the South, as it
may sound quaint and folksy, but at least gets you out of that
particular pickle.

Noted. But you asked the question, and I gave a fair if somewhat pithy
answer. I might have been willing to give a more-detailed answer, but
for my strong suspicion that most of your questions have been a bit
unfocussed.

> Is the threat that someone will get files onto my computer that will let
> them use it to send spam? Or delete my files? (I have lots more copies).

Some of those processes will be spy programs, running to capture login
information entered by local users for remote systems elsewhere. Those
will be logged and conveyed back to the attacker, giving him new
targets. Some may be network sniffers, monitoring the traffic passing
nearby, to or from other nearby machines, and likewise capturing private
information for the bad guys. Those work by putting your network
interface in promiscuous mode, in which the normal disregarding of other
machines' network traffic gets disabled. Some may be clandestine network
services, such as file-swapping, that are useful for the attacker and
his friends. Most distressing of all, some may be carrying out attacks
on other systems. The older variety of those involved flooding distant
machines with either normal or deliberately malformed network traffic
(ping, ping of death, smurf, SYN flooding, teardrop, land, bonk), as a
denial of service (DoS) attack. Then starting last year, the
more-organized DDoS tools (trinoo, Tribal Flood Network, stacheldraht,
Trank, and so on) came to sudden public attention when they were used to
overwhelm popular Internet sites. The third-party, subverted machines
(zombies) used to carry out those attacks appear to have been university
machines, favored for their lax security and high Internet bandwidth,
but your Linux hosts could be the attackers' next tools.
Even if your machines don't cause you that order of embarrassment, the
other risks are equally grim: you can reveal confidential data with
business and/or personal consequences, lose that data entirely, see it
corrupted or sabotaged, be involved in wrongful or even criminal
activity, lose access to your computing resources, and indirectly cause
harm to your staff and business associates. Your Website can be defaced
or modified, or visitors might be redirected by sabotaged company DNS
servers to entirely different sites.

(Please don't sit down and tell me that some or all of that doesn't
apply to your situation. I really don't care -- no offence! -- and the
answer is intended to be of general nature.)

BTW, ipchains is old (though it still works, of course), having been
long ago replaced by iptables.

"ipchains -P forward DENY" is a blanket default-deny rule on
IP-forwarding only: It does nothing about what sort of packets are
permitted in or out of the machine. That rule then gets modified by the
command that follows.

If you're up for reading RUTE, good for you! It's a very good book. It
is also, of course, not primarily about security (if I recall correctly).

> >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.)
>
> I did not compile nmap, the author of our distribution provided it.

My point about local tools being perilous to rely on, if you have any
reason to suspect security compromise, applies with or without local
compilation.

> I don't see how running as user would prevent the above anyway.

I didn't say it would.

You were asking why one would nmap-scan one's host from a nearby machine
instead of scanning just localhost, which after all is simpler. One of
several answers is the one I stated: that if you distrust local security
for some reason, then you logically need to distrust the local copy of
nmap, its console support libs, etc.

> I have compiled a few executables which have not attacked me. How would I
> know if source code was not to be trusted?

That is a very profound question, as it turns out.

People on Linux systems with package management tend to trust the code
(both source and binary) provided with and through their distributions
packages because of quality control by the package maintainers, attested
to by cryptographic signing on the packages. Part of those package
maintainers' jobs is to verify that "upstream" source code they fetch
from the original developers and then package for their distros hasn't
been tampered with, and is really from the upstream coders.

The upstream coders are, generally, motivated to cryptographically sign
their source code releases and make sure their signing keys are widely
known, so that forgeries would be easily detected.

Whenever you as an end-user take it upon yourself to fetch "upstream"
source code (or upstream compile binaries, if any), you have implicitly
assumed that quality-control burden for yourself.

>Quoting Sindi Keesan (keesan at grex.cyberspace.org):
> My list people told me a way to dump people into X when they start
> (inittab?) but I have no idea how I could log them in as user and then
> start X automatically. I can have them dial from an rxvt as user - would
> that help? And run opera as user.

Anyone that suggests you run X11 from inittab wants shooting -- that's a
nasty RedHat-ism which I am pleased to say went away some years ago.
The problem with running anything from inittab (X11 more so) is that
if X cannot start, inittab (well, init actually, but let's not split
hairs) attempts to continually launch it. This is bad.

If you do some simple googling, there's many ways of automatically
logging into X and starting applications up.

-- Thomas Adam

--
"Wanting to feel; to know what is real. Living is a lie." -- Purpoise
Song, by The Monkees.

> On Mon, Jan 29, 2007 at 07:08:46PM -0800, Rick Moen wrote:
>> Quoting Sindi Keesan (keesan at grex.cyberspace.org):
>> My list people told me a way to dump people into X when they start
>> (inittab?) but I have no idea how I could log them in as user and then
>> start X automatically. I can have them dial from an rxvt as user - would
>> that help? And run opera as user.

Actually I have not yet managed to dial as user with pppd
(/etc/ppp/options - No such file). I also cannot use ssh as user despite
having copied over everything from /root starting with . (including
directories .ssh .links .opera and Mail) and chown user * or .* including
subdirectories. This at least fixed lynx and links and pmail to use my
previous options. I did this after noticing that only Abiword and Opera
worked for user and they were both user users rather than root root.

ssh: Permission denied (publickey,password,
keyboard-interactive,hostbased)
known_hosts and random_seed in .ssh for user are both user users now.
-rw-------. My list will help with this.

This sort of thing is why I was trying to print as root with lpr. I
already changed various permissions (/dev/null, /dev/pty*, etc.) to get
Xvesa, rxvt and Opera to work as user (with lots of help).

So I am currently dialed and sshed as root, as usual, not as user.

> Anyone that suggests you run X11 from inittab wants shooting -- that's a
> nasty RedHat-ism which I am pleased to say went away some years ago.
> The problem with running anything from inittab (X11 more so) is that
> if X cannot start, inittab (well, init actually, but let's not split
> hairs) attempts to continually launch it. This is bad.
>
> If you do some simple googling, there's many ways of automatically
> logging into X and starting applications up.

Is it okay to use Xvesa and rxvt and dial as root and then go online as
user? If not, I have to fix the dial problem before worrying about how I
go into X.

> Quoting Sindi Keesan (keesan at grex.cyberspace.org):
>
>>> (FWIW, American informal English increasingly uses "guys" to refer to
>>> both sexes, this being a tangle that cannot be undone in any clean
>>> fashion.)
>>
>> Only in the plural, and not everywhere in the country. Michigan uses 'you
>> guys' like other places use 'you all' or 'you uns' or 'youse'. One guy is
>> only male.
>
> One guy whom you are familiar with. It has been common to refer to an
> unknown person as a "guy", while knowing that the implication of a
> particular sex isn't quite right either, and knowing that English has,
> in general, hopeless structural problems of the sort that are inevitable
> when Latin and German collide and have a violent accident.

Actually French was much more heavily involved than Latin, as were the
Norse invaders.

>
> The lack of a proper second-person plural is of course another problem,
> and "y'all" is frequently heard in the USA even outside the South, as it
> may sound quaint and folksy, but at least gets you out of that
> particular pickle.
>
>>> 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.)
>>
>> I don't know enough to assess these things. Yet.
>
> Noted. But you asked the question, and I gave a fair if somewhat pithy
> answer. I might have been willing to give a more-detailed answer, but
> for my strong suspicion that most of your questions have been a bit
> unfocussed.

I don't know enough to ask an intelligent question in this area.

>> Is the threat that someone will get files onto my computer that will let
>> them use it to send spam? Or delete my files? (I have lots more copies).
>
> Quoting my old "Attacking Linux" article
> (http://security.itworld.com/4352/LWD000829hacking/pfindex.html),
>
> Some of those processes will be spy programs, running to capture login
> information entered by local users for remote systems elsewhere. Those
> will be logged and conveyed back to the attacker, giving him new

What would the programs do with my shell account, which is run as user,
send spam from it?

> targets. Some may be network sniffers, monitoring the traffic passing
> nearby, to or from other nearby machines, and likewise capturing private
> information for the bad guys. Those work by putting your network
> interface in promiscuous mode, in which the normal disregarding of other
> machines' network traffic gets disabled. Some may be clandestine network
> services, such as file-swapping, that are useful for the attacker and
> his friends. Most distressing of all, some may be carrying out attacks
> on other systems. The older variety of those involved flooding distant
> machines with either normal or deliberately malformed network traffic
> (ping, ping of death, smurf, SYN flooding, teardrop, land, bonk), as a
> denial of service (DoS) attack. Then starting last year, the

One of the browsers (Opera?) mentioned a DoS-related bug.

> more-organized DDoS tools (trinoo, Tribal Flood Network, stacheldraht,
> Trank, and so on) came to sudden public attention when they were used to
> overwhelm popular Internet sites. The third-party, subverted machines
> (zombies) used to carry out those attacks appear to have been university
> machines, favored for their lax security and high Internet bandwidth,
> but your Linux hosts could be the attackers' next tools.
>
> Even if your machines don't cause you that order of embarrassment, the
> other risks are equally grim: you can reveal confidential data with
> business and/or personal consequences, lose that data entirely, see it
> corrupted or sabotaged, be involved in wrongful or even criminal
> activity, lose access to your computing resources, and indirectly cause
> harm to your staff and business associates. Your Website can be defaced
> or modified, or visitors might be redirected by sabotaged company DNS
> servers to entirely different sites.
>
> (Please don't sit down and tell me that some or all of that doesn't
> apply to your situation. I really don't care -- no offence! -- and the
> answer is intended to be of general nature.)
>
>
>> I was told to use as firewall:
>>
>> ipchains -P forward DENY
>> ipchains -A forward -s 192.168.1.0/24 -j MASQ
>
> BTW, ipchains is old (though it still works, of course), having been
> long ago replaced by iptables.

The kernel documentation said something about this but I had only
instructions for ipchains since our usual kernel is 2.2 . So I figured
out how to compile for it. Someone kindly taught me how to compile
kernels and eventually some of them were not broken.

> "ipchains -P forward DENY" is a blanket default-deny rule on
> IP-forwarding only: It does nothing about what sort of packets are
> permitted in or out of the machine. That rule then gets modified by the
> command that follows.

forwarding of packets from the internet via the dialed-in computer
(gateway) to the other one, both on the same local network?

This will take some time to figure out. I have set up a network of
wireless router (into which I can plug ethernet cables) and laptop
computer with aironet 340 pcmcia wireless card. I could ping the router.
Eventually the laptop (in whatever part of the apartment has the strongest
signal) will pick up a free county wireless signal which I can then
somehow pass along to two desktop computers plugged into the router. I
run udhcpc to get an IP address assigned to the laptop (and similarly for
the desktops?) by the router. Do I need a firewall like the above on the
laptop computer?

>> Can you recommend a good online tutorial about networking and firewalls
>> and security which is smaller?
>
> Online and smaller? I'm not sure. TLDP's book-length "guides" might be
> good, but I haven't looked at them in a long time.
> http://www.tldp.org/guides.html

Someone else at our list recommended tldp.

> If you're up for reading RUTE, good for you! It's a very good book. It
> is also, of course, not primarily about security (if I recall correctly).

I only ran across it searching for a few terms you had mentioned.

>>> 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.)
>>
>> I did not compile nmap, the author of our distribution provided it.
>
> My point about local tools being perilous to rely on, if you have any
> reason to suspect security compromise, applies with or without local
> compilation.
>
>> I don't see how running as user would prevent the above anyway.
>
> I didn't say it would.
>
> You were asking why one would nmap-scan one's host from a nearby machine
> instead of scanning just localhost, which after all is simpler. One of
> several answers is the one I stated: that if you distrust local security
> for some reason, then you logically need to distrust the local copy of
> nmap, its console support libs, etc.

I have a little ramdisk version of our linux which is unchanging, and
could add nmap to it and scan with something trusted.

>> I have compiled a few executables which have not attacked me. How would I
>> know if source code was not to be trusted?
>
> That is a very profound question, as it turns out.
>
> People on Linux systems with package management tend to trust the code
> (both source and binary) provided with and through their distributions
> packages because of quality control by the package maintainers, attested
> to by cryptographic signing on the packages. Part of those package
> maintainers' jobs is to verify that "upstream" source code they fetch
> from the original developers and then package for their distros hasn't
> been tampered with, and is really from the upstream coders.
>
> The upstream coders are, generally, motivated to cryptographically sign
> their source code releases and make sure their signing keys are widely
> known, so that forgeries would be easily detected.
>
> Whenever you as an end-user take it upon yourself to fetch "upstream"
> source code (or upstream compile binaries, if any), you have implicitly
> assumed that quality-control burden for yourself.
>
> I have some more to say about that topic, here:
> http://linuxgazette.net/118/weatherwax.html#1
>
>

Is sourceforge considered safe?

>> My friends will not even have a compiler. So it appears they are safe,
>> with su user opera.
>
> Safe against...? Lack of a compile toolchain doesn't make one "safe".

They are not going to be installing anything, much less compiling anything
from unsafe source code. Just running one or two programs. Besides
running Opera (and maybe dialing and/or loading Xvesa and rxvt) as user
should I take any other precautions on their computers?

We just replaced the dead power supply, floppy drive (had to remodel
another to fit) and 20GB hard drive (with a 540MB) in a friend's
never-used 900MHz eMachine. 128MB RAM. Much faster than what we usually
put linux on. He wants part of it to be Windows (for familiarity) but we
can add up to 200MB of linux on for browsing. So I can try to include any
security features you want to recommend, since the basic software would be
under 50MB.

> On Mon, 29 Jan 2007, Rick Moen wrote:
> >> Besides running Opera (and maybe dialing and/or loading Xvesa and
> >> rxvt) as user should I take any other precautions on their computers?
> >
> > I don't know how many times I'm willing to say "Your design is
> > fundamentally bad, if only because it uses root logins by default."
> > This is probably the last time, as obviously I'm wasting my time.
> > I stated, for that reason, that I was uninterested in helping users
> > unwilling to do that basic step correctly -- and I meant what I said.
>
>
> We had a long discussion about why it is bad to go online as root, which
> is how Basiclinux is set up to operate.
>
> My current compromise is to:
>
> 1. Dial as root (because dialing as user would give the user access to
> the login name and password, which would then let anyone with access to
> the user account know these, and besides if I try to dial as user pppd
> complains about not having /etc/ppp/options, which root does not need).

Just to correct a misconception on your part: the information in
/etc/ppp/*-secrets does not have to be readable by the user; this is why
'/usr/sbin/pppd' is set SUID 0. In fact, that's the default
configuration on every Linux system I've seen, including the one I've
just set up on my new laptop:

The above means that any user who is part of group 'dip' can execute
'pppd' - and since 'pppd' runs as root, it can read the files that
contain the name and the password.

In other words, it appears as though you're taking a mechanism that
works just fine and changing it so that it will do the same thing as
it's doing now. I suggest that understanding the current mechanism would
serve you better than trying to construct something new from the ground
up - especially since it's not new.

> 3. Put into /home/user/profile the line startx (rather than editing
> inittab to make vt1 run X, which does not work any more anyway once you
> add a user account).

This means, of course, that you'll be trying to start X every time you
log in. Perhaps making it conditional would work better.

> Actually French was much more heavily involved than Latin, as were the
> Norse invaders.

I'm quite minutely familiar with that history, Sindi, for multiple
reasons including my principal ancestors having been the main threat to
civilisation at that time (Vikings) -- and, as I hoped would be apparent,
was speaking metaphorically, i.e., of the collision between the language
families involved.

> What would the programs do with my shell account, which is run as user,
> send spam from it?

Let me turn that around and suggest that you think through the
possiblities. You have everything you need to do so.

> forwarding of packets from the internet via the dialed-in computer
> (gateway) to the other one, both on the same local network?

Sorry, I'm about done with the idle questions for which you can
determine the answers from standard resources. In addition to manpages
(which are often dauntingly terse, by design), try TLDP's HOWTOs, such
as this one:

The Answer Gang is quite tolerant generally about questions, but at a
certain point we expect the querent to engage with the subject matter.
A check of my sent mail reveals that you've been exchanging mail with
tag since at least 2003. It's time for you to resolve some basic
informational questions on your own, in my view.

> Do I need a firewall like the above on the laptop computer?

Please re-read my earlier mails, on how you determine what security
measures you "need".

> Is sourceforge considered safe?

Well, all of VA Linux Systems, Inc.'s corporate network was
security-compromised in 2001 because of a sysadmin incautiously visiting
shells.sourceforge.net (which was root-compromised at the time) and then
sshing or scping back into the corporate network. At the same time,
almost all development code being handled via shells.sourceforge.net
and hosted on SourceForge.net proved at the time to be verifiably
uncorrupted because the developers had cryptographically signed their
work.

All of the machines withing VA Linux Systems were powered down and their
ethernet ports disabled, after which every last one of them had to be
wiped and reinstalled, with any restored non-executable, non-conffile
data files needing to be carefully vetted.

I would not really call that "safe", personally.

> Besides running Opera (and maybe dialing and/or loading Xvesa and
> rxvt) as user should I take any other precautions on their computers?

I don't know how many times I'm willing to say "Your design is
fundamentally bad, if only because it uses root logins by default."
This is probably the last time, as obviously I'm wasting my time.
I stated, for that reason, that I was uninterested in helping users
unwilling to do that basic step correctly -- and I meant what I said.

>> What would the programs do with my shell account, which is run as user,
>> send spam from it?
>
> Let me turn that around and suggest that you think through the
> possiblities. You have everything you need to do so.
>
>> forwarding of packets from the internet via the dialed-in computer
>> (gateway) to the other one, both on the same local network?
>
> Sorry, I'm about done with the idle questions for which you can
> determine the answers from standard resources. In addition to manpages
> (which are often dauntingly terse, by design), try TLDP's HOWTOs, such
> as this one:
>
> http://tldp.org/HOWTO/IPCHAINS-HOWTO.html

Thanks. I have read other HOWTOs (ethernet, wireless).

> The Answer Gang is quite tolerant generally about questions, but at a
> certain point we expect the querent to engage with the subject matter.
> A check of my sent mail reveals that you've been exchanging mail with
> tag since at least 2003. It's time for you to resolve some basic
> informational questions on your own, in my view.

Okay, I will take some time off exchanging emails to do some reading.
I have not had time recently to do both and also get any work done.

>> Besides running Opera (and maybe dialing and/or loading Xvesa and
>> rxvt) as user should I take any other precautions on their computers?
>
> I don't know how many times I'm willing to say "Your design is
> fundamentally bad, if only because it uses root logins by default."
> This is probably the last time, as obviously I'm wasting my time.
> I stated, for that reason, that I was uninterested in helping users
> unwilling to do that basic step correctly -- and I meant what I said.

Okay, I will ask for help from my distribution's mailing list members.

>> Besides running Opera (and maybe dialing and/or loading Xvesa and
>> rxvt) as user should I take any other precautions on their computers?
>
> I don't know how many times I'm willing to say "Your design is
> fundamentally bad, if only because it uses root logins by default."
> This is probably the last time, as obviously I'm wasting my time.
> I stated, for that reason, that I was uninterested in helping users
> unwilling to do that basic step correctly -- and I meant what I said.

We had a long discussion about why it is bad to go online as root, which
is how Basiclinux is set up to operate.

My current compromise is to:

1. Dial as root (because dialing as user would give the user access to
the login name and password, which would then let anyone with access to
the user account know these, and besides if I try to dial as user pppd
complains about not having /etc/ppp/options, which root does not need).

2. Copy over all the files from /root to /home/user with cp -a * and also
cp -a .*, except that Opera has subdirectories so just start over again
setting parameters for user. Also chown user * and chown user .* and
make /dev/null writable by user.

3. Put into /home/user/profile the line startx (rather than editing
inittab to make vt1 run X, which does not work any more anyway once you
add a user account).

4. Login user, which starts X (and you can exit X if desired).
Or su user and don't start X.

5. Run Opera or other programs from the wm menu as user (having made them
all executable by user or chmod +s).

I will solve the problem of files needed by user but not root for ssh
eventually. The paths are different for user and root (user has no /sbin
or /usr/sbin). So pppd is not on the path for user (/usr/sbin) Probably
because user is not supposed to dial. But ssh is on the path. I will try
to find instructions for our ssh. I may need /home/user/.ssh/config or
/etc/ssh/ssh_config

I have set up a computer for a friend to use without ssh, as above.

Thanks to all of you for the help.

I ran across an article by Rick on using multiple monitors with X.
TAG once helped me use two monitors without X (MGA and VGA cards).

> On Wed, Feb 28, 2007 at 06:39:34PM -0500, Sindi Keesan wrote:
>>
>> My remaining problem is that ssh is working on one computer (with a
>> standard hardware modem) but not on the two with internal lucent modems
>> (where pppd for some reason is accessing ttyS1 and also ttyLT0).
>
> SSH is an application; it doesn't (can't) care about the kind of
> hardware you use for networking.

It is not working on another computer with hardware modem.

>> Host key verification failed if I ssh without the login.
>
> Quick guide to SSH "key auth" configuration, assuming "host1" as your
> computer, "host2" as the remote machine, and "keesan" as the name of the
> user on both hosts:
>
> 1) Create the public/private keypair on host1 by running "ssh-keygen -t dsa".

I compiled a putty version puttygen and will try it later. It is on a
computer at another location. Root does not seem to use this method.

> 2) Copy the public key (the contents of /home/keesan/.ssh/id_dsa.pub)
> from host1 into /home/keesan/.ssh/authorized_keys on host2.

Will try this later. Maybe there is some easier method.
Below are the log files.

I managed to copy the verbose output to a file. I don't have gpm
installed here. splitvt says it needs VT100 (when run as user) and
screen complained about no PTTYs (which I think is related to the rxvt
problem).

What I did was make two xterms (as user) and then edit my alias for using
Xvesa to add -2button (rather than using the standard X server, which says
not to run it as SUID, whereas Xvesa says to run it SUID), and use the
right button to copy and both buttons to paste. I normally use X only for
Opera and xpdf.

I uploaded ssh.log (to my shell account at the bbs where I am getting TAG
mail) via kermit because various permissions are broken at the bbs I am
using for mail since the volunteer staff did an emergency disk removal
(ftp appears to be dead even for root, which could be why psftp won't
work for user today). Here it is for 'user':

My neighbor's Fedora installation, when I typed set from an xterm (we were
looking for the path when his realplayer.bin file would not run, because
it was in /root/Desktop), listed the location of ssh-askpass, which I do
not have. Root on my system can ssh without it. The above looks like a
default for some other linux. Does ssh-askpass contain the password?
I enter it manually. I have several logins and paswords.

> 3) Execute "ssh keesan at host2" on host1 to log into host2.
>
> If you suspect that you messed up anywhere along the way, wipe out all
> the files in ~/.ssh on both machines and restart from scratch.

I have done that before without it helping, but not with the above method.

Root connects, without using id_dsa. It asks me for my password and I
give it and connect. It does not ask user for password, on this computer.
It does on one other computer. Maybe I got permissions correct on some
file there?.

>> I am happy dialing as user and ssh'ing as root, and my friends are
>> unlikely to ssh at all, but I would like to understand what is going on
>> with ssh. This continues to be educational.
>
> As Kapil pointed out, if you really want to know what's going on, use
> a non-broken distro and run 'strace'. You'll see all the system calls,
> failed file requests, etc.

I used strace when realplayer would not install on most of my computers
but could not figure out the output.

I have a shell account at the Slackware 10.2 computer of one of our list
members (also a TAG member). I will try ssh there and look at the verbose
output later. I suspect I missed changing some permissions on three
computers.

I looked at my neighbor's Fedora installation last night. It would not
play MP3s from an ipod and wanted Realplayer, which he had two copies of
on his desktop, neither installed. I showed him how to find their
locations (no 'locatedb' but he had 'find' and we also could click on
Properties) and run them when not on the path with './' and it wanted a
library he did not have. He did not know if he has mpg123. He has been
using linux much longer than me. He spent 1/2 hour updating a bunch of
programs online, most of which he has never used. He rebooted several
times at a few minutes per boot, loading things he did not know if he used
such as crontab. I would rather start small and add things I need.

> The 'root' account is made to operate with literally no security
> restrictions. Have you not heard what all of us here have been telling
> you? This is precisely why it's so dangerous.

Root was ssh'ing with known_hosts and password.

> Since I have no idea what the configuration for the other user is, I
> can't tell you why it works: you've only shown me these two log reports.

Wrong permissions for accessing tty.
Do you want to explain what ssh does with tty?

>
>> My neighbor's Fedora installation, when I typed set from an xterm (we were
>> looking for the path when his realplayer.bin file would not run, because
>> it was in /root/Desktop), listed the location of ssh-askpass, which I do
>> not have. Root on my system can ssh without it. The above looks like a
>> default for some other linux. Does ssh-askpass contain the password?

>> debug1: next auth method to try is keyboard-interactive
>> debug1: authentications that can continue:
>> publickey,password,keyboard-interactive
>> debug1: next auth method to try is password
>> debug1: ssh-userauth2 successful: method password
>
> And here is the auth method that succeeds: kb-interactive (i.e., you
> typed in the password) and system password auth based on that.

It required user access to tty to do that.

>> debug1: fd 7 setting O_NONBLOCK
>> debug1: channel 0: new [client-session]
>> debug1: send channel open 0
>> debug1: Entering interactive session.
>> (and much more)
>>
>> Root connects, without using id_dsa. It asks me for my password and I
>> give it and connect. It does not ask user for password, on this computer.
>> It does on one other computer. Maybe I got permissions correct on some
>> file there?.
>
> It's not about permissions. It's about missing necessary parts of the
> package.

It was wrong permissions in this case. The keyboard-interactive part
works now for 'user'. The error message was about permission.

>> I used strace when realplayer would not install on most of my computers
>> but could not figure out the output.
>
> Hint: a non-broken distro will include 'man strace'.

I don't understand the vocab and syntax of most man pages. My list
members suggested it but nobody figured out what went wrong. Again,
something worked on only one computer. Mplayer is better anyway.

>
> The fact that your neighbor doesn't know anything about Linux - and
> having multiple copies of uninstalled binaries sitting on his "desktop",
> as well as not knowing how to tell if a program is installed argues for
> a deep level of ignorance - implies absolutely nothing about small or
> large distros.
>
> To continue the car analogy, what you're doing is equivalent to grabbing
> a random hunk of metal out of a junkyard full of old trucks, trying to
> fit it to a stripped race-car frame, and trying to see if you can run
> the resulting gadget at a hundred miles an hour - all before installing
> the brakes, and without any knowledge of mechanics. What all of us have
> been telling you to do is to use an existing car, and carefully remove
> the parts that you decide you don't need (at least the brakes are
> guaranteed to be there, and you'll know that you removed them if you
> decide to do so.)
>

I don't drive, I bike ;=) It gets me places at the speed I want, seeing
much more along the way and meeting nice people, and without wasting
resources. Our bikes are put together out of parts from abandoned ones.
We know how they work and how to maintain them.

I would have no idea what parts could be safely removed off anything as
large and unwieldy as a car. I know what most of the bike parts do. We
might spend more time working on our bikes than the average car owner does
on a car, but we enjoy it. And we don't spend time making money to buy
the car, insure, or feed it. Bikes start instantly without warmup and
work in all temperatures. They exercise body and mind. (I do avoid ice).

The author of our distribution also bikes and does not drive. It attracts
the do-it-yourselfers.

I think with your help I either have everything working for user, or have
a better idea how to attack it by changing permissions and making sure
things are on the path. I would not have learned this from Fedora.

> On Thu, 1 Mar 2007, Ben Okopnik wrote:
> >
> >To continue the car analogy, what you're doing is equivalent to grabbing
> >a random hunk of metal out of a junkyard full of old trucks, trying to
> >fit it to a stripped race-car frame, and trying to see if you can run
> >the resulting gadget at a hundred miles an hour - all before installing
> >the brakes, and without any knowledge of mechanics. What all of us have
> >been telling you to do is to use an existing car, and carefully remove
> >the parts that you decide you don't need (at least the brakes are
> >guaranteed to be there, and you'll know that you removed them if you
> >decide to do so.)
>
> I don't drive, I bike ;=) It gets me places at the speed I want, seeing
> much more along the way and meeting nice people, and without wasting
> resources. Our bikes are put together out of parts from abandoned ones.
> We know how they work and how to maintain them.

But you see, that's precisely my point. Once you know the system, you
can fiddle with it to your heart's content - you understand the limits,
what you can and can't do, etc. When you don't know the system - as is
the case here - fiddling is essentially pointless.

A bicycle is a simple system, with few parts and not too many possible
system interactions (and thus easily comprehensible - a finite problem.)
An operating system is nothing like this: it is a highly complex
system - a number of orders of magnitude higher than a bicycle - and the
number of its possible internal and external interactions very quickly
approaches infinity. Fiddling with a part of it may teach you about that
part - but what you've learned is likely to be completely wrong, since
you don't have the overall picture.

It is possible to get a solid general overview of how an OS works; this
is, in fact, necessary if you're going to tweak various factors if
you're to have any hope of ending up with anything but a random mess.
You're trying to do it by fiddling; a patently bad approach.

> On Thu, Mar 01, 2007 at 09:13:17PM -0500, Sindi Keesan wrote:
>> On Thu, 1 Mar 2007, Ben Okopnik wrote:
>>>
>>> To continue the car analogy, what you're doing is equivalent to grabbing
>>> a random hunk of metal out of a junkyard full of old trucks, trying to
>>> fit it to a stripped race-car frame, and trying to see if you can run
>>> the resulting gadget at a hundred miles an hour - all before installing
>>> the brakes, and without any knowledge of mechanics. What all of us have
>>> been telling you to do is to use an existing car, and carefully remove
>>> the parts that you decide you don't need (at least the brakes are
>>> guaranteed to be there, and you'll know that you removed them if you
>>> decide to do so.)
>>
>> I don't drive, I bike ;=) It gets me places at the speed I want, seeing
>> much more along the way and meeting nice people, and without wasting
>> resources. Our bikes are put together out of parts from abandoned ones.
>> We know how they work and how to maintain them.
>
> But you see, that's precisely my point. Once you know the system, you
> can fiddle with it to your heart's content - you understand the limits,
> what you can and can't do, etc. When you don't know the system - as is
> the case here - fiddling is essentially pointless.
>
> A bicycle is a simple system, with few parts and not too many possible
> system interactions (and thus easily comprehensible - a finite problem.)
> An operating system is nothing like this: it is a highly complex
> system - a number of orders of magnitude higher than a bicycle - and the
> number of its possible internal and external interactions very quickly
> approaches infinity. Fiddling with a part of it may teach you about that
> part - but what you've learned is likely to be completely wrong, since
> you don't have the overall picture.

My linux is already a custom bicycle. Much smaller (not designed to haul
a crowd and three dogs), not full of gadgets like cup holders that are in
there 'just in case' someone might want to use them. And it works to
start with, for a single user, faster and more transparently than the
big-box models. It does what it is designed to do. I would rather add
any pieces I want than strip out 90% of what is there to make it go
faster. A matter of taste.

I don't like things to be automated. I LIKE inserting modules one at a
time (and it avoids the bugs such as needing to insmod gameport, which is
not on the list for some sound cards but is needed anyway).

With less pieces, it is less complicated to understand. Not that I claim
to understand most of what is in there but I prefer to start small.

I was advised to use the larger version to go online as 'user', by the
author. Karolis (in our BL group and TAG) will work on why the browsers
cannot read or write their configuration files as 'user' in the smaller
version. The passwords are shadowed in the smaller version, if I
understood right, so permissions might need to be different. (?)

So I am now stripping pieces from the larger version. I don't need most
of bin.tgz, for instance. I kept splitvt. I do need cpio (the busybox
version is inadequate) or rpm2cpio might work instead. I am recompiling
busybox and leaving out programs that were left out in the smaller version
(hexdump). I can put them back later if needed. This is educational.
I removed all the kernel source code not for i386 - half of the total.
Lots of glibc etc. is not needed (.a .pa .la, locale, most terminfo....) -
I left in what is used in the smaller version (vt100, linux, etc.).
I still have a whole 775MB of files (including source code for two
kernels but not for programs and 110MB uclibc). Karolis compiled a much
smaller uclibc (38MB and going down). My basic version of the smaller
linux is only 35MB (four browsers in there) without the ability to
compile.

> It is possible to get a solid general overview of how an OS works; this
> is, in fact, necessary if you're going to tweak various factors if
> you're to have any hope of ending up with anything but a random mess.
> You're trying to do it by fiddling; a patently bad approach.

Yes, I did make a mess of the permissions and thanks for explaining them.
Also how security works (ssh). I should do more reading before I change
things. So far I broke nothing (that I know of) which I did not fix.
I have lots of backup copies.

Maybe opera will work for user on another copy - I messed them all up a
bit differently (but kept a master copy). We have 24 potentially working
desktop computers.

My approach comes from being a technical translator with short deadlines.
Get it working from a superficial knowledge because there is never time to
go into the details. I will let my friends continuing browsing as root
until I can understand the details this time. It is a vast improvement
over Windows (which on one computer was so virus-ridden it no longer
worked with the modem anyway, which works now with linux). If they kill
linux I can recopy it from a 23MB backup file in DOS.

Thanks again for your help and patience. I hope other people also learned
something useful.

> I was advised to use the larger version to go online as 'user', by the
> author. Karolis (in our BL group and TAG) will work on why the browsers
> cannot read or write their configuration files as 'user' in the smaller
> version. The passwords are shadowed in the smaller version, if I
> understood right, so permissions might need to be different. (?)

The problem:

~<$> echo $HOME
/root

Lynx and all the programs look at this variable to figure out where
are the config files located - $HOME/.lynx or $HOME/.opera. They
expand the path to /root/.lynx or /root/.opera, and, because of that,
the applications get permission errors - the files are owned by root,
not the user.

To fix this once and for all, comment out the following line in
/etc/profile:

export HOME=/root

This is a bug in passwd.tgz's install.sh (it should comment out that
line when installed) and will be reported to BasLinux's mailing list.

> On Wed, Mar 07, 2007 at 12:11:59PM -0500, Sindi Keesan wrote:
>> I was advised to use the larger version to go online as 'user', by the
>> author. Karolis (in our BL group and TAG) will work on why the browsers
>> cannot read or write their configuration files as 'user' in the smaller
>> version. The passwords are shadowed in the smaller version, if I
>> understood right, so permissions might need to be different. (?)
>
> The problem:
>
> ``
> ~<$> echo $HOME
> /root
> ''
>
> Lynx and all the programs look at this variable to figure out where
> are the config files located - $HOME/.lynx or $HOME/.opera. They
> expand the path to /root/.lynx or /root/.opera, and, because of that,
> the applications get permission errors - the files are owned by root,
> not the user.
>
> To fix this once and for all, comment out the following line in
> /etc/profile:
>
> ``
> export HOME=/root
> ''
>
> This is a bug in passwd.tgz's install.sh (it should comment out that
> line when installed) and will be reported to BasLinux's mailing list.
>
> Karolis Lyvens
>

Karolis has been fixing all my problems by using strace, which shows where
a program failed.

Ssh has configuration files in /root/.ssh/ drwx------
I had made known_hosts world-readable. But not random_seed.
It is working for user though .ssh is not world-readable.

The files in .links are world-readable - so it works for 'user' but I
cannot write changed preferences. Apparently the directory permissions
do not need to be changed, just file permissions.

/root/.xinitrc was also world-readable, and .pmailrc.

I also had to chmod o+w for /dev/dsp* and /dev/lp*, so as to listen
to music and print (plus all the ?tty* devices so as to use rxvt and ssh,
and dial). Is there any danger in making all devices read/write for
users?

There is a new basiclinux coming out shortly, and permission changes could
be made in there or in the passwd.tgz package used to add user accounts.

> There is a new basiclinux coming out shortly, and permission changes could
> be made in there or in the passwd.tgz package used to add user accounts.

The fact that something so fundamental was broken like that in the first
place is enough for me to dismiss this distribution. Frankly, given the
amount of effort needed to do anything, and given that many other
distributions are much more ubiquitous in their operation and the tools
used, the choice is simple.

-- Thomas Adam

--
"He wants you back, he screams into the night air, like a fireman going
through a window that has no fire." -- Mike Myers, "This Poem Sucks".

I got Basiclinux 3.40 (libc5) mostly working online. Besides making eznet
and Xvesa SUID, I made symlinks to the dialing scripts from /usr/sbin to
/usr/bin (which is on the path for user).

A book said for single-user systems you can make the devices a+rw rather
than making them rw for groups (my only user is in just one group). So I
did chmod o+rw on all the tty* devices as well as /dev/null (needed by
Opera). Are there devices which should NOT be rw for user?

A couple of new puzzles which I need help with:

"PRNG is not seeded" when I try to ssh.
ssh -v provides no further information.

An internet search reveals:
"If you do not have /dev/random on your system you will get a "PRNG not
seeded" error message.

We don't have it but I could mknod /dev/random c 1 8.

PRNG is still not seeded.

It did not help to make /dev/random o+w or o+x.

In BL2.1, /home/user/.ssh files are owned by 100 100 and /etc/group says
users are 100. (I had changed ownership to user users). ssh works here.

In BL3 (which ssh works only for root) they are owned by user 500 (user
is in a group called 500). Should it be 500 500 instead?

Deleting the files in /home/user/.ssh did not help.
------------------

> A couple of new puzzles which I need help with:
>
> "PRNG is not seeded" when I try to ssh.
> ssh -v provides no further information.
>
> An internet search reveals:
> "If you do not have /dev/random on your system you will get a "PRNG not
> seeded" error message.
>
> We don't have it but I could mknod /dev/random c 1 8.
>
> PRNG is still not seeded.
>
> It did not help to make /dev/random o+w or o+x.

You generally need read access to /dev/random. It amy also be
necessary to use /dev/urandom (mknod /dev/urandom c 1 9).

Of course both these devices will not work if the kernel's random
number support is unavailable (I think Linux 2.0 added this support
but I am not sure).

> In BL3 (which ssh works only for root) they are owned by user 500 (user
> is in a group called 500). Should it be 500 500 instead?

There is also the need to create .rnd in the $HOME directory. So the
$HOME directory has to be readable/writable by the user who is making
use of "ssh".

>> "PRNG is not seeded" when I try to ssh.
>> ssh -v provides no further information.
>>
>> An internet search reveals:
>> "If you do not have /dev/random on your system you will get a "PRNG not
>> seeded" error message.
>>
>> We don't have it but I could mknod /dev/random c 1 8.
>>
>> PRNG is still not seeded.
>>
>> It did not help to make /dev/random o+w or o+x.
>
> You generally need read access to /dev/random. It may also be
> necessary to use /dev/urandom (mknod /dev/urandom c 1 9).

We had /dev/urandom, not writeable by 'other'. chmod o+w fixed it.

> Of course both these devices will not work if the kernel's random
> number support is unavailable (I think Linux 2.0 added this support
> but I am not sure).

Kernel 2.2.26 worked. We are 'modern'. Unfortunately USB storage got
back-ported and is broken so I usually use 2.4.31 (which has its own
bugs).

> There is also the need to create .rnd in the $HOME directory. So the
> $HOME directory has to be readable/writable by the user who is making
> use of "ssh".

/home and /home/user are drwxr-xr-x user 500 (writeable by user).
500 is the group where user is. I don't see a .rnd in either.

Opera has a 'preference initialization failure' as user.
Lynx and links can't read/write .lynxrc or links.cfg.

They all work in BL2.1 not BL3.4 for user. I copied these all from /root
and changed ownerships. They are all rw for the owner (user).

> I got Basiclinux 3.40 (libc5) mostly working online. Besides making eznet
> and Xvesa SUID, I made symlinks to the dialing scripts from /usr/sbin to
> /usr/bin (which is on the path for user).

> A couple of new puzzles which I need help with:
>
> "PRNG is not seeded" when I try to ssh.

> An internet search reveals:
> "If you do not have /dev/random on your system you will get a "PRNG not
> seeded" error message.
>
> We don't have it but I could mknod /dev/random c 1 8.
>
> PRNG is still not seeded.
>
> It did not help to make /dev/random o+w or o+x.

More research reveals that /dev/urandom is sufficient and is consulted
before /dev/random. (I used lynx as 'root' for a while to learn this).

> A couple of new puzzles which I need help with:
>
> "PRNG is not seeded" when I try to ssh.
> ssh -v provides no further information.
>
> An internet search reveals:
> "If you do not have /dev/random on your system you will get a "PRNG not
> seeded" error message.
>
> We don't have it but I could mknod /dev/random c 1 8.
>
> PRNG is still not seeded.
>
> It did not help to make /dev/random o+w or o+x.

You could try the following command, which makes that missing device
(which is /dev/urandom, not /dev/random):

mknod /dev/urandom c 1 9

If my memory isn't lying to me, that fixed an exactly the same error
when I tried to use openssh on BasLinux.

For directories, it means that for any file in that directory, only the
owner and root can remove that file regardless of permissions. This is
why some people also call it the "cooperative" bit: it's a good idea to
set it on directories where people are likely to share files.

> On Mon, Mar 05, 2007 at 12:00:19PM -0500, Sindi Keesan wrote:
>>
>> In BL2.10 /tmp is drwxrwxrwt. (Sticky bit set).
>> Running Linux says this means 'Keep executable in memory after exit'. ??
>
> For directories, it means that for any file in that directory, only the
> owner and root can remove that file regardless of permissions. This is
> why some people also call it the "cooperative" bit: it's a good idea to
> set it on directories where people are likely to share files.

So people can copy each other's files but not delete them?
Totally irrelevant for a single-user system.
Running Linux seems to be wrong here.

> On Wed, 7 Mar 2007, Ben Okopnik wrote:
>
> >On Mon, Mar 05, 2007 at 12:00:19PM -0500, Sindi Keesan wrote:
> >>
> >>In BL2.10 /tmp is drwxrwxrwt. (Sticky bit set).
> >>Running Linux says this means 'Keep executable in memory after exit'. ??
> >
> >For directories, it means that for any file in that directory, only the
> >owner and root can remove that file regardless of permissions. This is
> >why some people also call it the "cooperative" bit: it's a good idea to
> >set it on directories where people are likely to share files.
>
> So people can copy each other's files but not delete them?

No - so they can modify each other's files (assuming the permissions
are right) but not delete them.

> >>>>
> >>>>In BL2.10 /tmp is drwxrwxrwt. (Sticky bit set).
> >>>>Running Linux says this means 'Keep executable in memory after exit'. ??
> >>>
> >>>For directories, it means that for any file in that directory, only the
> >>>owner and root can remove that file regardless of permissions. This is
> >>>why some people also call it the "cooperative" bit: it's a good idea to
> >>>set it on directories where people are likely to share files.
> >>
> >>So people can copy each other's files but not delete them?
> >
> >No - so they can modify each other's files (assuming the permissions
> >are right) but not delete them.
> >
> >>Totally irrelevant for a single-user system.
>
> Would this let 'user' modify files owned by 'root'?

Assuming that the permissions are right, yes. The sticky bit on the
directory doesn't modify the effect of the file permissions; it affects
the way that the directory permissions are applied (directory
permissions are, unfortunately, often poorly understood by the average
*nix user - and even by many nominal sysadmins.)

> >>Running Linux seems to be wrong here.
> >
> >No, it's right - for files (although as I understand it, that usage is
> >no longer supported in newer Linux versions.) For directories, it has a
> >different meaning as I described.
> I don't know whether my libc5 linux qualifies as newer or older ;=)

It's a question of policy rather than libc.

> svgalib is now available with a module and device that can be used instead
> of running it svgalib, but I seem to be missing two files in 2.4.31 kernel
> source that it wants to compile with. (Not in the kernel source on the
> Slackware 10.2 CD).
>
> The latest zgv (svgalib-based viewer) ver 5.9 has some new way of making
> it more secure. The suid part is run only very briefly and then dropped
> somehow. I could post the explanation if you like.

No need - that's a very common (and effective where it's appropriate)
technique; e.g., many webservers do exactly that. They require root
privileges in order to bind to a low port (80, for HTTP), but after
that, drop down to user 'apache' or 'nobody'. That way, if somebody does
manage to crack into the server, they'll only gain a tiny, marginal set
of privileges on the system.

I have been experiencing spontaneous permission changes on devices after
using them as user:

/dev/ttyS1 (needed to dial with pppd and hardware modem)
/dev/ttyp0 (needed by rxvt)

And on another computer

/dev/ttyLT0 (lucent modem)

The lucent modem ownership was root tty (I had made it match all the other
ttys that came with Basiclinux 2.1.

Various online suggestions from people with similar problems were:

1. something happened when they used samba (I don't have that);

2. they shut down with the application (Eterm) running - I cannot shut
down with rxvt running, if I hit Ctrl-Alt-Del it just exits X.

3. something to do with kernel 2.2.19 and the program expected 2.4.31
(I have 2.4.31 kernel)

someone fiddled with file permissions and ownerships and fixed it.

So I looked at Basiclinux 3 and the ownership is root root, not root tty.
I don't recall having similar problems there.

I had ownerships root tty for /dev/ttyLT0 (on this computer) and root root
for /dev/ttyp0) (on this computer) and the former kept resetting when I
rebooted and the latter did not. I might have all tty* root tty on the
other computer. I have been messing around too much. I KNOW some things
came set root tty.

I changed group of ttyLT0 to users and the problem is cured.

Should I be using root root or root users for my devices that I want to be
accessible to user? ttyS1 or ttyLT0, and ttyp0-4 (four rxvts), and
/dev/dsp0 (sound) and /dev/lp0 (printer). These are currently all root
root except for the serial/modem devices.

Setting things 'group tty' appears to reset permissions so only root can
write to the device.

> I am still getting spontaneous permission resets on this other computer
> with /dev/ttyS1 as 'root tty' 'root root' or 'root users'.
>
> Any ideas other than resetting permissions in an rc file when I boot?
> Is there a file I can use to reset permissions when I login as a user?

I wasn't following this from the start but,
You are not by any chance using udevd are you???

> On Mon, 26 Mar 2007, MNZ wrote:
>
> >On Mon, Mar 26, 2007 at 01:00:44PM -0400, Sindi Keesan wrote:
> >>I am still getting spontaneous permission resets on this other computer
> >>with /dev/ttyS1 as 'root tty' 'root root' or 'root users'.
> >>
> >>Any ideas other than resetting permissions in an rc file when I boot?
> >>Is there a file I can use to reset permissions when I login as a user?
> >
> >I wasn't following this from the start but,
> >Ypu aren't by any chance using udevd are you??
>
> Unlikely, since I don't even know what udevd is or does. But thanks for
> the idea. You did not post to TAG, just to me.

udev handles devices, it populates /dev on startup. The permissions would
be reset each time you reboot and set again by udev rules.

Actually I sent the messages to TAG and forget CCing it to you, so I sent
you the same again.

> This is a small Slackware 7.1 based distribution designed to be run as
> root.

>>> On Mon, Mar 26, 2007 at 01:00:44PM -0400, Sindi Keesan wrote:
>>>> I am still getting spontaneous permission resets on this other computer
>>>> with /dev/ttyS1 as 'root tty' 'root root' or 'root users'.
>>>>
>>>> Any ideas other than resetting permissions in an rc file when I boot?
>>>> Is there a file I can use to reset permissions when I login as a user?
>>>
>>> I wasn't following this from the start but,
>>> Ypu aren't by any chance using udevd are you??
>>
>> Unlikely, since I don't even know what udevd is or does. But thanks for
>> the idea. You did not post to TAG, just to me.
>
> udev handles devices, it populates /dev on startup. The permissions would
> be reset each time you reboot and set again by udev rules.
>
> Actually I sent the messages to TAG and forget CCing it to you, so I sent
> you the same again.
>
>> This is a small Slackware 7.1 based distribution designed to be run as
>> root.

I searched MANIFEST.gz, and Slackware 7.1 does not have udevd (nor do I).
Isn't there some way to prevent permissions from being reset, rather than
resetting them during boot or login?

> >>Unlikely, since I don't even know what udevd is or does. But thanks for
> >>the idea. You did not post to TAG, just to me.
> >
> >udev handles devices, it populates /dev on startup. The permissions would
> >be reset each time you reboot and set again by udev rules.
> >
> >Actually I sent the messages to TAG and forget CCing it to you, so I sent
> >you the same again.
> >
> >>This is a small Slackware 7.1 based distribution designed to be run as
> >>root.
>
> I searched MANIFEST.gz, and Slackware 7.1 does not have udevd (nor do I).
> Isn't there some way to prevent permissions from being reset, rather than
> resetting them during boot or login?

Have you got devfs? check the kernel (assuming you are using an old one
more than version 2.3.46) config for CONFIG_DEVFS_FS=y and
CONFIG_DEVFS_MOUNT=y. Or simply try "# mount" and check if /dev is a devfs

If you do have devfs, you'll have to use devfsd to control permissions
across reboots (or just do it from an rc file

> On Mon, Mar 26, 2007 at 04:14:47PM -0400, Sindi Keesan wrote:
> > >>Unlikely, since I don't even know what udevd is or does. But thanks for
> > >>the idea. You did not post to TAG, just to me.
> > >
> > >udev handles devices, it populates /dev on startup. The permissions would
> > >be reset each time you reboot and set again by udev rules.
> > >
> > >Actually I sent the messages to TAG and forget CCing it to you, so I sent
> > >you the same again.
> > >
> > >>This is a small Slackware 7.1 based distribution designed to be run as
> > >>root.
> >
> > I searched MANIFEST.gz, and Slackware 7.1 does not have udevd (nor do I).
> > Isn't there some way to prevent permissions from being reset, rather than
> > resetting them during boot or login?
>
> Have you got devfs? check the kernel (assuming you are using an old one
> more than version 2.3.46) config for CONFIG_DEVFS_FS=y and
> CONFIG_DEVFS_MOUNT=y. Or simply try "# mount" and check if /dev is a devfs
>
> If you do have devfs, you'll have to use devfsd to control permissions
> across reboots (or just do it from an rc file

To clear up the matter about devfs/udev in BL:

Baslinux runs on 2.2.26 kernel by default, which is pre-devfs/hotplug
(which appeared in 2.4, if I'm not mistaken). There are several 2.4
images available, but BL doesn't use devfs. 2.6.x kernel isn't used in
BL at all (it could be compiled, but there's no need for that), so it
can't possibly have udev.

Instead of all this fancy automatic stuff, we use mknod to manually
create and manage our devices

> To clear up the matter about devfs/udev in BL:
>
> Baslinux runs on 2.2.26 kernel by default, which is pre-devfs/hotplug
> (which appeared in 2.4, if I'm not mistaken). There are several 2.4
> images available, but BL doesn't use devfs. 2.6.x kernel isn't used in
> BL at all (it could be compiled, but there's no need for that), so it
> can't possibly have udev.
>
> Instead of all this fancy automatic stuff, we use mknod to manually
> create and manage our devices

I think the "udev/devfs" stuff was a McGuffin.

The original problem was that "some" program was changing the permissions
of the "dialout" device.

Now, if devices are removed and created (a la devfs/udevd) by some
automated process then that could be the reason for the changing
permissions.

Otherwise, it is some other program...

Unfortunately, it seems as if too many aspects of BL are
"non-standard" for most of us to be able to help in debugging this.
This is especially so with regard to the "deconstruction" of the
permissions system of Posix.[1]

On a Debian system (which I use) the solution used is that all
dialout devices have "group" ownership of "dialout". The users who
belong to that group can access these devices. No program accessing
these devices is "permitted" (by policy[2]) to play around with its
mode/ownership and so on.

Regards,

Kapil.

[1] The flaws of this system are well-known and many people have spent
hours designing "better" systems. However, any implementation of a
replacement of a "core" aspect like this is fraught with great
burdens: "legacy" software re-write/review and user education.

[2] This policy is currently one that governs the writers/packagers
of the programs rather than the programs themselves!

>
> The original problem was that "some" program was changing the permissions
> of the "dialout" device.
>
> Now, if devices are removed and created (a la devfs/udevd) by some
> automated process then that could be the reason for the changing
> permissions.
>
> Otherwise, it is some other program...

I recall having this kind of problem a number of years ago, but I'm
afraid that my recollection of the fix is rather dim. If I am
remembering correctly, I ended up using "setserial".

I have a strong suspicion that, in this case, "pppd" itself is the
culprit. Running "strace" on the "pppd" process (with "-f" and "-s 4096"
options) and tracing the execution to see if it does anything silly with
the device might be helpful.

> Unfortunately, it seems as if too many aspects of BL are
> "non-standard" for most of us to be able to help in debugging this.
> This is especially so with regard to the "deconstruction" of the
> permissions system of Posix.[1]

[nod] On a "normal" system, I'd set the device to "chattr +i" and see
what process croaked (or complained in the log files.) On the B.A.D.
gadget that Sindi is using, it's anybody's guess.

> On Tue, Mar 27, 2007 at 08:54:41AM -0700, Kapil Hari Paranjape wrote:
>>
>> The original problem was that "some" program was changing the permissions
>> of the "dialout" device.
>>
>> Now, if devices are removed and created (a la devfs/udevd) by some
>> automated process then that could be the reason for the changing
>> permissions.
>>
>> Otherwise, it is some other program...
>
> I recall having this kind of problem a number of years ago, but I'm
> afraid that my recollection of the fix is rather dim. If I am
> remembering correctly, I ended up using "setserial".
>
> I have a strong suspicion that, in this case, "pppd" itself is the
> culprit. Running "strace" on the "pppd" process (with "-f" and "-s 4096"
> options) and tracing the execution to see if it does anything silly with
> the device might be helpful.

ttyp0 also changed permissions after I rebooted on the other computer.
It is still okay here (as root root). It is needed by rxvt. Xvesa appears
to be staying suid root.

I will take a look at strace, with help from Karolis. pppd and rxvt.

>
>> Unfortunately, it seems as if too many aspects of BL are
>> "non-standard" for most of us to be able to help in debugging this.
>> This is especially so with regard to the "deconstruction" of the
>> permissions system of Posix.[1]
>
> [nod] On a "normal" system, I'd set the device to "chattr +i" and see
> what process croaked (or complained in the log files.) On the B.A.D.
> gadget that Sindi is using, it's anybody's guess.

>
> ttyp0 also changed permissions after I rebooted on the other computer.
> It is still okay here (as root root). It is needed by rxvt. Xvesa appears
> to be staying suid root.

"/dev/ttypX" files are pseudoterminal slave devices; their permissions,
etc. change all the time. No surprises there. I suggest you read up on
them in /usr/src/linux/Documentation/devices.txt (although I suspect
that you don't have the kernel sources installed - which would give the
constantly-repeated point that you're using a Broken-As-Designed distro
yet another turn at the sharpening bench.) Perhaps you can get a copy
from someone with a less-broken system; it's only about 100k, and
contains a huge amount of info about the files in /dev.
Also, do note that terminal emulators such as 'xterm' and 'rxvt' are
usually SUID root. At least one of the reasons for this (at least in my
opinion) is the ability to "adjust" device files despite possible
weirdness in ownership/permissions.

> On Tue, Mar 27, 2007 at 11:54:51PM +0000, sindi keesan wrote:
>>
>> ttyp0 also changed permissions after I rebooted on the other computer.
>> It is still okay here (as root root). It is needed by rxvt. Xvesa appears
>> to be staying suid root.
>
> "/dev/ttypX" files are pseudoterminal slave devices; their permissions,
> etc. change all the time. No surprises there. I suggest you read up on
> them in /usr/src/linux/Documentation/devices.txt (although I suspect
> that you don't have the kernel sources installed - which would give the
> constantly-repeated point that you're using a Broken-As-Designed distro
> yet another turn at the sharpening bench.) Perhaps you can get a copy
> from someone with a less-broken system; it's only about 100k, and
> contains a huge amount of info about the files in /dev.

I installed kernel source a long time ago and compiled lots of kernels,
some of them not broken ;=) I am using a custom 2.4.31 kernel. I also
have the Slackware 7.1 (and later) CDs.

> Also, do note that terminal emulators such as 'xterm' and 'rxvt' are
> usually SUID root. At least one of the reasons for this (at least in my
> opinion) is the ability to "adjust" device files despite possible
> weirdness in ownership/permissions.

rxvt is SUID root on this computer. Maybe I need to make it that on the
computer where user cannot use rxvt unless I keep resetting permissions.
(They are 40 min apart, by foot, and it is raining).

pppd is -rwsr-xr-- root users
Should it be -rws--x--x root root like rxvt?

I have the strace man page and have succeeded in disabling one vt by
filling the screen (probably with 4K of data, which started repeating
things about SEEK_SET and start and len and ioctl). I don't understand man
pages and will ask Karolis for help with strace.

> ttyp0 also changed permissions after I rebooted on the other computer.
> It is still okay here (as root root). It is needed by rxvt. Xvesa appears
> to be staying suid root.

Wait a minute. Did you say "/dev/ttyp0"? I must have missed that
somewhere.

The device "ttyp0" is the "slave" of the pair of "pseudo-tty"
devices (the master is "ptyp0"). These are dynamically assigned and
de-assigned by the kernel based on requests from processes---no wonder
that their ownerships and permissions are dynamic!

For example [1] do the following:

ssh -t localhost ls -l '$(tty)'

You get the output (with kapil replaced by your username):

crw--w---- 1 kapil tty 136, 13 2007-03-27 17:18 /dev/ttyp13

On the other hand:

ls -l /dev/ttyp13

Will give the output:

crw--w---- 1 root tty 136, 13 2007-03-27 17:18 /dev/ttyp13

Regards,

Kapil.
[1] I have cheated in the above example. Since my system is 2.6.x it
uses /dev/pts rather than /dev/[tp]typ* for the pseudo-terminals.
Moreover, since it uses "udev" the device disappears after I logout.
But the principle is the same.
--

> Hello,
>
> On Tue, 27 Mar 2007, sindi keesan wrote:
>> ttyp0 also changed permissions after I rebooted on the other computer.
>> It is still okay here (as root root). It is needed by rxvt. Xvesa appears
>> to be staying suid root.
>
> Wait a minute. Did you say "/dev/ttyp0"? I must have missed that
> somewhere.
>
> The device "ttyp0" is the "slave" of the pair of "pseudo-tty"
> devices (the master is "ptyp0"). These are dynamically assigned and
> de-assigned by the kernel based on requests from processes---no wonder
> that their ownerships and permissions are dynamic!

Yes, Ben explained that rxvt has to be run SUID to deal with the changing
permissions. I seem to have rxvt permissions correct on this computer but
not my other computer. Amazingly, things mostly still work on both.

> [1] I have cheated in the above example. Since my system is 2.6.x it
> uses /dev/pts rather than /dev/[tp]typ* for the pseudo-terminals.
> Moreover, since it uses "udev" the device disappears after I logout.
> But the principle is the same.

Actually "udev" is not the culprit in removing the device file. Since
2.6.x uses the "devpts" pseudo file-system, it is that file-system
which creates and removes the /dev/pts/* devices.

>
> The man page says +i prevents you from writing data to the file. I need
> to write to the device to use the modem or rxvt. The problem is that it
> is being reset so the user cannot write to it.

Right - so the initial step would be to "disable" it to see what
process complains. If it's "pppd" that's causing problems, then that's
what you'll see in the logs; if it's "rxvt", then that's what'll be
reported.

> i is immutable
> u is undeletable
>
> Sort of like write protection in DOS?

No - that would be "chmod -w <filename>".

> I doubt we have log files.

Then I can only wish you the best of luck in troubleshooting your
problems. I've never been good at running with both my feet tied in a
sack.

> On Wed, Mar 28, 2007 at 12:11:51AM +0000, sindi keesan wrote:
>>
>> The man page says +i prevents you from writing data to the file. I need
>> to write to the device to use the modem or rxvt. The problem is that it
>> is being reset so the user cannot write to it.
>
> Right - so the initial step would be to "disable" it to see what
> process complains. If it's "pppd" that's causing problems, then that's
> what you'll see in the logs; if it's "rxvt", then that's what'll be
> reported.
>
>> i is immutable
>> u is undeletable
>>
>> Sort of like write protection in DOS?
>
> No - that would be "chmod -w <filename>".

Write protected DOS files cannot be deleted or written to, and +i makes a
file unwriteable, so there is some overlap.

>> I doubt we have log files.
>
> Then I can only wish you the best of luck in troubleshooting your
> problems. I've never been good at running with both my feet tied in a
> sack.

We have a busybox syslogd - "system logging daemon (says Doctor Linux).
It accumulates log messages from various applications and stores them into
log files based on /etc/syslogd.conf" (which I would need to create to
specify where the log message go).q

The log is used to check for attempts at a breakin.

I have the man page but this is more than I can handle tonight unless you
want to walk me through the details.

>> I doubt we have log files.
>
> Then I can only wish you the best of luck in troubleshooting your
> problems. I've never been good at running with both my feet tied in a

'Strace eznet up 4' when run as user indicates that eznet run as user does
not have permission to access /var/eznet/eznet.conf or any other files in
/var/eznet (which are log files kept for five different sessions such as
ppp.0 pid.0 status.0 and sessions.html). But eznet is root suid so I
thought it had root permissions to access everything.

eznet.conf contains password so I don't want it to be user-readable.

Online eznet documentation does not help, nor can I understand the 130
pages of source code for eznet. Nobody else seems to have had problems
dialing as user with eznet.

-rws--s--x root root eznet

I can make it work by changing /dev/ttyS1 to user-writeable (every time
before logging in as user, or probably in an rc file).

The error message when I try to dial as user with eznet says I don't have
permission to access /dev/ttyS1 (or other modem device).

I put pppd back to non-suid and non-executable by user since eznet is what
runs it. I should not work on linux late at night.

Another approach would be to use pppd without eznet, but then the friends
I set up linux for would need to learn to use it too (or come back to me
whenever they changed user information).

Similar problems for both versions of Basiclinux.

I can dial as root and then do everything else as user. I think this is
how we were told to go online for added security. How exactly would
dialing as root compromise security? We have no open ports.

> On Tue, Mar 27, 2007 at 08:54:41AM -0700, Kapil Hari Paranjape wrote:
>>
>> The original problem was that "some" program was changing the permissions
>> of the "dialout" device.
>>
>> Now, if devices are removed and created (a la devfs/udevd) by some
>> automated process then that could be the reason for the changing
>> permissions.
>>
>> Otherwise, it is some other program...
>
> I recall having this kind of problem a number of years ago, but I'm
> afraid that my recollection of the fix is rather dim. If I am
> remembering correctly, I ended up using "setserial".
>
> I have a strong suspicion that, in this case, "pppd" itself is the
> culprit. Running "strace" on the "pppd" process (with "-f" and "-s 4096"
> options) and tracing the execution to see if it does anything silly with
> the device might be helpful.
> --
> * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *
>

Here is the output from running strace as user for eznet, which runs pppd
(which is in /usr/sbin, not accessible to user). eznet up 4 dials (for
root) but for user says permission denied for /dev/ttyLT0 or ttyS1.

> I read a short section on security in an old SuSE book, which says to
> avoid SUID programs because they are succeptible to buffer overruns which
> is bad for security.

You've either misunderstood it, or it was poorly written. The real story
is that if you

a) have an SUID program

AND

b) it's susceptible to a buffer overrun - note that these two things are
distinct and independent -

then attackers can crack into your system by attacking that program.

> 1. Anything svgalib needs to be suid to run as 'user':
> links2, zgv, seejpeg, bmv.
>
> Are these security risks?

Probably not in your usage scenario; all of the above are
local-execution programs (although 'links2', depending on how it deals
with CGI, may be - but that's a different attack vector.)

> 2. Xvesa needs to be SUID to be loaded by 'user'. Is it better to start
> X as root then login as 'user'? (rxvt and xterm did not need to be suid).

As I recall, Xvesa is just an X binary; it shouldn't need root
privileges (I recall when X did need them; I also recall the flamewars
that this caused.) instead, it should check '/etc/X11/Xsession.options'
and '/etc/X11/Xwrapper.config' for the appropriate options (e.g.,
"allowed_users=console", "allow-user-resources", etc.) and run based on
those. Take a look at a normal system, and check out the interaction
between 'startx', 'xinit', and the X program.

> 3. eznet has to be SUID to access pppd (which is not on the path for
> 'user') and eznet.conf (with login and password, not readable by user)
> and/or pap-secrets. Would it be more secure to dial as root and then
> login as user? pppd is not suid, or even on the path for user, and is
> accessed by eznet.

It would be more secure to configure 'pppd' as I described, then use it
as a non-root user.

> If I dial as root but do not run any internet-related programs as root is
> there still a security risk?

Yes. Aside from the obvious - i.e., what everyone's been telling you -
see my first paragraph.

> 4. In the larger linux (not being given to friends) I installed bin.tgz
> with at and crontab (I never use them) and also lpr.tgz (print spooler)
> with lpr lprm and lqp, which I no longer use. All these files are SUID.
> Are they security risks?

Yes. Besides being vulnerable to local exploits, 'lpd' is a daemon that
can be attacked remotely.

Just lost my connection after typing out a very long reply to this ;=(

On Wed, 7 Mar 2007, Ben Okopnik wrote:

> On Sun, Mar 04, 2007 at 03:25:54AM -0500, Sindi Keesan wrote:
>> I read a short section on security in an old SuSE book, which says to
>> avoid SUID programs because they are succeptible to buffer overruns which
>> is bad for security.
>
> You've either misunderstood it, or it was poorly written. The real story
> is that if you
>
> a) have an SUID program
>
> AND
>
> b) it's susceptible to a buffer overrun - note that these two things are
> distinct and independent -
>
> then attackers can crack into your system by attacking that program.

I got a lot of hits on Opera and buffer overrun.

>
>> 1. Anything svgalib needs to be suid to run as 'user':
>> links2, zgv, seejpeg, bmv.
>>
>> Are these security risks?
>
> Probably not in your usage scenario; all of the above are
> local-execution programs (although 'links2', depending on how it deals
> with CGI, may be - but that's a different attack vector.)

>
>> 2. Xvesa needs to be SUID to be loaded by 'user'. Is it better to start
>> X as root then login as 'user'? (rxvt and xterm did not need to be suid).
>
> As I recall, Xvesa is just an X binary; it shouldn't need root
> privileges (I recall when X did need them; I also recall the flamewars
> that this caused.) instead, it should check '/etc/X11/Xsession.options'
> and '/etc/X11/Xwrapper.config' for the appropriate options (e.g.,
> "allowed_users=console", "allow-user-resources", etc.) and run based on
> those. Take a look at a normal system, and check out the interaction
> between 'startx', 'xinit', and the X program.

All TinyX servers need to be run SUID to work for user, unlike the regular
servers which will work with xdm or Xwrapper (which I read about and cited
info on in my attempted previous reply). Xwrapper is set suid and
needs only that one Xwrapper.config with that one line. The options file
is for running other things automatically at login time, I think.
xdm is for logging into the GUI which I don't want to do.

startx, Xwrapper (both in xbin.tgz) and Xwrapper.config are all tiny
files. They worked perfectly for root and user, except that I don't have
the proper X server for my newer Matrox video card, which works fine with
TinyX Xvesa and xfbdev (except in 8-bit color). I don't know how to
compile the mga server for XFree86-3.3.6. I am told X is hard to compile.

I don't have any other PCI video cards this good which work with
framebuffer. AGP cards conflict with MGA in this dual-head system (which
TAG helped me set up).

The X framebuffer standard server wants font 'fixed' (which we apparently
do not have). SVGA and S3 servers do not need it. Maybe I can put
something in the config file to work around this. I will ask at my list.

There is a TinyX matrox server but TinyX servers need to be set SUID.

>> 3. eznet has to be SUID to access pppd (which is not on the path for
>> 'user') and eznet.conf (with login and password, not readable by user)
>> and/or pap-secrets. Would it be more secure to dial as root and then
>> login as user? pppd is not suid, or even on the path for user, and is
>> accessed by eznet.
>
> It would be more secure to configure 'pppd' as I described, then use it
> as a non-root user.

I will leave this alone for a while. I could not find anything online
about eznet and security. The files with login and password are not
user-readable. eznet is just a way to set up and access pppd and related
files. Several small distributions use it.

>> If I dial as root but do not run any internet-related programs as root is
>> there still a security risk?
>
> Yes. Aside from the obvious - i.e., what everyone's been telling you -
> see my first paragraph.

That appears to be about SUID. Are you referring to running zgv after
dialing as root?

>> 4. In the larger linux (not being given to friends) I installed bin.tgz
>> with at and crontab (I never use them) and also lpr.tgz (print spooler)
>> with lpr lprm and lqp, which I no longer use. All these files are SUID.
>> Are they security risks?
>
> Yes. Besides being vulnerable to local exploits, 'lpd' is a daemon that
> can be attacked remotely.

> All TinyX servers need to be run SUID to work for user, unlike the regular
> servers which will work with xdm or Xwrapper (which I read about and cited
> info on in my attempted previous reply). Xwrapper is set suid and
> needs only that one Xwrapper.config with that one line. The options file
> is for running other things automatically at login time, I think.

Really? Nope. XWrapper simply sets the nice value (somewhat redundant
on 2.6.X kernels where the scheduler has been rewritten anyway) and sets
permissions as to which users can launch it.

> xdm is for logging into the GUI which I don't want to do.

You mean you don't want a graphical login manager. That's fine.

> I am told X is hard to compile.

It's not difficult -- just time consuming.

> I don't have any other PCI video cards this good which work with
> framebuffer. AGP cards conflict with MGA in this dual-head system (which
> TAG helped me set up).

Under TinyX you're going to be severly disadvangted with anything like
that anyway.

> The X framebuffer standard server wants font 'fixed' (which we apparently
> do not have). SVGA and S3 servers do not need it. Maybe I can put
> something in the config file to work around this. I will ask at my list.

No, X11 wants font fixed which it defaults to as the de facto font for
just about anything. No font fixed, no worky.

[...]

-- Thomas Adam

--
"Wanting to feel; to know what is real. Living is a lie." -- Purpoise
Song, by The Monkees.

> On Wed, Mar 07, 2007 at 03:26:00PM -0500, Sindi Keesan wrote:
>> All TinyX servers need to be run SUID to work for user, unlike the regular
>> servers which will work with xdm or Xwrapper (which I read about and cited
>> info on in my attempted previous reply). Xwrapper is set suid and
>> needs only that one Xwrapper.config with that one line. The options file
>> is for running other things automatically at login time, I think.
>
> Really? Nope. XWrapper simply sets the nice value (somewhat redundant
> on 2.6.X kernels where the scheduler has been rewritten anyway) and sets
> permissions as to which users can launch it.

My original reply (longer) said I don't need any options file for
Xwrapper, that was probably for something else. I got Xwrapper working
with just allowed_users=console.

>> I am told X is hard to compile.
>
> It's not difficult -- just time consuming.

Some day.

>
>> I don't have any other PCI video cards this good which work with
>> framebuffer. AGP cards conflict with MGA in this dual-head system (which
>> TAG helped me set up).
>
> Under TinyX you're going to be severly disadvangted with anything like
> that anyway.

Xvesa works fine with this dual-head setup. It is newer than the other
X drivers (from Slackware 7.1, year 2000).

>> The X framebuffer standard server wants font 'fixed' (which we apparently
>> do not have). SVGA and S3 servers do not need it. Maybe I can put
>> something in the config file to work around this. I will ask at my list.
>
> No, X11 wants font fixed which it defaults to as the de facto font for
> just about anything. No font fixed, no worky.

The SVGA and S3 servers work with the same font directories.

failed to set default font path .... could not open default font 'fixed'.

I probably need to do something to XF86Config, which is still set to a
monitor that died last year. I avoid X when possible. I will start over
with xf86config.

> failed to set default font path .... could not open default font 'fixed'.

Just so we're clear:

No font 'fixed'; no worky.

Or put another way:

If X cannot find font fixed (or font 'cursor' which it uses for a cursor
font, oddly enough, but that's a slightly separate issue) it won't
start. This is invariably due to a poorly setup X11 installation (such
as half of it missing) or your FontPaths are screwed.

Given I've written about this before for LG, I am not repeating it here.

> On Wed, Mar 07, 2007 at 04:18:34PM -0500, Sindi Keesan wrote:
>> failed to set default font path .... could not open default font 'fixed'.
>
> Just so we're clear:
>
> No font 'fixed'; no worky.
>
> Or put another way:
>
> If X cannot find font fixed (or font 'cursor' which it uses for a cursor
> font, oddly enough, but that's a slightly separate issue) it won't
> start. This is invariably due to a poorly setup X11 installation (such
> as half of it missing) or your FontPaths are screwed.

The same setup works on this computer with the SVGA server with no
complaint about font paths. It was scrambling things before but looks
perfect now. I think I only changed the monitor and card names and video
RAM amount in XF86Config (a generic one for our linux, to which I added
modelines above 800x600). I am getting some odd video effects switching
between user and root. A few times I had to logout and login or the
console prompt kept moving to the right. Bugs? Flakey hardware?

I also have a new XF86Config made with xf86config (it does not list Xvfb
as an accelerated server and I made my own symlink). It still 'failed to
set default font path' with the Xvfb driver, looking first for
/usr/X11R6/lib/X11/fonts/misc. This new XF86Config does not work beyond
320x200 with SVGA driver. Or at all with Xvfb.

I have font directories misc (with fixed fonts), 100dpi and 75dpi (and
PEX). XF86Config has fontpaths misc (first) 75dpi 100dpi Type1.
All in the right places. This server is not finding them (as root).

misc/fonts.alias has aliases for -misc-fixed and -sony-fixed and
jis-fixed pointed at the fonts which are in misc.

xset q lists font paths when run with the SVGA server.

Started without xinit/startx, Xvfb just says Fatal error no screens found.
S3 and Tseng servers can't find their devices, understandably. Tseng told
me I have a Matrox.

It will take me a while to understand all of that, and figure out why it
is not finding the font paths. misc is in the default location.

Xvesa comes with built-in fonts.
It won't work with startx and Xwrapper unless it is SUID root (I checked).

man Xvfb says it was written to run on machines without display hardware.
Other people seem to be using it to actually view things.
No longer needed, assuming SVGA keeps working. I don't need the fancy
features of the mga server for opera or xpdf.

> If you look back in the LG archives, you'll also see mention of another
> font article I wrote a few years ago which says much the same thing as
> the one cited above, it's just tangential.

>> I probably need to do something to XF86Config, which is still set to a
>> monitor that died last year. I avoid X when possible. I will start over
>> with xf86config.
>
> See above. Nothing to do with your monitor.

The monitor part was just a tipoff that it was an old config.
The old config is now working properly with new monitor and card names.

I have fixed the rxvt problem by reading about pseudoterminals at tldp
site. Pseudoterminals are pty/tty pairs. I was changing permissions on
ttyp* because someone on our list I think pointed me to those. ttyS* has
to be o+w to work for user to dial.

chmod 666 ptyp* and ttyp*

Or chmod o+w

Is it okay to have all these pairs user-accessible?

The 'screen' program no longer complains about not finding any PTTYs.
(I forgot how to exit it though).

I went down a wrong trail after reading that Nvidia framebuffer can
disable pseudoterminals. Mine messes up the screen colors badly.

rxvt in the smaller Basiclinux 3.40 probably works because the device
permissions were set properly. I was looking at the wrong devices.

New problem now. As user:
''
splitvt: Can't initialize screen: Terminal type must be set to VT100.
''
More to learn. Slackware would not be as much fun.

On or around Thursday 01 March 2007 19:16, Thomas Adam reorganised a bunch of
electrons to form the message:

> On Thu, Mar 01, 2007 at 09:09:45PM +0200, Karolis Lyvens wrote:

> I would be wary of exporting that, since most apps will simply barf on
> it. Set it to the duration of a process instead:
>
> ```
> TERM=VT100 splitvt

That's bash syntax. I'm not sure if the querent is using bash. I suspect
busybox is probably providing a limited shell environment. If it fails she
will need to check how environment variables are set in that environment.

> On or around Thursday 01 March 2007 19:16, Thomas Adam reorganised a bunch of
> electrons to form the message:
>> On Thu, Mar 01, 2007 at 09:09:45PM +0200, Karolis Lyvens wrote:
>
>> I would be wary of exporting that, since most apps will simply barf on
>> it. Set it to the duration of a process instead:
>>
>> ```
>> TERM=VT100 splitvt

User is using sh linked to bash, I think.
Root can't even do the above.
Can't find termcap entry for terminal type "(null)".

I did not get a mail from Karolis, who I think has Basiclinux 3.40 not
2.10. 3.40 uses busybox sh.

> Hello,
>
> A suggestion:
> I understand that you want to create a minimal distribution.
> There is no reason for you to use a minimal distribution while
> designing one. Having a full-fledged working distribution may give
> you a better idea of what you want to leave in in the minimal one.
> Moreover, on a full-fledged distribution you can read man pages, run
> strace/ltrace and possibly even run the debugger. You can test the
> mini-distribution in a user-mode-linux or a qemu or some other
> virtualised sub-box if you don't feel like booting all the time.

For a while I had Slackware in another partition on one drive (that died).
I use at most 1GB for my linux, so no lack of space on a 3GB drive.
If I use kernel 2.4.31 in Basiclinux and have modules for it in both
partitions, I can mount the other partition and chroot to it. I have man
pages on CD. But I can't usually understand them. I now have a shell
account at a Slackware 10.02 machine with broadband connection.

I added strace but the output is hard to understand. I am starting to
learn vi and don't need tex or emacs. I set up linux for friends in 35MB
just for internet.

> I think you can have a full-fledged development box with about 4MB
> of RAM providing you don't use X and are willing to wait a while for
> compiles. I recall building linux (ver 1.x), libc, basic utilities,
> vi, emacs and tex on a 386 which had 4MB of RAM and 500MB of disk. It
> took a while but it worked.

A strange problem. I dial as user and it works, then next time I don't
have permission to use /dev/ttyS1. This has happened repeatedly. I
change to o+rw and it changes itself back. I changed all tty* to o+rw and
today I have again:

ttyS1 crw-r--r--
ttyp0 crw-------
ttyp1 crw--w--w-

They are all different, even stranger. They used to be all other rw.
The other tty's (which I did not use as user) are unchanged (rw).

I could set rc.S or something to redo the permissions on these
three files each time I boot, but what could be causing this?

The author of svgalib helped me to make the module which lets me now use
zgv and links2 non-suid. Kernel 2.4 was missing two files which were
non-essential so we commented them out.

>> Besides running Opera (and maybe dialing and/or loading Xvesa and
>> rxvt) as user should I take any other precautions on their computers?
>
> I don't know how many times I'm willing to say "Your design is
> fundamentally bad, if only because it uses root logins by default."
> This is probably the last time, as obviously I'm wasting my time.
> I stated, for that reason, that I was uninterested in helping users
> unwilling to do that basic step correctly -- and I meant what I said.

We had a long discussion about why it is bad to go online as root, which
is how Basiclinux is set up to operate.

My current compromise is to:

1. Dial as root (because dialing as user would give the user access to
the login name and password, which would then let anyone with access to
the user account know these, and besides if I try to dial as user pppd
complains about not having /etc/ppp/options, which root does not need).

2. Copy over all the files from /root to /home/user with cp -a * and also
cp -a .*, except that Opera has subdirectories so just start over again
setting parameters for user. Also chown user * and chown user .* and
make /dev/null writable by user.

3. Put into /home/user/profile the line startx (rather than editing
inittab to make vt1 run X, which does not work any more anyway once you
add a user account).

4. Login user, which starts X (and you can exit X if desired).
Or su user and don't start X.

5. Run Opera or other programs from the wm menu as user (having made them
all executable by user or chmod +s).

I will solve the problem of files needed by user but not root for ssh
eventually. The paths are different for user and root (user has no /sbin
or /usr/sbin). So pppd is not on the path for user (/usr/sbin) Probably
because user is not supposed to dial. But ssh is on the path. I will try
to find instructions for our ssh. I may need /home/user/.ssh/config or
/etc/ssh/ssh_config

I have set up a computer for a friend to use without ssh, as above.

Thanks to all of you for the help.

I ran across an article by Rick on using multiple monitors with X.
TAG once helped me use two monitors without X (MGA and VGA cards).

> On Mon, 29 Jan 2007, Rick Moen wrote:
> >> Besides running Opera (and maybe dialing and/or loading Xvesa and
> >> rxvt) as user should I take any other precautions on their computers?
> >
> > I don't know how many times I'm willing to say "Your design is
> > fundamentally bad, if only because it uses root logins by default."
> > This is probably the last time, as obviously I'm wasting my time.
> > I stated, for that reason, that I was uninterested in helping users
> > unwilling to do that basic step correctly -- and I meant what I said.
>
>
> We had a long discussion about why it is bad to go online as root, which
> is how Basiclinux is set up to operate.
>
> My current compromise is to:
>
> 1. Dial as root (because dialing as user would give the user access to
> the login name and password, which would then let anyone with access to
> the user account know these, and besides if I try to dial as user pppd
> complains about not having /etc/ppp/options, which root does not need).

Just to correct a misconception on your part: the information in
/etc/ppp/*-secrets does not have to be readable by the user; this is why
'/usr/sbin/pppd' is set SUID 0. In fact, that's the default
configuration on every Linux system I've seen, including the one I've
just set up on my new laptop:

The above means that any user who is part of group 'dip' can execute
'pppd' - and since 'pppd' runs as root, it can read the files that
contain the name and the password.

In other words, it appears as though you're taking a mechanism that
works just fine and changing it so that it will do the same thing as
it's doing now. I suggest that understanding the current mechanism would
serve you better than trying to construct something new from the ground
up - especially since it's not new.

> 3. Put into /home/user/profile the line startx (rather than editing
> inittab to make vt1 run X, which does not work any more anyway once you
> add a user account).

This means, of course, that you'll be trying to start X every time you
log in. Perhaps making it conditional would work better.

>>
>> We had a long discussion about why it is bad to go online as root, which
>> is how Basiclinux is set up to operate.
>>
>> My current compromise is to:
>>
>> 1. Dial as root (because dialing as user would give the user access to
>> the login name and password, which would then let anyone with access to
>> the user account know these, and besides if I try to dial as user pppd
>> complains about not having /etc/ppp/options, which root does not need).
>
> Just to correct a misconception on your part: the information in
> /etc/ppp/*-secrets does not have to be readable by the user; this is why
> '/usr/sbin/pppd' is set SUID 0. In fact, that's the default
> configuration on every Linux system I've seen, including the one I've
> just set up on my new laptop:

We don't HAVE a /usr/sbin/pppd. We use eznet to dial with (it tells pppd
what to do) and it uses /var/eznet/eznet.conf which contains login info.

When I try to dial as user, pppd wants /etc/ppp/options (which we also do
not have). When I dial as root that is not needed.

This linux came with one 'user' login who lives in /home/user and uses
/bin/sh. Root uses /bin/bash (according to /etc/passwd). I had to make
/home/user owned by user (chown -R user user chgrp -R users user) before I
could save anything to it. As I said, this is a single-user distribution.

I compiled a new busybox which has adduser and addgroup (my linux had
neither). I have used adduser once.

addgroup users tells me it is already in use.

Next problem is that we are dialing with eznet not directly with pppd.

My pap-secrets is also not world-readable and it contains the same login
and password info as eznet.conf. I don't know where eznet looks for
info.

I think you are saying if I set pppd SUID, then the user can use pppd,
which can read the login and password info from pap-secrets, but the user
cannot do that directly, so it is safe. But I don't know how to dial with
pppd directly, just via eznet.

I will set eznet like pppd.

It is currently -rwsr-sr-x root root - probably should not be executable
by user. chgrp users eznet chmod u+s eznet
Now -rwsr-xr-- root users

eznet.conf is -rw------- readable by root like pap-secrets.

An attempt to dial as user STILL wants /etc/ppp/options.

(I hope I can still dial as root after all this.)

Does the following help any:

I can type 'eznet up 4' to get the fourth login and password etc. (set up
to use the lucent modem) listed in eznet.conf. ps lists as a process:

(LT0 is a lucent modem for which I somehow managed to compile the
modules. It does not keep disconnecting due to line noise like the
external 1997 USR that I updated from X2 to v90. crw-r--r-- root root).

> In other words, it appears as though you're taking a mechanism that
> works just fine and changing it so that it will do the same thing as
> it's doing now. I suggest that understanding the current mechanism would
> serve you better than trying to construct something new from the ground
> up - especially since it's not new.

I don't have the standard setup to start with.

>> 3. Put into /home/user/profile the line startx (rather than editing
>> inittab to make vt1 run X, which does not work any more anyway once you
>> add a user account).
>
> This means, of course, that you'll be trying to start X every time you
> log in. Perhaps making it conditional would work better.

This is only for other people who only want to use opera in linux. I want
to save them a step. But this stopped working.

To use X as user I needed to make Xvesa and rxvt o+x (or it would complain
about permissions) and also suid root (Xvesa told me so).

> In that case, either recompiling 'ssh' to look for 'ssh_askpass' in a
> different place, or creating the above path and a link to the
> actual location of 'ssh_askpass' should help.

I don't know how to compile ssh. Our distribution author did it
(statically against uclibc). A few of our users know how to compile and
one of them is in TAG. He will try to compile uclibc-static latest
openssh, and maybe can explain how to use ssh as user in our distribution.
We don't have a default config file for ssh either.

I don't have an ssh_askpass any more than I do /etc/ppp/options. I don't
even have an /opt - that is for some other distribution, I think.
It works for root without either of those. Might this be related to user
using /bin/sh and root using /bin/bash? Root has a .bashrc which user
may not be accessing but it only sets the prompt and a few aliases.
I am lost here.

Is ssh not secure enough to use as root? I no longer telnet.

I just compiled putty's psftp and pscp for secure file transfers instead
of kermit ftp or busybox ftpput and ftpget.

> On Mon, 26 Feb 2007, Ben Okopnik wrote:
> >>
> >> We had a long discussion about why it is bad to go online as root, which
> >> is how Basiclinux is set up to operate.
> >>
> >> My current compromise is to:
> >>
> >> 1. Dial as root (because dialing as user would give the user access to
> >> the login name and password, which would then let anyone with access to
> >> the user account know these, and besides if I try to dial as user pppd
> >> complains about not having /etc/ppp/options, which root does not need).
> >
> > Just to correct a misconception on your part: the information in
> > /etc/ppp/*-secrets does not have to be readable by the user; this is why
> > '/usr/sbin/pppd' is set SUID 0. In fact, that's the default
> > configuration on every Linux system I've seen, including the one I've
> > just set up on my new laptop:
>
> We don't HAVE a /usr/sbin/pppd.

The fact that you've emphasized this implies that you find it
meaningful, but I'm at a loss as to why. You clearly have a 'pppd'
somewhere; this means that you can follow the same method as everyone
else who uses 'pppd' - i.e., make the executable SUID 0 and executable
by some group, then make those users who should be able to dial out part
of that group. Where's the problem?

> We use eznet to dial with (it tells pppd
> what to do) and it uses /var/eznet/eznet.conf which contains login info.
>
> When I try to dial as user, pppd wants /etc/ppp/options (which we also do
> not have).

Honestly, this is getting rather silly. If your software complains about
not having some file - particularly if that file doesn't need to have
anything special in it and doesn't require a large amount of space -
then why not create it, perhaps by copying it from a working system? In
the case of '/etc/ppp/options', on my system, it's just a tiny text file
that contains about 100 bytes of non-comment text:

Well, Sindi... if you don't explicitly mention that you need help with
permissions/ownership, then you're not likely to get it. Reading the
relevant manpages would have helped, and in significantly less than 10
minutes (and please don't tell me that you don't have them on your
system; at this point, searching google for "man chmod" brings up the
'chmod' manpage as the first hit.)

chown root.pppd pppd
chmod 4754 pppd

> This linux came with one 'user' login who lives in /home/user and uses
> /bin/sh. Root uses /bin/bash (according to /etc/passwd). I had to make
> /home/user owned by user (chown -R user user chgrp -R users user) before I
> could save anything to it. As I said, this is a single-user distribution.

Clearly a very badly-configured one. A home directory where you can't
save anything as that user? That's pretty bad.

> I compiled a new busybox which has adduser and addgroup (my linux had
> neither). I have used adduser once.

Perhaps you should use 'useradd' instead. 'adduser', etc., are front
ends to that whole toolkit.

> addgroup users tells me it is already in use.

The simplest way to add an existing user to an existing group is by
editing '/etc/group'. The safe and simple way to do it is by using
'vigr'.

> Next problem is that we are dialing with eznet not directly with pppd.
>
> My pap-secrets is also not world-readable and it contains the same login
> and password info as eznet.conf. I don't know where eznet looks for
> info.

I'm not familiar with 'eznet' - I've never used it. Anytime I need to
connect by dialing - and I do this every day with my Aircard - I just
use 'pppd' directly (e.g., 'pppd call aircard' for the 'aircard'
configuration.) I do this as a non-root user, and haven't had any
problems related to the functioning of 'pppd' itself.

> I think you are saying if I set pppd SUID, then the user can use pppd,
> which can read the login and password info from pap-secrets, but the user
> cannot do that directly, so it is safe. But I don't know how to dial with
> pppd directly, just via eznet.

Based on what you've said (i.e., that eznet is a front end to pppd),
'pppd' is already configured for you - the only thing you need to do is
find out what the name of the configuration files is. Fortunately,
that's pretty easy: take a look at '/etc/ppp/peers' - this contains all
your "dialup configurations". If these don't contain root-only options
such as 'noauth' (and there's rarely any reason for having such
options), then a non-root user can just enter

pppd call foo

where 'foo' is the name of the config file from '/etc/ppp/peers', to
dial.
'

> Does the following help any:
>
> I can type 'eznet up 4' to get the fourth login and password etc. (set up
> to use the lucent modem) listed in eznet.conf. ps lists as a process:
>
> /usr/sbin/pppd /dev/ttyLT0 115200 connect /usr/bin/eznet chat 4
> defaultroute lock modem mtu 552 mru 5 (goes off the screen).

If you use the 'w' option to 'ps', it'll wrap the line.

> > In other words, it appears as though you're taking a mechanism that
> > works just fine and changing it so that it will do the same thing as
> > it's doing now. I suggest that understanding the current mechanism would
> > serve you better than trying to construct something new from the ground
> > up - especially since it's not new.
>
> I don't have the standard setup to start with.

Then whoever set up the distro broke that standard setup for no reason.
In fact, that sounds like the core of all your problems - pretty much
everything you've asked here in this regard has been a standard
"question" in Unix that got answered a long time ago by either designing
a better system or defining a specific method for dealing with the
problem. In addition, all these things have been refined and "tuned"
over time to eliminate or avoid security problems, problematic edge
cases, etc. Now, it sounds like whoever put this distro together has
recreated these ancient problems - and you're stuck trying to solve
them. The only question, given the plethora of other, well-working
distros out there is "why"?

If you were doing this because you wanted to learn how to solve
low-level Linux problems, perhaps this would be a good approach.
However, you keep mentioning having to accomodate users; this is like
trying to design a brand-new type of chainsaw and handing it out to
random people to use while it's still in the prototype stage. The
results that you're getting are - well, exactly what could be expected
of such actions.

> > In that case, either recompiling 'ssh' to look for 'ssh_askpass' in a
> > different place, or creating the above path and a link to the
> > actual location of 'ssh_askpass' should help.
>
> I don't know how to compile ssh.

Then create the path, as I've mentioned.

> This reply took a couple of hours. I am learning a lot. Thanks.

I'm glad that you're finding this helpful, but you're working with a
broken system and learning many lessons that are going to be useless in
normal scenarios (along with some that will be useful.) I would
seriously suggest exploring other distros.

Quite all right; I'm running pretty short of sleep myself, so I know
what it's like.

> We do have
> /usr/sbin/pppd but when I dial as user it wants /etc/ppp/options, which is
> what we do not have.
>
> >Honestly, this is getting rather silly. If your software complains about
> >not having some file - particularly if that file doesn't need to have
> >anything special in it and doesn't require a large amount of space -
> >then why not create it, perhaps by copying it from a working system? In
> >the case of '/etc/ppp/options', on my system, it's just a tiny text file
> >that contains about 100 bytes of non-comment text:
> >
> >``
> >ben at Tyr:~$ grep '^[^#]' /etc/ppp/options
> >asyncmap 0
> >auth
> >crtscts
> >lock
> >hide-password
> >modem
> >proxyarp
> >lcp-echo-interval 30
> >lcp-echo-failure 4
> >noipx
> >''
>
> I copied this to /etc/ppp/options (without the`` '')
> -rw-r--r-- root root /etc/ppp/options - is this correct?

Yes.

> Now when I try to dial (never mind that I am already dialed as root):
>
> The remote system (x0) is required to authenticate itself but I couldn't
> find any suitable secret (password) for it to use to do so.

Right - this means that you don't have a password defined for that
system. For your reference, here's the standard method of setting up a
PPP connection (there are plenty of setup scripts that can make this
easier, but you clearly want to know how to do it manually) is as
follows:

1) Pick a name for the connection (e.g., 'my_isp'.)

2) Create /etc/chatscripts/my_isp, typically by copying one of the
default scripts (e.g., /etc/chatscripts/provider); these define the
host negotiations for dial-up connections. A common chatscript might
look like this:

3) Create '/etc/ppp/peers/my_isp' - usually by copying something like
'/etc/ppp/peers/provider' and setting the 'user' and 'connect'
parameters as well as the modem interface and connection speed. A
common peer config might look like this:

# Replace with actual name/domain.
user "myusername at domain"
# Replace ****** with phone number.
connect "/usr/sbin/chat -v -f /etc/chatscripts/pap -T ********"
# Serial device to which the modem is connected.
/dev/modem
# Speed of the serial line.
115200
# Assumes that your IP address is allocated dynamically by the ISP.
noipdefault
# Try to get the name server addresses from the ISP.
usepeerdns
# Use this connection as the default route.
defaultroute
# Makes pppd "dial again" when the connection is lost.
persist
# Do not ask the remote to authenticate.
noauth

4) Enter the password into '/etc/ppp/pap-secrets' (this requires root
access, since the file is not even readable otherwise.) The format is

* password

unless you want to dial several ISPs with different passwords, in which
case the '*' is replaced with the actual hostname.

> I read Running Linux 2nd edition. I also have 'Linux Man' old version but
> man pages use a lot of unfamiliar vocabulary. It would have gone faster
> if I had been more awake (and I may have been exaggerating just a bit
> about 10 min).
>
> >``
> >chown root.pppd pppd
> >chmod 4754 pppd
> >''
>
> It is easier for me to remember o+x than the numbers.

[shrug] In some cases, it's a lot more difficult to do it with the
relative permission settings; the absolute ones (the numbers) let you do
it all in one shot.

> >>This linux came with one 'user' login who lives in /home/user and uses
> >>/bin/sh. Root uses /bin/bash (according to /etc/passwd). I had to make
> >>/home/user owned by user (chown -R user user chgrp -R users user) before I
> >>could save anything to it. As I said, this is a single-user distribution.
> >
> >Clearly a very badly-configured one. A home directory where you can't
> >save anything as that user? That's pretty bad.
>
> It was designed to use as root. The author says we are on our own if we
> want to use it as user.

Yep. That's BAD (Broken As Designed.)

> >Then whoever set up the distro broke that standard setup for no reason.
>
> To make it small enough to fit on 2 floppy disks, including X, a browser,
> a viewer, a window manager, a dialing program, a mail program and a lot of
> utilities. The first disk can be used alone for rescue.

There are at least a few that meet those requirements, as I understand
it.

> >I'm glad that you're finding this helpful, but you're working with a
> >broken system and learning many lessons that are going to be useless in
> >normal scenarios (along with some that will be useful.) I would
> >seriously suggest exploring other distros.
>
> I tried installing a few and uninstalled them again. I did not like
> Redhat, Caldera (horrible on older hardware), Debian (does too much
> automatically). SuSE was okay, but I prefer Slackware and this is a small
> version of it that I can add to as needed. The default small installation
> of SW10.2 used up 64MB immediately running daemons I did not ask for. It
> would be a lot of work to strip Slackware. We are putting linux on
> computers with 32MB RAM.

Again, I'd suggest looking at the above list (among many others on the
Net); a number of those distros are designed for exactly the purpose
you've described. The ones you've just mentioned are all "full-sized"
distros, and not suitable for the hardware you've mentioned.

To dial I needed to chmod +s eznet, which lets eznet use pppd, which is
not on the path for user and does not need to be suid or executable by
user. So I am dialed as user on all three computers now.

rxvt works for user in Basiclinux 3.40, where it is compiled not to need
libXPM or lib-ldlinux just libX11 and libc.so.5

In BL2.1 (libc6) it cannot open pseudo-tty. rxvt -h lists XPM and utmp.
I read something about pseudoterminals and registering users in
/var/log/utmp (which of course we do not have). Perhaps if compiled
without the utmp stuff it would work without a utmp file in BL2.1.

I have switched to xterm, which needs a long list of libraries but not
XPM.

My remaining problem is that ssh is working on one computer (with a
standard hardware modem) but not on the two with internal lucent modems
(where pppd for some reason is accessing ttyS1 and also ttyLT0).

> In BL2.1 (libc6) it cannot open pseudo-tty. rxvt -h lists XPM and utmp.
> I read something about pseudoterminals and registering users in
> /var/log/utmp (which of course we do not have). Perhaps if compiled
> without the utmp stuff it would work without a utmp file in BL2.1.

The "-ut" switch to rxvt or a suitable entry in the application
defaults file for rxvt may help you. The man page says.

> I am happy dialing as user and ssh'ing as root, and my friends are
> unlikely to ssh at all, but I would like to understand what is going on
> with ssh. This continues to be educational.

I don't understand your setup and the places where files are to be
found but in case this is useful here is a (very) simplified version
of the steps that are performed by SSH:

1. Client establishes TCP connection to server.

2. Server sends a its "Host Key".

3. Client checks the "Host Key" against its "Known Hosts" or prompts the user for acceptance of the "unknown Host Key" if "StrictHostKeyChecking=no".
4. If the Client accepts this then it proceeds to authenticate itself.

> Someone did once send out a generic mail to previous question-askers
> asking for more questions. This might be more than you asked for.

A suggestion:
I understand that you want to create a minimal distribution.
There is no reason for you to use a minimal distribution while
designing one. Having a full-fledged working distribution may give
you a better idea of what you want to leave in in the minimal one.
Moreover, on a full-fledged distribution you can read man pages, run
strace/ltrace and possibly even run the debugger. You can test the
mini-distribution in a user-mode-linux or a qemu or some other
virtualised sub-box if you don't feel like booting all the time.

I think you can have a full-fledged development box with about 4MB
of RAM providing you don't use X and are willing to wait a while for
compiles. I recall building linux (ver 1.x), libc, basic utilities,
vi, emacs and tex on a 386 which had 4MB of RAM and 500MB of disk. It
took a while but it worked.

>
> My remaining problem is that ssh is working on one computer (with a
> standard hardware modem) but not on the two with internal lucent modems
> (where pppd for some reason is accessing ttyS1 and also ttyLT0).

SSH is an application; it doesn't (can't) care about the kind of
hardware you use for networking.

> Host key verification failed if I ssh without the login.

Quick guide to SSH "key auth" configuration, assuming "host1" as your
computer, "host2" as the remote machine, and "keesan" as the name of the
user on both hosts:

2) Copy the public key (the contents of /home/keesan/.ssh/id_dsa.pub)
from host1 into /home/keesan/.ssh/authorized_keys on host2.

3) Execute "ssh keesan at host2" on host1 to log into host2.

If you suspect that you messed up anywhere along the way, wipe out all
the files in ~/.ssh on both machines and restart from scratch.

> ssh keesan at xxxx
> Permission denied (publickey,password,keyboard-interactive).
>
>
> Same permissions on ssh and on the .ssh files in both computers.
>
> Same problem whether or not I copy over known_hosts from /root/.ssh .

Please forgive this error. It was getting quite late. We do have
/usr/sbin/pppd but when I dial as user it wants /etc/ppp/options, which is
what we do not have.

>Honestly, this is getting rather silly. If your software complains about
>not having some file - particularly if that file doesn't need to have
>anything special in it and doesn't require a large amount of space -
>then why not create it, perhaps by copying it from a working system? In
>the case of '/etc/ppp/options', on my system, it's just a tiny text file
>that contains about 100 bytes of non-comment text:
>
>``
>ben at Tyr:~$ grep '^[^#]' /etc/ppp/options
>asyncmap 0
>auth
>crtscts
>lock
>hide-password
>modem
>proxyarp
>lcp-echo-interval 30
>lcp-echo-failure 4
>noipx
>''

I copied this to /etc/ppp/options (without the`` '')

-rw-r--r-- root root /etc/ppp/options

- is this correct?

Now when I try to dial (never mind that I am already dialed as root):

The remote system (x0) is required to authenticate itself but I couldn't
find any suitable secret (password) for it to use to do so.

My permissions are as follows: (pppd group is 'users' not dip)

>
>>>``
>>>ben at Tyr:~$ ls -l /usr/sbin/pppd /etc/ppp/*secrets
>>>-rw------- 1 root root 80 2006-05-30 20:58 /etc/ppp/chap-secrets
>>>-rw------- 1 root root 1628 2006-05-30 20:58 /etc/ppp/pap-secrets
>>>-rwsr-xr-- 1 root dip 306720 2006-07-05 06:22 /usr/sbin/pppd
>>>'''
>>>
>>>The above means that any user who is part of group 'dip' can execute
>>>'pppd' - and since 'pppd' runs as root, it can read the files that
>>>contain the name and the password.
>>
>>In my attempts to dial I ended up with pppd -rwsr-sr-x root root
>>I am experimenting ....
>>chgrp users pppd chmod o-r pppd chmod g-s pppd
>>
>>Ten minutes later I have -rwsr-xr-- root users pppd
>
>Well, Sindi... if you don't explicitly mention that you need help with
>permissions/ownership, then you're not likely to get it. Reading the
>relevant manpages would have helped, and in significantly less than 10
>minutes (and please don't tell me that you don't have them on your
>system; at this point, searching google for "man chmod" brings up the
>'chmod' manpage as the first hit.)
>

I read Running Linux 2nd edition. I also have 'Linux Man' old version but
man pages use a lot of unfamiliar vocabulary. It would have gone faster
if I had been more awake (and I may have been exaggerating just a bit
about 10 min).

>``
>chown root.pppd pppd
>chmod 4754 pppd
>''

It is easier for me to remember o+x than the numbers.

>>This linux came with one 'user' login who lives in /home/user and uses
>>/bin/sh. Root uses /bin/bash (according to /etc/passwd). I had to make
>>/home/user owned by user (chown -R user user chgrp -R users user) before I
>>could save anything to it. As I said, this is a single-user distribution.
>
>Clearly a very badly-configured one. A home directory where you can't
>save anything as that user? That's pretty bad.

It was designed to use as root. The author says we are on our own if we
want to use it as user. The later version of this distribution does
provide a passwd package (based on tinylogin, with passwd, getty, su,
login, deluser, delgroup, adduser, addgroup, group, and /etc/group
/etc/passwd /etc/inittab) to let us add a user. But it is libc5 and the
larger distribution I am using is libc6 so I compiled adduser etc into
busybox instead. I think I can delete a user by removing a line from
/etc/passwd.

>>I compiled a new busybox which has adduser and addgroup (my linux had
>>neither). I have used adduser once.
>
>Perhaps you should use 'useradd' instead. 'adduser', etc., are front
>ends to that whole toolkit.

Tinylogin and busybox don't have useradd. I am trying to keep this small.
I got it working on a 386 with 3MB RAM (X is rather slow there).

>>addgroup users tells me it is already in use.
>
>The simplest way to add an existing user to an existing group is by
>editing '/etc/group'. The safe and simple way to do it is by using
>'vigr'.

The larger/older version has no /etc/group. It has /etc/passwd and
inittab. We do not have vigr. Since my 'user' is already in 'users' (it
came that way with the larger version) I don't think I need to add it to
any other group. I should probably change the password with 'passwd',
which I compiled in busybox. I can add more users to 'users'. I will
play with this later.

>
>>Next problem is that we are dialing with eznet not directly with pppd.
>>
>>My pap-secrets is also not world-readable and it contains the same login
>>and password info as eznet.conf. I don't know where eznet looks for
>>info.
>
>I'm not familiar with 'eznet' - I've never used it. Anytime I need to
>connect by dialing - and I do this every day with my Aircard - I just
>use 'pppd' directly (e.g., 'pppd call aircard' for the 'aircard'
>configuration.) I do this as a non-root user, and haven't had any
>problems related to the functioning of 'pppd' itself.

I would have to figure out how to do this. Eznet is already working and
even the friends I set up with linux can handle changing login and
password and phone number with the script ppp-on that edits eznet.conf.

>>I think you are saying if I set pppd SUID, then the user can use pppd,
>>which can read the login and password info from pap-secrets, but the user
>>cannot do that directly, so it is safe. But I don't know how to dial with
>>pppd directly, just via eznet.
>
>Based on what you've said (i.e., that eznet is a front end to pppd),
>'pppd' is already configured for you - the only thing you need to do is
>find out what the name of the configuration files is. Fortunately,
>that's pretty easy: take a look at '/etc/ppp/peers' - this contains all

We don't have that file. Just pap-secrets and eznet.conf.
Where would a configuration file go and what would it look like?

>your "dialup configurations". If these don't contain root-only options
>such as 'noauth' (and there's rarely any reason for having such
>options), then a non-root user can just enter
>
>``
>pppd call foo
>''
>
>where 'foo' is the name of the config file from '/etc/ppp/peers', to
>dial.
>'
>
>>Does the following help any:
>>
>>I can type 'eznet up 4' to get the fourth login and password etc. (set up
>>to use the lucent modem) listed in eznet.conf. ps lists as a process:
>>
>>/usr/sbin/pppd /dev/ttyLT0 115200 connect /usr/bin/eznet chat 4
>>defaultroute lock modem mtu 552 mru 5 (goes off the screen).
>
>If you use the 'w' option to 'ps', it'll wrap the line.

Thanks. .... mru 552 cr

I had had to set framebuffer console to 1024x768 to even see what I did.

>
>>>In other words, it appears as though you're taking a mechanism that
>>>works just fine and changing it so that it will do the same thing as
>>>it's doing now. I suggest that understanding the current mechanism would
>>>serve you better than trying to construct something new from the ground
>>>up - especially since it's not new.
>>
>>I don't have the standard setup to start with.
>
>Then whoever set up the distro broke that standard setup for no reason.

To make it small enough to fit on 2 floppy disks, including X, a browser,
a viewer, a window manager, a dialing program, a mail program and a lot of
utilities. The first disk can be used alone for rescue.

>In fact, that sounds like the core of all your problems - pretty much
>everything you've asked here in this regard has been a standard
>"question" in Unix that got answered a long time ago by either designing
>a better system or defining a specific method for dealing with the
>problem. In addition, all these things have been refined and "tuned"
>over time to eliminate or avoid security problems, problematic edge
>cases, etc. Now, it sounds like whoever put this distro together has
>recreated these ancient problems - and you're stuck trying to solve
>them. The only question, given the plethora of other, well-working
>distros out there is "why"?
>
>If you were doing this because you wanted to learn how to solve
>low-level Linux problems, perhaps this would be a good approach.
>However, you keep mentioning having to accomodate users; this is like
>trying to design a brand-new type of chainsaw and handing it out to
>random people to use while it's still in the prototype stage. The
>results that you're getting are - well, exactly what could be expected
>of such actions.

It is small and simple and works on older hardware and I already know
enough to support my friends using it for internet. It does work as
designed, for root. I have it working with root dialing and then going
online as user (except ssh). I am learning a lot trying to make it do
other things. I prefer the do-it-yourself approach. Start with the
basics and add what you need, keeping it small.

>>>In that case, either recompiling 'ssh' to look for 'ssh_askpass' in a
>>>different place, or creating the above path and a link to the
>>>actual location of 'ssh_askpass' should help.
>>
>>I don't know how to compile ssh.

>Then create the path, as I've mentioned.

I don't have the file to create the path to, as I've mentioned (in my last
mail).

>>This reply took a couple of hours. I am learning a lot. Thanks.
>
>I'm glad that you're finding this helpful, but you're working with a
>broken system and learning many lessons that are going to be useless in
>normal scenarios (along with some that will be useful.) I would
>seriously suggest exploring other distros.

I tried installing a few and uninstalled them again. I did not like
Redhat, Caldera (horrible on older hardware), Debian (does too much
automatically). SuSE was okay, but I prefer Slackware and this is a small
version of it that I can add to as needed. The default small installation
of SW10.2 used up 64MB immediately running daemons I did not ask for. It
would be a lot of work to strip Slackware. We are putting linux on
computers with 32MB RAM.

I like to do things the more educational way and not have a bunch of
programs on my computer that I don't use. Or large GUI frontends that
don't require thinking. Our mail list members are very helpful. Half of
us knew next to nothing about linux and came from DOS, and the other half
have been teaching us and compiling. One of them taught me to compile
kernels and busybox. It is a group puzzle. I like it. I was happy
running as root. Our professional users said they have had lots of
attempted breakins while online but none never succeeded. Possibly
because we have no open ports/sockets. I am willing to try to make things
more secure anyway, but not willing enough to change distributions.

There is no point in my dialing as user until I can ssh as user because I
spend most of my online time at four shell accounts. But friends would
benefit from dialing as user. In the meantime they prefer what I gave
them to Windows. It is a lot more secure.

> SuSE was okay, but I prefer Slackware and this is a small
> version of it that I can add to as needed. The default small installation
> of SW10.2 used up 64MB immediately running daemons I did not ask for. It
> would be a lot of work to strip Slackware. We are putting linux on
> computers with 32MB RAM.

I haven't used Slackware in a long time, but recall it being very easy
to pare down, e.g., disabling unwanted processes' startup. And
small-RAM machines were a particular strong area for that distro. I
don't know about the prospects for shrinking it to anything like
two-floppy sizes, though.

(By the way, please remember to Reply-to-All, when you are responding to
TAG, or to mailing lists generally. Thanks.)

--
Cheers, "Your program just attempted an illegal instruction. No worries, mate."
Rick Moen -- Australian error messages, #14 in a series
rick at linuxmafia.com

> Sindi Keesan <keesan at grex.cyberspace.org> wrote:
>
>> SuSE was okay, but I prefer Slackware and this is a small
>> version of it that I can add to as needed. The default small installation
>> of SW10.2 used up 64MB immediately running daemons I did not ask for. It
>> would be a lot of work to strip Slackware. We are putting linux on
>> computers with 32MB RAM.
>
> I haven't used Slackware in a long time, but recall it being very easy
> to pare down, e.g., disabling unwanted processes' startup. And
> small-RAM machines were a particular strong area for that distro. I
> don't know about the prospects for shrinking it to anything like
> two-floppy sizes, though.

My distribution boots in 15 seconds and works in 3MB RAM. I can put a
20MB loop version into a DOS or Win9X partition for people to play with or
even use. I added it to a small partition on someone's Win98 computer in
which the viruses had disabled the lucent modem, and it worked online. Now
that I can dial, use X, and print as user (without a print spooler such as
lpr) my friends won't need Win98 for wordprocessing either. (It is their
problem if they want to play fancy online games). Most people I know just
user their computers for wordprocessing, webmail, and basic web searches.
They don't need most of what comes with a distribution.

This distribution is now included in a universal boot CD.

Slackware 10.2 came with several pages of X.org default configuration.
Our Xvesa needs no configuration. If it does not work with some video
card we have a simple package for using the SVGA server. And today I got
Scitech Display Doctor working, which might help with Xvesa compatibility
on our older hardware. (SDD is 1998 and got a Divide error when
self-extracting on a 2001 computer).

It may be easy for you to stop the daemons from running but it would be
just as much work for me to disable 90% of Slackware as to add the parts I
do want to my own distribution.

I will attempt to write up and post to my distribution mailing list all
the changes I needed to make to get online as user, so other people can do
it more easily. I had problems with permissions and ownership and
configuration files for pppd, Xvesa, rxvt, svgalib programs, various
devices (ttyS*, ttyp*, null), the user home directory and probably more.
Maybe the next version will have different permissions so as to work for
user.

ssh compiled for us still is not working for user. I can use it as root
after dialing as user. It wants a file which I don't need as root.

Putty's psftp which I just compiled works for user.
Putty would not compile because it is X-based and would need more
libraries. Another list member is working on compiling the latest openssh
(for console) and maybe that will work better for user.

>
> (By the way, please remember to Reply-to-All, when you are responding to
> TAG, or to mailing lists generally. Thanks.)

3MB RAM is pretty impressive in 2007 -- but more than a bit extreme.
(Is it a requirement?) In any event, any Linux distro, in any decade,
that requires routine use of the root account is broken. You might find
a suitable substitute here: "Small Linux" on http://linuxmafia.com/kb/Admin/ .
Note in particular: http://www.superant.com/smalllinux/

As mentioned previously, I'm not prepared to assist in encouraging
demonstrably bad habits and practices.

> Quoting Sindi Keesan (keesan at grex.cyberspace.org):
>
>> My distribution boots in 15 seconds and works in 3MB RAM.
>
> 3MB RAM is pretty impressive in 2007 -- but more than a bit extreme.
> (Is it a requirement?) In any event, any Linux distro, in any decade,
> that requires routine use of the root account is broken. You might find
> a suitable substitute here: "Small Linux" on http://linuxmafia.com/kb/Admin/ .
> Note in particular: http://www.superant.com/smalllinux/

Smallinux looks interesting but it also runs root only. Kernel 2.0,
libc5. I am using 2.4.31 kernel (for the usb-storage support which remains
broken in 2.2, but which works in DOS).

3MB was not required but several of us tested it out on laptops. The
video was quite slow on the old style LCD screens. svgalib used less
memory than X. DOS with lynx for DOS worked a lot better in 3MB, with a
small viewer (lxpic). Our linux works nicely in 12MB. The distribution
is now aimed at older laptops but is expandable to work with newer
hardware.

Yes, noted. I'm frankly amazed that it's possible to run any Linux in
3 MB of total RAM, since it was always a struggle to squeeze into 16 MB,
even in the old days.

If I still had one of those boxes (sub-16MB), I think I'd let it keep
running MS-DOS and Telix, and use it in server rooms for machines that
need remote serial console. They are surely likely to be on their last
legs, among other problems.

With 16 MB and a 200 MB HD, by contrast, I would guess it should be
still possible to run small X configurations with a reasonable security
model, but have not attempted to hit that mark for a long time.

> Quoting Sindi Keesan (keesan at grex.cyberspace.org):
>
>> Smallinux looks interesting but it also runs root only. Kernel 2.0,
>> libc5.
>
> Yes, noted. I'm frankly amazed that it's possible to run any Linux in
> 3 MB of total RAM, since it was always a struggle to squeeze into 16 MB,
> even in the old days.

A smaller kernel helps a lot. And a swap file.

> If I still had one of those boxes (sub-16MB), I think I'd let it keep
> running MS-DOS and Telix, and use it in server rooms for machines that
> need remote serial console. They are surely likely to be on their last
> legs, among other problems.

Our Basiclinux distribution was designed so you could use it as a terminal
with X, to run graphical programs on another faster machine. It comes
with microcom and I succeeded in using it with serial nullmodem cable as
a console.

The older machines tended to have soldered-on batteries which would leak
and corrode the board.

> With 16 MB and a 200 MB HD, by contrast, I would guess it should be
> still possible to run small X configurations with a reasonable security
> model, but have not attempted to hit that mark for a long time.