RE: [suse-security] nobody
Preetam, Yes, to offer system accounts open outside is a security risk. Normally sysadmins solve this by setting the login shells to /dev/null. Jose -----Original Message----- From: Preetam Ramakrishna [mailto:rpreetam@novell.com] Sent: Monday, August 08, 2005 12:35 PM To: Thomas, Jose - Authorized Dell Representative; suse-security@suse.com Subject: RE: [suse-security] nobody Jose, Thanks for the information. I understand the need for system accounts. But, I thought giving a shell to such accounts could be a security risk. Thanks, Preetam
8/8/2005 10:09:18 AM >>> Preetham,
These system accounts (daemon, nobody, lp, bin, uucp etc.) are using to execute system functions that require special privilages. For eg. to access certain files or directories, but that does not require root privilages. These special users are associated with particular system functions rather than indvidual users. Different flavours have slightly different kind of implementation. To understand why these special accounts are in use, we can consider the example of uucp (Unix to Unix CoPy) program. Except for legacy networks, uucp is not a widely use mail transmission mechanism now. UUCP is use for transfering files and mails between unix systems connected by telephone lines. When one computer dials another it must first log in instead of logging in as root, the remote compter log in as uucp. The mails (or files) that is awaiting transmission to the remote machine is stored in directories that are readable only by uucp user. nobody - nfs anonymous access user; nobody4 - nfs4 anonymous access user; uucp - uucp admin; daemon - use for network utilities; bin, sys - for system files; lp - for line printer (or laser printer :-)) etc. However I think some are maintain as it is due to historical reasons to keep the legacy systems interact well with more recent Linux systems. HTH Jose -----Original Message----- From: Preetam Ramakrishna [mailto:rpreetam@novell.com] Sent: Friday, August 05, 2005 9:47 AM To: suse-security@suse.com Subject: [suse-security] nobody Hi, The system accounts like nobody, daemon, lp, etc on SUSE have a shell in the /etc/password file. Why is this required. These system accounts do not have a shell on other unix / linux systems. Thanks, Preetam -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
Jose, But, in SuSE, these system accounts have a shell entry in /etc/password file. Doesn't this mean that that particular user can login to the system. Thanks, Preetam
8/8/2005 1:00:33 PM >>> Preetam,
Yes, to offer system accounts open outside is a security risk. Normally sysadmins solve this by setting the login shells to /dev/null. Jose -----Original Message----- From: Preetam Ramakrishna [mailto:rpreetam@novell.com] Sent: Monday, August 08, 2005 12:35 PM To: Thomas, Jose - Authorized Dell Representative; suse-security@suse.com Subject: RE: [suse-security] nobody Jose, Thanks for the information. I understand the need for system accounts. But, I thought giving a shell to such accounts could be a security risk. Thanks, Preetam
8/8/2005 10:09:18 AM >>> Preetham,
These system accounts (daemon, nobody, lp, bin, uucp etc.) are using to execute system functions that require special privilages. For eg. to access certain files or directories, but that does not require root privilages. These special users are associated with particular system functions rather than indvidual users. Different flavours have slightly different kind of implementation. To understand why these special accounts are in use, we can consider the example of uucp (Unix to Unix CoPy) program. Except for legacy networks, uucp is not a widely use mail transmission mechanism now. UUCP is use for transfering files and mails between unix systems connected by telephone lines. When one computer dials another it must first log in instead of logging in as root, the remote compter log in as uucp. The mails (or files) that is awaiting transmission to the remote machine is stored in directories that are readable only by uucp user. nobody - nfs anonymous access user; nobody4 - nfs4 anonymous access user; uucp - uucp admin; daemon - use for network utilities; bin, sys - for system files; lp - for line printer (or laser printer :-)) etc. However I think some are maintain as it is due to historical reasons to keep the legacy systems interact well with more recent Linux systems. HTH Jose -----Original Message----- From: Preetam Ramakrishna [mailto:rpreetam@novell.com] Sent: Friday, August 05, 2005 9:47 AM To: suse-security@suse.com Subject: [suse-security] nobody Hi, The system accounts like nobody, daemon, lp, etc on SUSE have a shell in the /etc/password file. Why is this required. These system accounts do not have a shell on other unix / linux systems. Thanks, Preetam -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
Preetam Ramakrishna wrote:
But, in SuSE, these system accounts have a shell entry in /etc/password file. Doesn't this mean that that particular user can login to the system.
I suggest you to lock system accounts with "passwd -l"; this will prevent password based logins. -- Mit freundlichen Grüßen / Sincerely Dipl. Inform. Ralph Seichter
Hi *, Preetam Ramakrishna schrieb:
Jose,
But, in SuSE, these system accounts have a shell entry in /etc/password file. Doesn't this mean that that particular user can login to the system.
Not directly, cause if you have a look at /etc/shadow there will be no password by default. But one can use su or sudo. So you can for example make a group webadmins put some users into that group, and enable sudo to the Webserver-User. One of the group can login, and then switch over to Webserver Administration with the sudo command. In this case the Webserver-User needs a login-Shell. The daemon itself doesn`t need the shell. Remember, no Password should be known by more than 1 Person. ;-)
Thanks, Preetam
8/8/2005 1:00:33 PM >>> Preetam,
Yes, to offer system accounts open outside is a security risk. Normally sysadmins solve this by setting the login shells to /dev/null.
I would prefer /bin/false Or better, write a little Program /bin/falselogin which is doing the same as /bin/false but aditionally logging Time, UID, GID, PID, ps -ef and network Status ;-)) (Could do some sleep 1000 too ;->=> ) You should _not_ read any Parameters. (like GNU false --help :-/) /dev/null is no executable and will result in some obscure error Messages :-/. Btw. most modern Xploits don`t use the login shell. But every closed door is a good door. Dirk TRIA IT-consulting GmbH Joseph-Wild-Straße 20 81829 München Germany Tel: +49 (89) 92907-0 Fax: +49 (89) 92907-100 http://www.tria.de -------------------------------------------------------- working hard | for your success -------------------------------------------------------- Registergericht München HRB 113466 USt.-IdNr. DE 180017238 Steuer-Nr. 802/40600 Geschäftsführer: Richard Hofbauer kaufm. Geschäftsleitung: Rosa Igl -------------------------------------------------------- Nachricht von: Dirk.Schreiner@tria.de Nachricht an: suse-security@suse.com # Dateianhänge: 0 Die Mitteilung dieser E-Mail ist vertraulich und nur für den oben genannten Empfänger bestimmt. Wenn Sie nicht der vorgesehene Empfänger dieser E-Mail oder mit der Aushändigung an ihn betraut sind, weisen wir darauf hin, daß jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung sowie Weitergabe des Inhalts untersagt ist. Wir bitten Sie uns in diesem Fall umgehend zu unterrichten. Vielen Dank The information contained in this E-Mail is privileged and confidental intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient or competent to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this E-Mail is strictly prohibited. If you have received this E-Mail in error, please notify us immediately. Thank you
Hi, Thanks for the info. So, If I understand correctly, I can have system accounts with shell entry, but still prevent that account from login. Thanks, Preetam
"Dirk Schreiner"
8/8/2005 3:09:06 PM >>> Hi *,
Preetam Ramakrishna schrieb:
Jose,
But, in SuSE, these system accounts have a shell entry in /etc/password file. Doesn't this mean that that particular user can login to the system.
Not directly, cause if you have a look at /etc/shadow there will be no password by default. But one can use su or sudo. So you can for example make a group webadmins put some users into that group, and enable sudo to the Webserver-User. One of the group can login, and then switch over to Webserver Administration with the sudo command. In this case the Webserver-User needs a login-Shell. The daemon itself doesn`t need the shell. Remember, no Password should be known by more than 1 Person. ;-)
Thanks, Preetam
8/8/2005 1:00:33 PM >>> Preetam,
Yes, to offer system accounts open outside is a security risk. Normally sysadmins solve this by setting the login shells to /dev/null.
I would prefer /bin/false Or better, write a little Program /bin/falselogin which is doing the same as /bin/false but aditionally logging Time, UID, GID, PID, ps -ef and network Status ;-)) (Could do some sleep 1000 too ;->=> ) You should _not_ read any Parameters. (like GNU false --help :-/) /dev/null is no executable and will result in some obscure error Messages :-/. Btw. most modern Xploits don`t use the login shell. But every closed door is a good door. Dirk TRIA IT-consulting GmbH Joseph-Wild-Straße 20 81829 München Germany Tel: +49 (89) 92907-0 Fax: +49 (89) 92907-100 http://www.tria.de -------------------------------------------------------- working hard | for your success -------------------------------------------------------- Registergericht München HRB 113466 USt.-IdNr. DE 180017238 Steuer-Nr. 802/40600 Geschäftsführer: Richard Hofbauer kaufm. Geschäftsleitung: Rosa Igl -------------------------------------------------------- Nachricht von: Dirk.Schreiner@tria.de Nachricht an: suse-security@suse.com # Dateianhänge: 0 Die Mitteilung dieser E-Mail ist vertraulich und nur für den oben genannten Empfänger bestimmt. Wenn Sie nicht der vorgesehene Empfänger dieser E-Mail oder mit der Aushändigung an ihn betraut sind, weisen wir darauf hin, daß jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung sowie Weitergabe des Inhalts untersagt ist. Wir bitten Sie uns in diesem Fall umgehend zu unterrichten. Vielen Dank The information contained in this E-Mail is privileged and confidental intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient or competent to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this E-Mail is strictly prohibited. If you have received this E-Mail in error, please notify us immediately. Thank you -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
participants (4)
-
Dirk Schreiner
-
Jose_Thomas@Dell.com
-
Preetam Ramakrishna
-
Ralph Seichter