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
Is there a reason why Debian chooses to specify /bin/sh for system
don't know.
accounts? Do we risk breaking anything if we perform an
s/\/bin\/sh$/\/bin\/false/ ?
Yes, you'll run into trouble trying to run cronjobs as those system users,
also su user -c command won't work, you'll need to
On Wed, 22 Oct 2003 09:53:10 +0200
Dariush Pietrzak [EMAIL PROTECTED] wrote:
Is there a reason why Debian chooses to specify /bin/sh for system
don't know.
accounts? Do we risk breaking anything if we perform an
s/\/bin\/sh$/\/bin\/false/ ?
Yes, you'll run into trouble trying to
Dariush Pietrzak wrote:
accounts? Do we risk breaking anything if we perform an
s/\/bin\/sh$/\/bin\/false/ ?
Yes, you'll run into trouble trying to run cronjobs as those system users,
No, cron jobs work just fine. I've got a user named 'mirror' with
/bin/true as shell and it performs FTP
unsubscribe
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
'su -s /bin/bash -c cmd user '
sounds like a very bs argument
Do you understand the term 'breakage' ?
How about the idea that changing something in the system may force to you
to rewrite parts of code?
--
Dariush Pietrzak,
Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC
On Wed, 22 Oct 2003 19:27, Dariush Pietrzak wrote:
'su -s /bin/bash -c cmd user '
sounds like a very bs argument
Do you understand the term 'breakage' ?
Do you understand the term testing?
How about the idea that changing something in the system may force to you
to rewrite parts of
resend, to list this time
On Wed, 22 Oct 2003 11:27:54 +0200
Dariush Pietrzak [EMAIL PROTECTED] wrote:
'su -s /bin/bash -c cmd user '
sounds like a very bs argument
Do you understand the term 'breakage' ?
How about the idea that changing something in the system may force to
you to
On Wed, Oct 22, 2003 at 07:41:33PM +1000, Russell Coker wrote:
We can start with bin, daemon, sys, and sync which are the least
likely accounts to need a login shell. After those changes have been tested
to everyone's satisfaction we can then move on to others.
why not deny those accounts
On Wed, Oct 22, 2003 at 07:41:33PM +1000, Russell Coker wrote:
On Wed, 22 Oct 2003 19:27, Dariush Pietrzak wrote:
'su -s /bin/bash -c cmd user '
sounds like a very bs argument
Do you understand the term 'breakage' ?
Do you understand the term testing?
Why should I?
The question
I.R.van Dongen wrote:
If the shells are changed, there are some really big consequences, but
Such as? Please share your knowledge. :-)
Cheers,
Tobias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Wed, Oct 22, 2003 at 07:13:33PM +1000, Russell Coker wrote:
Having a valid shell all the time because it might be needed at some time is
not a good idea.
I recall that there was a bug in pam in unstable at one time that would allow
logging in to those accounts. Setting the shells to
On Wed, 22 Oct 2003 20:00, Dariush Pietrzak wrote:
Do you understand the term 'breakage' ?
Do you understand the term testing?
Why should I?
Because some of us have already performed extensive tests on this when it was
raised previously.
The idea of giving non-login accounts a shell
Dariush Pietrzak wrote:
'su -s /bin/bash -c cmd user '
sounds like a very bs argument
Do you understand the term 'breakage' ?
How about the idea that changing something in the system may force to you
to rewrite parts of code?
Hence my original question. OK, it doesn't break cron, it does break
On Wed, 22 Oct 2003 12:15:55 +0200
Tobias Reckhard [EMAIL PROTECTED] wrote:
I.R.van Dongen wrote:
If the shells are changed, there are some really big consequences,
but
Such as? Please share your knowledge. :-)
- manually compiled postgresql (user:postgres) expects the user it runs
as to
On Wed, 22 Oct 2003 21:37, I.R.van Dongen wrote:
If the shells are changed, there are some really big consequences,
but
Such as? Please share your knowledge. :-)
- manually compiled postgresql (user:postgres) expects the user it runs
as to have a valid shell (I'm not sure about the
Russell Coker said:
The idea of giving non-login accounts a shell of /bin/false is hardly
new.
Out of curiosity, what security benefit does a shell of /bin/false grant,
that say, an encrypted password of NOLOGIN (or equivalently *) does not
grant?
In what circumstances would a process be
Hi,
I must have the acl support for Reiserfs, the only source of patch found
was on the ftp of suse, I use them
Until now, I was able to use ACL on ext3 fs but with a reiserfs
partition, I get Operation not supported when I try to modify the ACL
of a file
Can someone help me?
Regards
--
To
Fulop Andras Peter
Rendszergazda
Miskolci Egyetem Szamitokozpont
[36]-(46)-565-111/16-27
###
Ezt a levelet az F-Secure Anti-Virus for Internet Mail ellenõrizte.
Miskolci Egyetem Számítóközpont
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Package: gdm
Version: 2.4.1.6-2
Severity: important
Tags: security
Security bug reported for about a week and not yet fixed in Debian ...
Fixed in gdm 2.4.4.4 :
http://www.gnome.org/project/shownotes.php?release_id=2355
- SECURITY: Fixed CAN-2003-0793, a local DoS, the socket connection
is
On Wed, 22 Oct 2003 20:39, Joe Moore wrote:
Russell Coker said:
The idea of giving non-login accounts a shell of /bin/false is hardly
new.
Out of curiosity, what security benefit does a shell of /bin/false grant,
that say, an encrypted password of NOLOGIN (or equivalently *) does not
Package: gdm
Version: 2.4.1.6-2
Severity: important
Tags: security
A second security bug that need to be closed, fixed in gdm 2.4.4.4 upstream for about
one week (and on others distribs too, is the GDM maintainer taking care of this
package ?) :
Russell Coker wrote:
We can start with bin, daemon, sys, and sync which are the least
likely accounts to need a login shell.
Er, the only known point of the sync user is to give it a login
shell.
sync:x:4:65534:sync:/bin:/bin/sync
--
see shy jo
signature.asc
Description: Digital signature
In article [EMAIL PROTECTED] you wrote:
We can start with bin, daemon, sys, and sync which are the least
likely accounts to need a login shell. After those changes have been tested
to everyone's satisfaction we can then move on to others.
I dont know what your login shell for sync is, I
In article [EMAIL PROTECTED] you wrote:
Out of curiosity, what security benefit does a shell of /bin/false grant,
that say, an encrypted password of NOLOGIN (or equivalently *) does not
grant?
Two things, first it is more obvious from reading the password file (and
therefore also avoids
UNSUBSCRIBE
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Wed, Oct 22, 2003 at 02:02:25PM -0400, Joe Moore wrote:
The similarities:
--
ro /usr:
Blocks certain types of automated trojan horse/virus attacks
Can't stop an intruder that can run mount -o remount,rw /usr as root
Can be worked around for short tasks by the
Bernd Eckenfels said:
In article [EMAIL PROTECTED]
you wrote:
Out of curiosity, what security benefit does a shell of /bin/false
grant, that say, an encrypted password of NOLOGIN (or equivalently
*) does not grant?
Two things, first it is more obvious from reading the password file
(and
Reading:
In article [EMAIL PROTECTED] you wrote:
The /etc/passwd file does not control granting of priveledges[sic].
and
It contains a map of UID - username - Primary GID
is a contradiction on traditional unix, since the most powerful priveledge
is coupled with uid 0.
And the priveledge
On Wed, Oct 22, 2003 at 05:36:42PM +0200, Sebastien Bacher wrote:
Package: gdm
Version: 2.4.1.6-2
Severity: important
Tags: security
A second security bug that need to be closed, fixed in gdm 2.4.4.4 upstream for
about one week (and on others distribs too, is the GDM maintainer taking
On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
There was a case of a buggy pam some time ago which let people login to
accounts such as man and bin. Changing the shell would have
prevented that problem (or limited the number of accounts that were
vulnerable)
So there was a bug in the PAM
In article [EMAIL PROTECTED] you wrote:
Does bin even own ANY files or have write access to ANY directories on a
default install? From a quick look it seems that account bin gets no write
access to anything on a Linux system.
not allowed by policy, thats why i hate that account.
Greetings
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
Is there a reason why Debian chooses to specify /bin/sh for system
don't know.
accounts? Do we risk breaking anything if we perform an
s/\/bin\/sh$/\/bin\/false/ ?
Yes, you'll run into trouble trying to run cronjobs as those system users,
also su user -c command won't work, you'll need to
On Wed, 22 Oct 2003 09:53:10 +0200
Dariush Pietrzak [EMAIL PROTECTED] wrote:
Is there a reason why Debian chooses to specify /bin/sh for system
don't know.
accounts? Do we risk breaking anything if we perform an
s/\/bin\/sh$/\/bin\/false/ ?
Yes, you'll run into trouble trying to
Dariush Pietrzak wrote:
accounts? Do we risk breaking anything if we perform an
s/\/bin\/sh$/\/bin\/false/ ?
Yes, you'll run into trouble trying to run cronjobs as those system users,
No, cron jobs work just fine. I've got a user named 'mirror' with
/bin/true as shell and it performs FTP
unsubscribe
On Wed, 22 Oct 2003 18:50, Tobias Reckhard wrote:
also su user -c command won't work, you'll need to use sudo or suid bit,
and that's a bit messy.
This is true, when I need to su to this user's account (for
troubleshooting, usually), I need to 'chsh -s /bin/bash mirror' first
(and change
'su -s /bin/bash -c cmd user '
sounds like a very bs argument
Do you understand the term 'breakage' ?
How about the idea that changing something in the system may force to you
to rewrite parts of code?
--
Dariush Pietrzak,
Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC
On Wed, 22 Oct 2003 19:27, Dariush Pietrzak wrote:
'su -s /bin/bash -c cmd user '
sounds like a very bs argument
Do you understand the term 'breakage' ?
Do you understand the term testing?
How about the idea that changing something in the system may force to you
to rewrite parts of
resend, to list this time
On Wed, 22 Oct 2003 11:27:54 +0200
Dariush Pietrzak [EMAIL PROTECTED] wrote:
'su -s /bin/bash -c cmd user '
sounds like a very bs argument
Do you understand the term 'breakage' ?
How about the idea that changing something in the system may force to
you to
On Wed, Oct 22, 2003 at 07:41:33PM +1000, Russell Coker wrote:
We can start with bin, daemon, sys, and sync which are the least
likely accounts to need a login shell. After those changes have been tested
to everyone's satisfaction we can then move on to others.
why not deny those accounts
On Wed, Oct 22, 2003 at 07:41:33PM +1000, Russell Coker wrote:
On Wed, 22 Oct 2003 19:27, Dariush Pietrzak wrote:
'su -s /bin/bash -c cmd user '
sounds like a very bs argument
Do you understand the term 'breakage' ?
Do you understand the term testing?
Why should I?
The question
I.R.van Dongen wrote:
If the shells are changed, there are some really big consequences, but
Such as? Please share your knowledge. :-)
Cheers,
Tobias
On Wed, Oct 22, 2003 at 07:13:33PM +1000, Russell Coker wrote:
Having a valid shell all the time because it might be needed at some time is
not a good idea.
I recall that there was a bug in pam in unstable at one time that would allow
logging in to those accounts. Setting the shells to
On Wed, 22 Oct 2003 20:00, Dariush Pietrzak wrote:
Do you understand the term 'breakage' ?
Do you understand the term testing?
Why should I?
Because some of us have already performed extensive tests on this when it was
raised previously.
The idea of giving non-login accounts a shell
Dariush Pietrzak wrote:
'su -s /bin/bash -c cmd user '
sounds like a very bs argument
Do you understand the term 'breakage' ?
How about the idea that changing something in the system may force to you
to rewrite parts of code?
Hence my original question. OK, it doesn't break cron, it does
On Wed, 22 Oct 2003 12:15:55 +0200
Tobias Reckhard [EMAIL PROTECTED] wrote:
I.R.van Dongen wrote:
If the shells are changed, there are some really big consequences,
but
Such as? Please share your knowledge. :-)
- manually compiled postgresql (user:postgres) expects the user it runs
as to
On Wed, 22 Oct 2003 21:37, I.R.van Dongen wrote:
If the shells are changed, there are some really big consequences,
but
Such as? Please share your knowledge. :-)
- manually compiled postgresql (user:postgres) expects the user it runs
as to have a valid shell (I'm not sure about the
Hi,
I must have the acl support for Reiserfs, the only source of patch found
was on the ftp of suse, I use them
Until now, I was able to use ACL on ext3 fs but with a reiserfs
partition, I get Operation not supported when I try to modify the ACL
of a file
Can someone help me?
Regards
Russell Coker said:
The idea of giving non-login accounts a shell of /bin/false is hardly
new.
Out of curiosity, what security benefit does a shell of /bin/false grant,
that say, an encrypted password of NOLOGIN (or equivalently *) does not
grant?
In what circumstances would a process be
Fulop Andras Peter
Rendszergazda
Miskolci Egyetem Szamitokozpont
[36]-(46)-565-111/16-27
###
Ezt a levelet az F-Secure Anti-Virus for Internet Mail ellenõrizte.
Miskolci Egyetem Számítóközpont
Package: gdm
Version: 2.4.1.6-2
Severity: important
Tags: security
Security bug reported for about a week and not yet fixed in Debian ...
Fixed in gdm 2.4.4.4 :
http://www.gnome.org/project/shownotes.php?release_id=2355
- SECURITY: Fixed CAN-2003-0793, a local DoS, the socket connection
is
Package: gdm
Version: 2.4.1.6-2
Severity: important
Tags: security
A second security bug that need to be closed, fixed in gdm 2.4.4.4 upstream for
about one week (and on others distribs too, is the GDM maintainer taking care
of this package ?) :
Russell Coker wrote:
We can start with bin, daemon, sys, and sync which are the least
likely accounts to need a login shell.
Er, the only known point of the sync user is to give it a login
shell.
sync:x:4:65534:sync:/bin:/bin/sync
--
see shy jo
signature.asc
Description: Digital signature
On Wed, 22 Oct 2003 20:39, Joe Moore wrote:
Russell Coker said:
The idea of giving non-login accounts a shell of /bin/false is hardly
new.
Out of curiosity, what security benefit does a shell of /bin/false grant,
that say, an encrypted password of NOLOGIN (or equivalently *) does not
In article [EMAIL PROTECTED] you wrote:
We can start with bin, daemon, sys, and sync which are the least
likely accounts to need a login shell. After those changes have been tested
to everyone's satisfaction we can then move on to others.
I dont know what your login shell for sync is, I
In article [EMAIL PROTECTED] you wrote:
Out of curiosity, what security benefit does a shell of /bin/false grant,
that say, an encrypted password of NOLOGIN (or equivalently *) does not
grant?
Two things, first it is more obvious from reading the password file (and
therefore also avoids
Russell Coker said:
On Wed, 22 Oct 2003 20:39, Joe Moore wrote:
Russell Coker said:
The idea of giving non-login accounts a shell of /bin/false is
hardly new.
Out of curiosity, what security benefit does a shell of /bin/false
grant, that say, an encrypted password of NOLOGIN (or
Bernd Eckenfels said:
In article [EMAIL PROTECTED]
you wrote:
Out of curiosity, what security benefit does a shell of /bin/false
grant, that say, an encrypted password of NOLOGIN (or equivalently
*) does not grant?
Two things, first it is more obvious from reading the password file
(and
UNSUBSCRIBE
On Wed, Oct 22, 2003 at 02:02:25PM -0400, Joe Moore wrote:
The similarities:
--
ro /usr:
Blocks certain types of automated trojan horse/virus attacks
Can't stop an intruder that can run mount -o remount,rw /usr as root
Can be worked around for short tasks by the
Reading:
In article [EMAIL PROTECTED] you wrote:
The /etc/passwd file does not control granting of priveledges[sic].
and
It contains a map of UID - username - Primary GID
is a contradiction on traditional unix, since the most powerful priveledge
is coupled with uid 0.
And the priveledge
On Wed, Oct 22, 2003 at 05:36:42PM +0200, Sebastien Bacher wrote:
Package: gdm
Version: 2.4.1.6-2
Severity: important
Tags: security
A second security bug that need to be closed, fixed in gdm 2.4.4.4 upstream
for about one week (and on others distribs too, is the GDM maintainer taking
On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
There was a case of a buggy pam some time ago which let people login to
accounts such as man and bin. Changing the shell would have
prevented that problem (or limited the number of accounts that were
vulnerable)
So there was a bug in the PAM
In article [EMAIL PROTECTED] you wrote:
Does bin even own ANY files or have write access to ANY directories on a
default install? From a quick look it seems that account bin gets no write
access to anything on a Linux system.
not allowed by policy, thats why i hate that account.
Greetings
66 matches
Mail list logo
