On Wed, Mar 21, 2001 at 05:31:30PM +0100, Sven Michels wrote:

Egan wrote:

...

On my new SuSE 7.1 any user can su to root if they know the root password. I thought only members of group root could su to root, but now anybody can.

Is this a bug?

no, but what you need is to set the permissions on su .. only root and the member of the group x (can be root or whatever) can execute su.

Ahem... if a user knows the root password, why would you want to keep him or her from becoming root, anyway? If you restricted permissions of su, to members of the "root" group, then other users would not be able to change their "id" at all - you need to decide for yourself whether you want this or not. I don't see very much benefit in restricting access to su. On the other hand if e.g. you set your box to allow root to log in only on the console and never over the net... but still: if you can't trust the people who know the root password to use "su" correctly, then you probably shouldn't let them know the root password in the first place. Or am I missing something? Bye, Thomas -- Thomas Haeberlen Rechenzentrum Universitaet Stuttgart (RUS) Abteilung Informationsdienste Allmandring 30 , D-70569 Stuttgart Email: haeberlen@rus.uni-stuttgart.de Phone: +49 711 685 47 19 Fax: +49 711 678 76 26

Egan wrote:

On Wed, 21 Mar 2001 17:59:31 +0100, Thomas Haeberlen wrote:

...

Ahem... if a user knows the root password, why would you want to keep him or her from becoming root, anyway?

For a second level of protection. I think it is better if only the users who belong to group root can su to root.

...

If you restricted permissions of su, to members of the "root" group, then other users would not be able to change their "id" at all

That is what others have suggested, but that is a problem.

...

On the other hand if e.g. you set your box to allow root to log in only on the console and never over the net...

That's not feasible on a box in remote collocation.

...

but still: if you can't trust the people who know the root password to use "su" correctly, then you probably shouldn't let them know the root password in the first place.

There is only one person who knows the root password, me. I have to log in remotely, most of the time with sshd, but in emergencies, with telnet and then su to root.

I don't want other users trying su to root and guessing the password. It would be nice if su had that extra level of protection the way it did on bsdi.

Egan

If you use pam then perhaps the pam_wheel module is what you're looking for? add the following to /etc/pam.d/su: auth required pam_wheel.so William

Egan wrote:

On Wed, 21 Mar 2001 18:47:53 +0100, William Preston wrote:

...

...

I don't want other users trying su to root and guessing the password. It would be nice if su had that extra level of protection the way it did on bsdi.

...

add the following to /etc/pam.d/su:

auth required pam_wheel.so

Here is my default /etc/pam.d/su:

...

#%PAM-1.0 auth sufficient /lib/security/pam_rootok.so auth required /lib/security/pam_unix.so nullok #set_secrpc account required /lib/security/pam_unix.so password required /lib/security/pam_unix.so #session required /lib/security/pam_homecheck.so session required /lib/security/pam_unix.so debug # none or trace

What does this first line do?

...

...

auth sufficient /lib/security/pam_rootok.so

And will that conflict with your suggestion?

Egan

The first line means that root is allowed to su to any user without a password --which is normal for most systems. Just add the pam_wheel line to the end of your file. The PAM documents are very good- I think they're installed under /usr/share/doc/packages/pam for SuSE7 William

A very similar discussion was held on this list in October and the conclusion was that 2 of the documented ways of doing this (/etc/suauth and PAM) did not work. Of course, things may have changed now. Have the people suggesting PAM actually tried it and confirmed that it does indeed restrict who can su to root? Of course, changing the permissions of the su program works fine. Bob ============================================================== Bob Vickers R.Vickers@cs.rhul.ac.uk Dept of Computer Science, Royal Holloway, University of London WWW: http://www.cs.rhul.ac.uk/home/bobv Phone: +44 1784 443691

Bob Vickers wrote:

A very similar discussion was held on this list in October and the conclusion was that 2 of the documented ways of doing this (/etc/suauth and PAM) did not work. Of course, things may have changed now. Have the people suggesting PAM actually tried it and confirmed that it does indeed restrict who can su to root?

I couldn't find the thread in the archives, but the PAM way definitely works on SuSE7, with caveats... ...you have to add the username to the wheel group in /etc/group, for some reason it's not enough to make the primary group wheel. And you can't su to a member of the wheel group, then su root either.

Of course, changing the permissions of the su program works fine.

Bob

William

On Thu, 22 Mar 2001 19:16:03 +0100 (MET), Yuri Robbers wrote:

I cannot try this now to see if it still works, but in the past I've used the following workaround for this: use "su -" to su to a member of the wheel group (the "-" makes this a login shell),

That worked.

and then use either a "su" or a "su -" to become root.

But that failed, reporting incorrect password.

I don't know how to block this approach,

My test indicates it's already blocked. Egan

William Preston wrote:

Bob Vickers wrote:

<snip>

And you can't su to a member of the wheel group, then su root either.

<snip> Use "use_uid" parameter with pam_wheel.so to get this behaviour. For more info, see: /usr/share/doc/packages/pam/modules/README.pam_wheel (on 7.1) -- Nadeem Hasan nhasan@nadmm.com http://www.nadmm.com/

On Thu, 22 Mar 2001, Yuri Robbers wrote:

Sometimes I have to remotely log into a system (SuSE :o) of mine from a machine that doesn't come with ssh. That's why I tend to carry ssh client binaries for a number of OS's with me most of the time. I'd like to add some more of those to my collection. Does anyone know where to find or how to compile ssh binaries on any of these OS's: VMS, DOS, AmigaOS, Acorn RISC-OS and Mac-OS? For VMS I would be interested in having an ssh server too...

