I see that /bin/false is not a valid shell by default on CentOS. It is f.i. on Suse. /bin/false is present, though. Is there a security reason for this? man says that nologin gives feedback that the account is not available while false just exits false. Anything against just adding /bin/false to /etc/shells? Kai -- Kai Sch?tzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Le Mercredi 22 Mars 2006 18:17, Kai Schaetzl a ?crit?:> I see that /bin/false is not a valid shell by default on CentOS. It is > f.i. on Suse. /bin/false is present, though. Is there a security reason > for this? man says that nologin gives feedback that the account is not > available while false just exits false. Anything against just adding > /bin/false to /etc/shells?I''d say use /sbin/nologin instead. It''s already in /etc/shells, and is able to give a reason about why login fails (check its man page for that).
Le Mercredi 22 Mars 2006 20:05, Vincent Knecht a ?crit?:> Le Mercredi 22 Mars 2006 18:17, Kai Schaetzl a ?crit?: > > I see that /bin/false is not a valid shell by default on CentOS. It is > > f.i. on Suse. /bin/false is present, though. Is there a security reason > > for this? man says that nologin gives feedback that the account is not > > available while false just exits false. Anything against just adding > > /bin/false to /etc/shells? > > I''d say use /sbin/nologin instead. > It''s already in /etc/shells, and is able to give a reason about why login > fails (check its man page for that).Argh, I read/reply too fast without replying to the real question, sorry... Some little research told me that some ''/bin/false'' versions have no real ''login'' capacity, but dunno about CentOS'' one.
HI guys, If the rpm for this could be produced as soon as humanly possible it would be appreciates ! thanks guys - Synopsis Critical: sendmail security update Issued: 3/22/06 Updated: 3/22/06 Topic Updated sendmail packages to fix a security issue are now available for Red Hat Enterprise Linux 3 and 4. This update has been rated as having critical security impact by the Red Hat Security Response Team. Description Sendmail is a Mail Transport Agent (MTA) used to send mail between machines. A flaw in the handling of asynchronous signals was discovered in Sendmail. A remote attacker may be able to exploit a race condition to execute arbitrary code as root. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0058 to this issue. By default on Red Hat Enterprise Linux 3 and 4, Sendmail is configured to only accept connections from the local host. Therefore, only users who have configured Sendmail to listen to remote hosts would be able to be remotely exploited by this vulnerability. Users of Sendmail are advised to upgrade to these erratum packages, which contain a backported patch from the Sendmail team to correct this issue. Solution Before applying this update, make sure all previously released errata relevant to your system have been applied. This update is available via Red Hat Network. To use Red Hat Network, launch the Red Hat Update Agent with the following command: up2date This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. Affected Channels Red Hat Enterprise Linux ES (v. 3 for AMD64/Intel EM64T) Red Hat Enterprise Linux ES (v. 3 for Itanium) Red Hat Enterprise Linux ES (v. 3 for x86) Red Hat Enterprise Linux ES (v. 4 for 32-bit x86) Red Hat Enterprise Linux ES (v. 4 for 64-bit Intel Itanium) Red Hat Enterprise Linux ES (v. 4 for AMD64/Intel EM64T)
One thing you can do if the update doesn''t come fast enough for you is rebuilding the latest sendmail .src.rpm provided by RH (AFAIK that''s exactly what the CentOS team is doing). That way, you''ll get it before every others :). Gilles.
On Wednesday 22 March 2006 20:47, Tony Wicks wrote:> HI guys, If the rpm for this could be produced as soon as humanly > possible it would be appreciates ! thanks guys -Next time try to write a _new_ e-mail and resist the temptation to hit reply on a random list post. Now you''re e-mail ended up at the end of a (potentially ignored) thread. /Peter -- ------------------------------------------------------------ Peter Kjellstr?m | National Supercomputer Centre | Sweden | http://www.nsc.liu.se -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : http://lists.centos.org/pipermail/centos/attachments/20060322/23714fda/attachment.bin
Kai Schaetzl wrote:> I see that /bin/false is not a valid shell by default on CentOS. It is > f.i. on Suse. /bin/false is present, though. Is there a security reason > for this? man says that nologin gives feedback that the account is not > available while false just exits false. Anything against just adding > /bin/false to /etc/shells?The login shell is used for an interactive login (ssh). Some other types of login will check to see if the login shell is listed in /etc/shells before they allow access. I think this is done by pam_shells. eg: To give a user ftp only, set their shell to /sbin/nologin (and make sure that is in /etc/shells) To have a user with no interactive or ftp, set their shell to /bin/false and make sure it is not listed in /etc/shells John.> > Kai >-- John Newbigin Computer Systems Officer Faculty of Information and Communication Technologies Swinburne University of Technology Melbourne, Australia http://www.ict.swin.edu.au/staff/jnewbigin
Kai Schaetzl wrote:> I see that /bin/false is not a valid shell by default on CentOS. It is > f.i. on Suse. /bin/false is present, though. Is there a security reason > for this? man says that nologin gives feedback that the account is not > available while false just exits false. Anything against just adding > /bin/false to /etc/shells?Just use it if you want. I''d keep it out of /etc/shells. Historically, some network daemons refused to authenticate users if user''s shell was not present in /etc/shells.
Vincent Knecht wrote on Wed, 22 Mar 2006 20:18:26 +0100:> Some little research told me that some ''/bin/false'' versions have no real > ''login'' capacity, but dunno about CentOS'' one.Aha, thanks. Kai -- Kai Sch?tzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Tony Wicks wrote:> HI guys, If the rpm for this could be produced as soon as humanly > possible it would be appreciates ! thanks guys -It was already released, probably as you were typing above email. It might take some time for it to propagate to all mirrors. Telus in Canada already has it (just one example).
Aleksandar Milivojevic wrote on Wed, 22 Mar 2006 18:19:53 -0600:> Just use it if you want. I''d keep it out of /etc/shells. Historically, > some network daemons refused to authenticate users if user''s shell was > not present in /etc/shells.Well, vsftpd still does, that''s how I came about it. I have always used /bin/false on my Suse setups (which has /bin/false in /etc/shells) and am currently migrating the first machine to CentOS. So, I noticed the users couldn''t login via ftp unless I changed to /sbin/nologin. I decided to add /bin/false to /etc/shells. Kai -- Kai Sch?tzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com