Uwe Hermann <[EMAIL PROTECTED]> writes:
> On Fri, May 05, 2006 at 11:12:35AM +0300, Jari Aalto wrote:
>> > The rest of the system accounts are happily running with /bin/false
>>
>> There is now /bin/nologin which is more secure
>
> I think you mean /usr/sbin/nologin, right? Please define "more sec
On 8 May 2006, Marc Haber outgrape:
> On Fri, 05 May 2006 11:12:35 +0300, Jari Aalto
> <[EMAIL PROTECTED]>
> wrote:
>> Richard A Nelson <[EMAIL PROTECTED]> writes:
>>> On Wed, 3 May 2006, Colin Watson wrote:
>>> The rest of the system accounts are happily running with
>>> /bin/false
>>
>> There is
On Mon, May 08, 2006 at 01:36:14AM +0200, Uwe Hermann wrote:
>
> Or does such a thing already exist?
Not that I know of, such a report might be interesting...
Regards
Javier
signature.asc
Description: Digital signature
On Mon, May 08, 2006 at 09:04:35AM +0200, Marc Haber wrote:
> On Fri, 05 May 2006 11:12:35 +0300, Jari Aalto <[EMAIL PROTECTED]>
> wrote:
> >Richard A Nelson <[EMAIL PROTECTED]> writes:
> >> On Wed, 3 May 2006, Colin Watson wrote:
> >> The rest of the system accounts are happily running with /bin/f
On Mon, May 08, 2006 at 12:47:53PM +0100, Thiemo Seufer wrote:
> So you expect systems to become exploitable by mounting /usr as noexec
> when they provide some /usr/bin/foo shell?
Not actually "expect", but I would not be _that_ suprised. Most programs
that care about the login shell tend to run
Gabor Gombas wrote:
> On Mon, May 08, 2006 at 11:53:15AM +0100, Thiemo Seufer wrote:
>
> > Such a binary is completely broken, and it would fail in a similiar way
> > for any sort of file it has no execute permission for, not only for
> > $SHELL.
>
> Sure, but that does not change the fact that i
On Mon, May 08, 2006 at 11:53:15AM +0100, Thiemo Seufer wrote:
> Such a binary is completely broken, and it would fail in a similiar way
> for any sort of file it has no execute permission for, not only for
> $SHELL.
Sure, but that does not change the fact that it is a failure path that
is usuall
Gabor Gombas wrote:
> On Mon, May 08, 2006 at 10:00:42AM +0100, Thiemo Seufer wrote:
>
> > > You can surely explain why /bin/nologin is more secure than
> > > /bin/false. I'm eager to learn.
> >
> > I am curious why any of both would be more secure than /dev/null, a
> > place which makes it hard
On Mon, May 08, 2006 at 10:00:42AM +0100, Thiemo Seufer wrote:
> > You can surely explain why /bin/nologin is more secure than
> > /bin/false. I'm eager to learn.
>
> I am curious why any of both would be more secure than /dev/null, a
> place which makes it hard to smuggle an infected binary into
Marc Haber wrote:
> On Fri, 05 May 2006 11:12:35 +0300, Jari Aalto <[EMAIL PROTECTED]>
> wrote:
> >Richard A Nelson <[EMAIL PROTECTED]> writes:
> >> On Wed, 3 May 2006, Colin Watson wrote:
> >> The rest of the system accounts are happily running with /bin/false
> >
> >There is now /bin/nologin whic
On Fri, 05 May 2006 11:12:35 +0300, Jari Aalto <[EMAIL PROTECTED]>
wrote:
>Richard A Nelson <[EMAIL PROTECTED]> writes:
>> On Wed, 3 May 2006, Colin Watson wrote:
>> The rest of the system accounts are happily running with /bin/false
>
>There is now /bin/nologin which is more secure
You can surely
Hi,
thanks for the pointers, I'll read the old discussions ASAP...
On Wed, May 03, 2006 at 01:48:33PM +0200, Javier Fernández-Sanguino Peña wrote:
> AFAIK, this is already being done in Red Hat, SuSE, FreeBSD and OpenBSD for
> many system users.
I'm currently installing tons of distributions on
Hi,
On Fri, May 05, 2006 at 11:12:35AM +0300, Jari Aalto wrote:
> > The rest of the system accounts are happily running with /bin/false
>
> There is now /bin/nologin which is more secure
I think you mean /usr/sbin/nologin, right? Please define "more secure"
in this context.
Uwe.
--
Uwe Herman
Richard A Nelson <[EMAIL PROTECTED]> writes:
> On Wed, 3 May 2006, Colin Watson wrote:
>
>
> The rest of the system accounts are happily running with /bin/false
>
There is now /bin/nologin which is more secure
Jari
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe".
On Wed, May 03, 2006 at 01:48:33PM +0200, Javier Fernández-Sanguino Peña wrote:
>
> In any case, you could use noshell (already available in Debian) or nologin
> (see #298782) instead of /bin/false.
nologin is now distributed with login.
I've closed the ITP.
Kind Regards,
--
Nekral
--
To UNS
On Wed, May 03, 2006 at 02:45:56AM +0200, Uwe Hermann wrote:
> Security-wise it's probably a good idea to give as few users as possible
> a valid shell, all others should get /bin/false, right?
AFAIK, this is already being done in Red Hat, SuSE, FreeBSD and OpenBSD for
many system users. And is th
On May 03, Uwe Hermann <[EMAIL PROTECTED]> wrote:
> I get tons of warnings like this when I run tiger(8):
Tools like this need to generate lots of warnings or people may start
thinking that they are useless...
> Security-wise it's probably a good idea to give as few users as possible
> a valid sh
On Wed, 3 May 2006, Colin Watson wrote:
On Wed, May 03, 2006 at 02:45:56AM +0200, Uwe Hermann wrote:
this may be a dumb question, but I really wonder if there's a policy
(which I obviously haven't found) about which system users should get
a valid shell and which shouldn't.
Yeah, I had the sa
On Wed, May 03, 2006 at 02:45:56AM +0200, Uwe Hermann wrote:
> this may be a dumb question, but I really wonder if there's a policy
> (which I obviously haven't found) about which system users should get
> a valid shell and which shouldn't.
This is bug #330882, and is basically because I'm excepti
Hi,
this may be a dumb question, but I really wonder if there's a policy
(which I obviously haven't found) about which system users should get
a valid shell and which shouldn't.
I get tons of warnings like this when I run tiger(8):
NEW: --WARN-- [pass014w] Login (bin) is disabled, but has a vali
20 matches
Mail list logo
