Tried the Titan noshell and it works as expected.
However, Tiger complains about it if you follow the CERT installation
procedure and "Register the noshell program as the valid login shell."
There's no need to do this, as noshell really doesn't care and still
works a non-valid shell.
[...]
NEW: --
* Ennio-Sr <[EMAIL PROTECTED]> [Thu, 23 Oct 2003 at 23:00 GMT]:
> Hi, everybody on the NG.
> 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
> [...]
Many thanks to all of you for the reassuring a
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 i
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
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
>> > v
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 (+)
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 discover
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/.r
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/
Tried the Titan noshell and it works as expected.
However, Tiger complains about it if you follow the CERT installation
procedure and "Register the noshell program as the valid login shell."
There's no need to do this, as noshell really doesn't care and still
works a non-valid shell.
[...]
NEW: --
* Ennio-Sr <[EMAIL PROTECTED]> [Thu, 23 Oct 2003 at 23:00 GMT]:
> Hi, everybody on the NG.
> 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
> [...]
Many thanks to all of you for the reassuring a
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 i
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
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
>> > v
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 (+)
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 discover
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/.r
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 PROT
18 matches
Mail list logo
