Why not use /bin/noshell? (was Re: Why do system users have valid shells)
On Wed, Oct 22, 2003 at 09:45:24AM +0200, Tobias Reckhard wrote: > Hi > > We recently noticed that a stock woody install produces an /etc/passwd > in which most, if not all, system users have a valid shell entry of > /bin/sh. They're all unable to login due to having no valid password, > but best UNIX security practice typically involves giving accounts that > don't need to be able to login a shell of /bin/false or /bin/true. Other > distros (at least some of them) appear to follow suit. I have meant to ask this question for some time too. Specially since some distributions (such as RedHat) provide system users with a /bin/noshell shell. I'm not sure if this is the same shell as the one provided by Titan [1] but IMHO I believe it's a must to have a shell that logs the entry attempt to syslog (as opposed to what /bin/false or /bin/true do). So, anybody knows any issues (Debian specific or not) related to using /bin/noshell instead? Regards Javi PS: I guess, as for recommended practice, you mean CERT's guidelines: http://www.cert.org/security-improvement/implementations/i049.02.html which does suggest using Titan's noshell [1] Titan's noshell can be found at: http://www.fish.com/titan/src1/noshell.c pgpJqi6NiO105.pgp Description: PGP signature
Re: Why not use /bin/noshell? (was Re: Why do system users have valid shells)
On Thu, Oct 23, 2003 at 12:52:19PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: > I have meant to ask this question for some time too. Specially since some > distributions (such as RedHat) provide system users with a /bin/noshell > shell. I'm not sure if this is the same shell as the one provided by Titan > [1] but IMHO I believe it's a must to have a shell that logs the entry > attempt to syslog (as opposed to what /bin/false or /bin/true do). If one isn't available, they are damn easy to write. I've probably got source laying around somewhere for one I wrote for NeXT's about a decade ago.
Squid package containing buffer overrun ??
I'm just sending this out as a 'request for comment' really -- I notice debian-stable has a package for squid which (besides being security-updated already) still has a known buffer overflow in it (although it is apparently of 'unknown risk'). See: http://www.squid-cache.org/Versions/v2/2.4/bugs/#squid-2.4.STABLE7-url_escape I reported this and was told that it was considered 'not important' and would be sorted out when other things had been sorted out... I wonder if this has been found to be really non-vulnerable or if debian policy doesn't normally allow things to be updated unless a vulnerability has been proved to really exist?? I'm confused and would like to know what others think! -enyc <[EMAIL PROTECTED]>
Re: Why not use /bin/noshell? (was Re: Why do system users have valid shells)
Try the package "falselogin" micah Javier Fern?ndez-Sanguino Pe?a schrieb am Thursday, den 23. October 2003: > On Wed, Oct 22, 2003 at 09:45:24AM +0200, Tobias Reckhard wrote: > > Hi > > > > We recently noticed that a stock woody install produces an /etc/passwd > > in which most, if not all, system users have a valid shell entry of > > /bin/sh. They're all unable to login due to having no valid password, > > but best UNIX security practice typically involves giving accounts that > > don't need to be able to login a shell of /bin/false or /bin/true. Other > > distros (at least some of them) appear to follow suit. > > I have meant to ask this question for some time too. Specially since some > distributions (such as RedHat) provide system users with a /bin/noshell > shell. I'm not sure if this is the same shell as the one provided by Titan > [1] but IMHO I believe it's a must to have a shell that logs the entry > attempt to syslog (as opposed to what /bin/false or /bin/true do). > > So, anybody knows any issues (Debian specific or not) related to using > /bin/noshell instead? > > Regards > > Javi > > PS: I guess, as for recommended practice, you mean CERT's guidelines: > http://www.cert.org/security-improvement/implementations/i049.02.html > which does suggest using Titan's noshell > > > [1] Titan's noshell can be found at: > http://www.fish.com/titan/src1/noshell.c pgp208hc7G1Ft.pgp Description: PGP signature
Re: Why not use /bin/noshell? (was Re: Why do system users have valid shells)
On Thu, Oct 23, 2003 at 10:35:26AM -0500, Micah Anderson wrote: > Try the package "falselogin" > That's not what I was looking for. I was looking for something that logged connection attempts, which falselogin does not. Regards Javi pgpvmmHktDV88.pgp Description: PGP signature
Re: Why not use /bin/noshell? (was Re: Why do system users have valid shells)
On Thu, Oct 23, 2003 at 12:57:53PM +0100, Dale Amon wrote: > If one isn't available, they are damn easy to write. I've > probably got source laying around somewhere for one I wrote > for NeXT's about a decade ago. Well, Titan's noshell source code is available, I'm not sure if it's license is DFSG-free. RedHat's noshell probably is but I cannot find which package holds the source code (anyone?) Regards Javi
Securetty: limits root login while allowing 'su -'
Hi, everybody on the NG. This is my first post here and I hope it won't be the last one too :-) [Using Debian/Woody-3.0 on knl 2.2.22 on a home PC.] I limited root login to two ttys only (in /etc/securetty) but yesterday I discovered I could 'su -' to root in the excluded ttys. Do you think this is normal behaviour or does my system need re-configuration ? Thanks for your attention. Regards, Ennio -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ] (°|°) [Why to use Win$ozz (I say) if ... "even a fool can do that. )=( Do something you aren't good at!" (used to say Henry Miller) ] Ennio. (Please change . for .dot. and @ for .at. in my Reply-To) -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo.\\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ](°|°) Ennio. (Please change . for .dot. and @ for .at. in my Reply-To) )=(
Re: Securetty: limits root login while allowing 'su -'
On Thu, Oct 23, 2003 at 10:13:16PM +, Ennio-Sr wrote: > I limited root login to two ttys only (in /etc/securetty) but yesterday > I discovered I could 'su -' to root in the excluded ttys. Do you think > this is normal behaviour Yes. | [EMAIL PROTECTED]:/etc/pam.d# grep securetty * | login:# Disallows root logins except on tty's listed in /etc/securetty | login:auth requisite pam_securetty.so | [EMAIL PROTECTED]:/etc/pam.d# You could try adding this line to the file and see what happens: | auth requisite pam_securetty.so Just make sure you can get to root in a way other than the command if things break. -- Tom Goulet mail: [EMAIL PROTECTED] UID0 Unix Consultingweb: em.ca/uid0/
Re: Securetty: limits root login while allowing 'su -'
In article <[EMAIL PROTECTED]> you wrote: > I discovered I could 'su -' to root in the excluded ttys. Do you think > this is normal behaviour or does my system need re-configuration ? This is the intended normal behaviour. Idea behind it is to avoid random admins logging into the system as root so they are not trackable. If the login as non root and use su, they at least are visible in last. I think you could, however add "auth requisite pam_securetty.so" to /etc/pam.d/su, but havent tried. Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/
Re: Securetty: limits root login while allowing 'su -'
On Fri, 24 Oct 2003 10:50, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > I discovered I could 'su -' to root in the excluded ttys. Do you think > > this is normal behaviour or does my system need re-configuration ? > > This is the intended normal behaviour. Idea behind it is to avoid random > admins logging into the system as root so they are not trackable. If the > login as non root and use su, they at least are visible in last. I think that the idea is to prevent password guessing. If an attacker successfully logs in as root then in 99.9% of cases they can remove any log entries showing how they did it. If the user knows that they can't just login as root then they have to su from their own account, which means that their attempts are logged and appropriate action can be taken long before they guess the right password. > I think you could, however add "auth requisite pam_securetty.so" to > /etc/pam.d/su, but havent tried. Another possibility is pam_wheel.so... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Why not use /bin/noshell? (was Re: Why do system users have valid shells)
On Wed, Oct 22, 2003 at 09:45:24AM +0200, Tobias Reckhard wrote: > Hi > > We recently noticed that a stock woody install produces an /etc/passwd > in which most, if not all, system users have a valid shell entry of > /bin/sh. They're all unable to login due to having no valid password, > but best UNIX security practice typically involves giving accounts that > don't need to be able to login a shell of /bin/false or /bin/true. Other > distros (at least some of them) appear to follow suit. I have meant to ask this question for some time too. Specially since some distributions (such as RedHat) provide system users with a /bin/noshell shell. I'm not sure if this is the same shell as the one provided by Titan [1] but IMHO I believe it's a must to have a shell that logs the entry attempt to syslog (as opposed to what /bin/false or /bin/true do). So, anybody knows any issues (Debian specific or not) related to using /bin/noshell instead? Regards Javi PS: I guess, as for recommended practice, you mean CERT's guidelines: http://www.cert.org/security-improvement/implementations/i049.02.html which does suggest using Titan's noshell [1] Titan's noshell can be found at: http://www.fish.com/titan/src1/noshell.c pgp0.pgp Description: PGP signature
Re: Why not use /bin/noshell? (was Re: Why do system users have valid shells)
On Thu, Oct 23, 2003 at 12:52:19PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: > I have meant to ask this question for some time too. Specially since some > distributions (such as RedHat) provide system users with a /bin/noshell > shell. I'm not sure if this is the same shell as the one provided by Titan > [1] but IMHO I believe it's a must to have a shell that logs the entry > attempt to syslog (as opposed to what /bin/false or /bin/true do). If one isn't available, they are damn easy to write. I've probably got source laying around somewhere for one I wrote for NeXT's about a decade ago. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Squid package containing buffer overrun ??
I'm just sending this out as a 'request for comment' really -- I notice debian-stable has a package for squid which (besides being security-updated already) still has a known buffer overflow in it (although it is apparently of 'unknown risk'). See: http://www.squid-cache.org/Versions/v2/2.4/bugs/#squid-2.4.STABLE7-url_escape I reported this and was told that it was considered 'not important' and would be sorted out when other things had been sorted out... I wonder if this has been found to be really non-vulnerable or if debian policy doesn't normally allow things to be updated unless a vulnerability has been proved to really exist?? I'm confused and would like to know what others think! -enyc <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why not use /bin/noshell? (was Re: Why do system users have valid shells)
Try the package "falselogin" micah Javier Fern?ndez-Sanguino Pe?a schrieb am Thursday, den 23. October 2003: > On Wed, Oct 22, 2003 at 09:45:24AM +0200, Tobias Reckhard wrote: > > Hi > > > > We recently noticed that a stock woody install produces an /etc/passwd > > in which most, if not all, system users have a valid shell entry of > > /bin/sh. They're all unable to login due to having no valid password, > > but best UNIX security practice typically involves giving accounts that > > don't need to be able to login a shell of /bin/false or /bin/true. Other > > distros (at least some of them) appear to follow suit. > > I have meant to ask this question for some time too. Specially since some > distributions (such as RedHat) provide system users with a /bin/noshell > shell. I'm not sure if this is the same shell as the one provided by Titan > [1] but IMHO I believe it's a must to have a shell that logs the entry > attempt to syslog (as opposed to what /bin/false or /bin/true do). > > So, anybody knows any issues (Debian specific or not) related to using > /bin/noshell instead? > > Regards > > Javi > > PS: I guess, as for recommended practice, you mean CERT's guidelines: > http://www.cert.org/security-improvement/implementations/i049.02.html > which does suggest using Titan's noshell > > > [1] Titan's noshell can be found at: > http://www.fish.com/titan/src1/noshell.c pgp0.pgp Description: PGP signature
Re: Why not use /bin/noshell? (was Re: Why do system users have valid shells)
On Thu, Oct 23, 2003 at 10:35:26AM -0500, Micah Anderson wrote: > Try the package "falselogin" > That's not what I was looking for. I was looking for something that logged connection attempts, which falselogin does not. Regards Javi pgp0.pgp Description: PGP signature
Re: Why not use /bin/noshell? (was Re: Why do system users have valid shells)
On Thu, Oct 23, 2003 at 12:57:53PM +0100, Dale Amon wrote: > If one isn't available, they are damn easy to write. I've > probably got source laying around somewhere for one I wrote > for NeXT's about a decade ago. Well, Titan's noshell source code is available, I'm not sure if it's license is DFSG-free. RedHat's noshell probably is but I cannot find which package holds the source code (anyone?) Regards Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Securetty: limits root login while allowing 'su -'
Hi, everybody on the NG. This is my first post here and I hope it won't be the last one too :-) [Using Debian/Woody-3.0 on knl 2.2.22 on a home PC.] I limited root login to two ttys only (in /etc/securetty) but yesterday I discovered I could 'su -' to root in the excluded ttys. Do you think this is normal behaviour or does my system need re-configuration ? Thanks for your attention. Regards, Ennio -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ] (°|°) [Why to use Win$ozz (I say) if ... "even a fool can do that. )=( Do something you aren't good at!" (used to say Henry Miller) ] Ennio. (Please change . for .dot. and @ for .at. in my Reply-To) -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo.\\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ](°|°) Ennio. (Please change . for .dot. and @ for .at. in my Reply-To) )=( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Securetty: limits root login while allowing 'su -'
On Thu, Oct 23, 2003 at 10:13:16PM +, Ennio-Sr wrote: > I limited root login to two ttys only (in /etc/securetty) but yesterday > I discovered I could 'su -' to root in the excluded ttys. Do you think > this is normal behaviour Yes. | [EMAIL PROTECTED]:/etc/pam.d# grep securetty * | login:# Disallows root logins except on tty's listed in /etc/securetty | login:auth requisite pam_securetty.so | [EMAIL PROTECTED]:/etc/pam.d# You could try adding this line to the file and see what happens: | auth requisite pam_securetty.so Just make sure you can get to root in a way other than the command if things break. -- Tom Goulet mail: [EMAIL PROTECTED] UID0 Unix Consultingweb: em.ca/uid0/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Securetty: limits root login while allowing 'su -'
In article <[EMAIL PROTECTED]> you wrote: > I discovered I could 'su -' to root in the excluded ttys. Do you think > this is normal behaviour or does my system need re-configuration ? This is the intended normal behaviour. Idea behind it is to avoid random admins logging into the system as root so they are not trackable. If the login as non root and use su, they at least are visible in last. I think you could, however add "auth requisite pam_securetty.so" to /etc/pam.d/su, but havent tried. Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Securetty: limits root login while allowing 'su -'
On Fri, 24 Oct 2003 10:50, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > I discovered I could 'su -' to root in the excluded ttys. Do you think > > this is normal behaviour or does my system need re-configuration ? > > This is the intended normal behaviour. Idea behind it is to avoid random > admins logging into the system as root so they are not trackable. If the > login as non root and use su, they at least are visible in last. I think that the idea is to prevent password guessing. If an attacker successfully logs in as root then in 99.9% of cases they can remove any log entries showing how they did it. If the user knows that they can't just login as root then they have to su from their own account, which means that their attempts are logged and appropriate action can be taken long before they guess the right password. > I think you could, however add "auth requisite pam_securetty.so" to > /etc/pam.d/su, but havent tried. Another possibility is pam_wheel.so... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
