The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Zardoz 'Security Digest' - Archives (1989 - 1991)
DOCUMENT: Zardoz 'Security Digest' V1 #10 1989-02-17 (1 file, 1493 bytes)
NOTICE: recognises the rights of all third-party works.


Security Digest Volume 1 Issue 10


            security idea: make lost+found drwx------
            Re: fingerd
            Re: lock
            lock (Security Digest V1 #9)


Date: Fri, 17 Feb 89 18:40:52 -0800
From: uunet!okeeffe.Berkeley.EDU!bostic (Keith Bostic)
Subject: security idea: make lost+found drwx------

>      I'd like to bounce this off the rest of the list.  I suggest
> that all lost+found directories should be readable only by root
> as a security precaution.  It seems to me that if I have a
> readable file under a secure directory and it gets detached from
> the directory entry, it will be readable to everybody if fsck
> picks it off the floor.  Certainly, protecting the file itself is
> a good idea, but some people could be in for a surprise if their
> love.letters directory gets skrunched :-).

Good idea; we've added a flag to fsck, -m mode, allowing you to set
the mode on the lost+found directories fsck creates.


Date: Fri, 17 Feb 89 18:48:02 -0800
From: uunet!okeeffe.Berkeley.EDU!bostic (Keith Bostic)
Subject: Re: fingerd

> Aaaargghh! I was going to say that finger should also check that .plan
> and .project are owned by the person being fingered, but I couldn't
> come up with a reason why this would be necessary.
> Now, can I have my fingerd run as root, or is there still more to
> this? (No, I don't *have* to have my fingerd run as root).

This is too much effort.  Just have your fingerd run as a pseudo-user
with no special permissions.  End of problem.


Date: Fri, 17 Feb 89 18:48:02 -0800
From: uunet!okeeffe.Berkeley.EDU!bostic (Keith Bostic)
Subject: Re: lock

> The problem with always allowing a lock program to accept the root
> passwd follows.  We found that the root passwd is useful to break a lock
> running on an idle terminal (the user locked the terminal and left).
> However, consider the person who writes a highly similar lock program
> which also accepts the root passwd - but logs it.  The sysadmin doesn't
> even know that it happened, if done skillfully enough.

So what's the difference between that and writing a program that
simulates getty/login and just logs attempted login/password?  If
you have publicly available terminals lock isn't your problem.


Date: Fri, 17 Feb 89 23:28:53 EST
From: Bob Sutterfield <uunet!!bob>
Subject: lock (Security Digest V1 #9)

>From lock.1: accepts the password for root as an alternative to the one
   given by the user...

We had an xsecure here that had that behavior for a while.  A
lookalike was used to entice knowledgeable users to type the root
password, which was then of course stashed away (before encryption) in
the perpetrator's file just before the program exited, freeing the
machine hosting the X server to which it was directed.  That feature
was removed, and more modern xsecures are slightly more careful.

Accepting the root password is convenient for those who already know

the root password, but it is also convenient for those who would
prefer to enlarge that set.  We decided to sacrifice both

        End of Security Digest Volume 1 Issue 10