I have packaged a version of titan's tools (noshell+runas). Does anyone
wants to test them?
Regards
Javi
signature.asc
Description: Digital signature
I have packaged a version of titan's tools (noshell+runas). Does anyone
wants to test them?
Regards
Javi
signature.asc
Description: Digital signature
Russell Coker said:
Which goes back to my previous question, what do you think it should
have as the home directory then?
/etc/nohome, or something similar*. Somewhere where I can say There should
be no files in that directory, because it's the home directory for disabled
accounts.
It should
On Mon, Oct 27, 2003 at 07:03:13AM -0500, Joe Moore wrote:
/etc/nohome, or something similar*. Somewhere where I can say There should
be no files in that directory, because it's the home directory for disabled
accounts.
It should also be owned by root, permissions 1555. It is optional to
Russell Coker said:
Which goes back to my previous question, what do you think it should
have as the home directory then?
/etc/nohome, or something similar*. Somewhere where I can say There should
be no files in that directory, because it's the home directory for disabled
accounts.
It should
On Mon, Oct 27, 2003 at 07:03:13AM -0500, Joe Moore wrote:
/etc/nohome, or something similar*. Somewhere where I can say There should
be no files in that directory, because it's the home directory for disabled
accounts.
It should also be owned by root, permissions 1555. It is optional to
On Friday October 24 2003 02:33, Javier Fernández-Sanguino Peña wrote:
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.
On Friday October 24 2003 02:33, Javier Fernández-Sanguino Peña wrote:
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.
Bernd Eckenfels said:
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
Russell Coker said:
On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
I guess what I'm saying is that there are just as many ways to get
access to UID2 with bin:x:2:2:bin:/bin:/bin/false in the
/etc/passwd. As there are with bin:x:2:2:bin:/bin:/bin/sh.
(And bin:*: in /etc/shadow. I left that out,
Russell Coker said:
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
Russell Coker said:
On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
* A more important consideration is the location of bin's $HOME.
What's wrong with the current location?
At the moment, nothing. Since write access to /bin pretty much 0wns
the box. But a .rhosts file (+) in /bin might not
On Sat, 25 Oct 2003 02:40, Joe Moore wrote:
So there was a bug in the PAM code so that it ignored an invalid
/etc/passwd field. Why would the next bug not ignore some other
/etc/passwd field (like the user's chosen shell)?
You are correct, the next time a problem is discovered in PAM
On Sat, 25 Oct 2003 02:46, Joe Moore wrote:
To create a file in /bin you need root access. Therefore to create
/bin/.rhosts you need more access than such a file will grant. There
is no point in such an attack. Why would someone create /bin/.rhosts
when they can create /root/.rhosts?
In article [EMAIL PROTECTED] you wrote:
/bin/login uses all the fields in /etc/passwd (and some in /etc/shadow) to
determine:
and ftp uses /etc/shells.
Gruss
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
--
To UNSUBSCRIBE, email to [EMAIL
Bernd Eckenfels said:
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
Russell Coker said:
On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
I guess what I'm saying is that there are just as many ways to get
access to UID2 with bin:x:2:2:bin:/bin:/bin/false in the
/etc/passwd. As there are with bin:x:2:2:bin:/bin:/bin/sh.
(And bin:*: in /etc/shadow. I left that out,
Russell Coker said:
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
Russell Coker said:
On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
* A more important consideration is the location of bin's $HOME.
What's wrong with the current location?
At the moment, nothing. Since write access to /bin pretty much 0wns
the box. But a .rhosts file (+) in /bin might not
On Sat, 25 Oct 2003 02:40, Joe Moore wrote:
So there was a bug in the PAM code so that it ignored an invalid
/etc/passwd field. Why would the next bug not ignore some other
/etc/passwd field (like the user's chosen shell)?
You are correct, the next time a problem is discovered in PAM
On Sat, 25 Oct 2003 02:46, Joe Moore wrote:
To create a file in /bin you need root access. Therefore to create
/bin/.rhosts you need more access than such a file will grant. There
is no point in such an attack. Why would someone create /bin/.rhosts
when they can create /root/.rhosts?
In article [EMAIL PROTECTED] you wrote:
/bin/login uses all the fields in /etc/passwd (and some in /etc/shadow) to
determine:
and ftp uses /etc/shells.
Gruss
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
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
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
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
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
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
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
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
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
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
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
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
'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
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
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
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 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
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
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
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
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 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
84 matches
Mail list logo
