Hey list, On my box I have sendmail running. In order to use SMTP over SSL I run it with stunnel in inetd: smpts stream tcp nowait root /usr/local/sbin/stunnel stunnel -D 3 -p /usr/local/ssl/certs/stunnel.pem -r smtp Further I configured sendmail to use SMTP AUTH. Everything works perfect. 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?) Is there a solution that I can use SMTP over SSL and SMTP AUTH? Clients should not be able to connect without SSL or SMPT AUTH! Thanks Raffy
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
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. -- Mit freundlichen Gruessen / best regards, Sven Michels Network Operating Center / Infrastructure ----------------------------------------- intraDAT AG Wilhelm Leuschner Strasse 7 u. 9-11 60329 Frankfurt / Germany Tel: +49 69 256 29 - 0 Fax: +49 69 256 29 - 256 http://www.intradat.com ----------------------------------------- Besuchen Sie uns vom 22.03.01-28.03.01 auf der CeBIT in Hannover, Halle 3 Stand E45 -----------------------------------------
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
On Wed, 21 Mar 2001 17:59:31 +0100, Thomas Haeberlen <Haeberlen@RUS.Uni-Stuttgart.DE> 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
Egan wrote:
On Wed, 21 Mar 2001 17:59:31 +0100, Thomas Haeberlen <Haeberlen@RUS.Uni-Stuttgart.DE> 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
On Wed, 21 Mar 2001 18:47:53 +0100, William Preston <william.preston@100world.com> 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
Egan wrote:
On Wed, 21 Mar 2001 18:47:53 +0100, William Preston <william.preston@100world.com> 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
On Wed, 21 Mar 2001 19:44:32 +0100, William Preston <william.preston@100world.com> wrote:
Just add the pam_wheel line to the end of your file.
Almost. I just discovered that group wheel is not gid 0 on SuSE. It's gid 10 so I had to put myself in that group too. But it works now, thanks. Egan
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
On Thu, 22 Mar 2001 17:32:03 +0000 (GMT), Bob Vickers <bobv@cs.rhul.ac.uk> 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?
It was suggested to me, and after adding my user name to group wheel (gid 10, not 0) in addition to group root, it works. This is on SuSE 7.1. Egan
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
Hi!
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.
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), and then use either a "su" or a "su -" to become root. I don't know how to block this approach, given that it still works, and also I don't know whether or not this still works at all nowadays: I've used it ages ago. Cheers, Yuri. -------------------------------------------------------------------------- Yuri Robbers phone : +31-71-527-4966 Leiden University fax : +31-71-527-4900 Institute for Theoretical Biology email : robbers@rulsfb.leidenuniv.nl Kaiserstraat 63 2311 GP Leiden PGP 5.0 public key available: the Netherlands Check your favourite hkp server. --------------------------------------------------------------------------
On Thu, 22 Mar 2001 19:16:03 +0100 (MET), Yuri Robbers <yuri@rulbii.leidenuniv.nl> 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
Hi!
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.
I'm glad! I need that very often :o)
and then use either a "su" or a "su -" to become root.
But that failed, reporting incorrect password.
Ok good. It might be a problem for some people, but I think it's safer this way... it would be no use to allow only members of wheel to su to root if anyone could su to wheel and then to root. Apart from adding an extra password between the status of mortal user and root of course.
I don't know how to block this approach,
My test indicates it's already blocked.
Groovy. Thanks. Ciao, Yuri. -------------------------------------------------------------------------- Yuri Robbers phone : +31-71-527-4966 Leiden University fax : +31-71-527-4900 Institute for Theoretical Biology email : robbers@rulsfb.leidenuniv.nl Kaiserstraat 63 2311 GP Leiden PGP 5.0 public key available: the Netherlands Check your favourite hkp server. --------------------------------------------------------------------------
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/
Hi all, I hope this is not off-topic, since it despite being a security question, it is not directly SuSE-related. Please send your flames to me and not to the list if you think I should not have posted this. Anyway, here goes... 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... Thanks, Yuri. -------------------------------------------------------------------------- Yuri Robbers phone : +31-71-527-4966 Leiden University fax : +31-71-527-4900 Institute for Theoretical Biology email : robbers@rulsfb.leidenuniv.nl Kaiserstraat 63 2311 GP Leiden PGP 5.0 public key available: the Netherlands Check your favourite hkp server. --------------------------------------------------------------------------
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/
On Thu, Mar 22, 2001 at 23:30 +0100, 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. [ ... ] 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...
www.openssh.org has some links to "alternatives for other platforms" (or something similar), see the end of the left navigation column. The most portable is probably MindTerm since Java is said to run almost everywhere. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
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 -------------------------------------------------------------------
Hello, I made the changes to pam for su that only the group wheel can become superuser. All works fine. I log in as an usual user and made su and have root-access. 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? Thomas
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
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
Hi list my password has only eight character in the range [a-z]. Thomas
"Thomas" == Thomas Hartmann <thomas@hartmann.net> 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
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. My guess is that by the time sshd is dead telnet is also probably dead. There was a recent post to bugtraq about some vulnerabilities in ssh and besides I don't think you would want to telnet as root. Why not simply ssh as yourself and then su or use sudo to become root?
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.
At 09:47 PM 22/03/2001, you wrote:
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.
When you execute harden_suse it sets up a system a little similar to the what Open/Free BSD has. Except the group is called trusted and the enforcement of who can su is done with file permissions and not pam. If you wish to set it exactly the same as the BSD's then use the pam_wheel module as previously discussed by others. 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) On my systems I allow only ssh certificate based logins (no passwords at all) and also enforce the trusted group access. This means to compromise the machine (assuming there are no buffer overflows etc) an attacker has to have a copy of my ssh private certificate, (and know the rather long password it has protecting it) as well as know the rather long root password. (I enable MD5 hashes instead of DES so I can have longer passwords.. the doco for this is in /usr/share/doc/packages/pam) If there are any other users on the system they will not have su access. If I need them to be able to do stuff, I give them access to sudo.. Cheers --- Nix - nix@susesecurity.com http://www.susesecurity.com
On Thu, 22 Mar 2001 22:52:56 +1100, Nix <suse@nix.hispeed.com> 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
On Wed, 21 Mar 2001 17:31:30 +0100, Sven Michels <smichels@intradat.com> 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.
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.
Maybe I'm just remembering the way BSDI worked ... 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
Hey list,
On my box I have sendmail running. In order to use SMTP over SSL I run it with stunnel in inetd:
smpts stream tcp nowait root /usr/local/sbin/stunnel stunnel -D 3 -p /usr/local/ssl/certs/stunnel.pem -r smtp
Further I configured sendmail to use SMTP AUTH. Everything works perfect.
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?)
Is there a solution that I can use SMTP over SSL and SMTP AUTH? Clients should not be able to connect without SSL or SMPT AUTH!
firewall it on the local machine, Linux has firewalling capabilities (ipchains in 2.2, iptables in 2.4).
Thanks
Raffy
-Kurt
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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
participants (19)
-
Bob Vickers
-
Egan
-
Florian Kirchmeir
-
Gerhard Sittig
-
Kurt Seifried
-
Michael Bain
-
Nadeem Hasan
-
Nix
-
Raffy
-
Ralf Ronneburger
-
rise
-
RoMaN SoFt / LLFB!!
-
semat
-
Sven Michels
-
Thomas Haeberlen
-
Thomas Hartmann
-
Thorsten Marquardt
-
William Preston
-
Yuri Robbers