For MacOS I can recommend Nifty Telnet-SSH. If that server (or another you're running) has a web server a good approach to consider is setting up Mindbright's[0] MindTerm (Java SSH client - there's also a server available) on a web page. At that point if you've got a Java capable browser (which may be just as much of a pain for some of those platforms) you've got SSH access. If you do a lot of remote admin work this is pretty convenient even for platforms like Unix and Windows where SSH implementations are (cheap|free) and widely available. You're still vulnerable to keystroke loggers, etc. on an untrusted machine, but at least you're not sending passwords in the clear. The main issue to be aware of is code-signing - I believe that if you don't code-sign the app or have Mindbright do it (big money) you can only contact the server it's on - but you can always download it and use it with a JRE/JDK as a normal application. Note that their "free for personal use" includes you putting it up for your own use on your own initiative even in a commercial setting - they even specifically give setting it up on your own machine so you can connect to it from outside as an example. FSF compatible it's not, but the terms are lenient and usable. Jonathan Conway [0] http://www.mindbright.se/

Am 22-Mär-01 schrieb Yuri Robbers:

Hi all,

Sometimes I have to remotely log into a system (SuSE :o) of mine from a machine that doesn't come with ssh. That's why I tend to carry ssh client binaries for a number of OS's with me most of the time. I'd like to add some more of those to my collection. Does anyone know where to find or how to compile ssh binaries on any of these OS's: VMS, DOS, AmigaOS, Acorn RISC-OS and Mac-OS? For VMS I would be interested in having an ssh server too...

A ssh capable client for Amiga is napsaterm. I use V3.13for years. But I can't remember where it came from. Another Client may be AmTelnet available from www.vapor.com . But since it's commercial I've no experiances with it. Bye Thom -- I like work ... I can sit and watch it for hours. ------------------------------------------------------------------- bye bye (c) by Thom | Thorsten Marquardt | EMail: THOM@kaupp.chemie.uni-oldenburg.de | Member of the pzt project. | http://www.pzt.de -------------------------------------------------------------------

Hi list! Thomas Hartmann wrote:

Only if I run a xterm-client and use the su command, su reports incorrect password? If I make an ssh localhost in my xterm-client an start su, it works? Why?

Have you got any control characters in your password? I've seen that on NCD X-Terminals, that wouldn't accept any double quotes (or was it $?) in any password. Got them square somehow. Only solution was to change the password from another terminal to one that didn't contain that character. Greetz, Florian Kirchmeir

...

...

...

...

"Thomas" == Thomas Hartmann writes:

Thomas> Only if I run a xterm-client and use the su command, su Thomas> reports incorrect password? If I make an ssh localhost in my Thomas> xterm-client an start su, it works? Why? I'll take a wild ass guess; your system is configured not to let root log into a console? On mine, I can't log in as root on the X GUI login screen, but once I'm in have no problem su-ing to root. -- Michael Bain mbain@duc916.com ----------------------------------------------------------------------- "What's another word for Thesaurus?" -- Steven Wright

On Wed, Mar 21, 2001 at 05:31:30PM +0100, Sven Michels wrote:

...

Egan wrote:

...

On my new SuSE 7.1 any user can su to root if they know the root password. I thought only members of group root could su to root, but now anybody can.

I think what he wants is the freebsd style su. Anyone can su to another normal user but only members of group wheel ( read root ) can su to root.

On Thu, 22 Mar 2001 22:52:56 +1100, Nix wrote:

...

I think what he wants is the freebsd style su. Anyone can su to another normal user but only members of group wheel ( read root ) can su to root.

Right.

If you wish to set it exactly the same as the BSD's then use the pam_wheel module as previously discussed by others.

Didn't know about that, but after trying it, it's just what I needed.

There are very good reasons to do defense in depth this way, there are cases where in penetration tests we have compromised the root password (through poor permissions of history files etc) but have been unable to su because of wheel setup)

That's one good reason why I want to control su to root, yet maintain non-root su flexibility for normal users.

On my systems I allow only ssh certificate based logins (no passwords at all) and also enforce the trusted group access.

I have to manage remote servers. There have been times when I needed to stop, or perhaps accidentally stopped sshd (thinking I was logged into a different server). The only way to regain access was via telnet and su to root. Those rare emergency situations where root's password is sent in the clear are an acceptable risk, considering the alternative is not logging in at all, to a server 1,000 miles away. Egan

Hi Egan, as far as I remember: the user has to be in the group trusted to su to root, at least if you've set your Permissions to "paranoid" (I think it's the same with "secure"). I don't know about the other permission-settings. You should check the group-setting and the permissions for "su". Greetings, Ralf Egan schrieb:

On my new SuSE 7.1 any user can su to root if they know the root password. I thought only members of group root could su to root, but now anybody can.

Is this a bug?

Egan

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

On Wed, 21 Mar 2001 15:19:09 -0700, you wrote:

...

But: smpts is on port 465. I configured my clients such that they use that port. So far so good. But now port 25 can still be used to send email. I could block it at the firewall but then I am not able to receive email any more, because other mailservers are talking with me on that port. (right?)

firewall it on the local machine, Linux has firewalling capabilities (ipchains in 2.2, iptables in 2.4).

I think it would be possible to make a kind of "conditional" port-forwarding (based on clients' ip). It should be similar as transparent proxying process: you set some ipchains/iptables rules with -j REDIRECT target. For instance: "packets coming from our local clients and destined to port 25 should be redirected to port 465". This is easy to achieve (documented in many docs: nat, fws, squid, transparent-proxy minihowto, etc). You should also set the return path: "all packets destined to our local clients coming from port 465 must be mangled to show as if they came from port 25" (it's another redirection). =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ** RoMaN SoFt / LLFB ** roman@madrid.com http://pagina.de/romansoft ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~