Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Secure-Shell
[Top] [All Lists]

Re: Locking down ssh config in large env

Subject: Re: Locking down ssh config in large env
Date: Mon, 20 Sep 2004 18:43:29 -0400
General speaking, if you set the sticky bit (chmod +t) on a directory, only
the owner of a writable file in that directory or the owner of the
directory can delete the writable file.  This protects application files
that have to be writable by everyone but only one user should be able to
delete the files.

X-ClientAddr: 205.206.231.26
Mailing-List: contact secureshell-help@securityfocus.com; run by ezmlm
List-Post: <mailto:secureshell@securityfocus.com>
List-Help: <mailto:secureshell-help@securityfocus.com>
List-Unsubscribe: <mailto:secureshell-unsubscribe@securityfocus.com>
List-Subscribe: <mailto:secureshell-subscribe@securityfocus.com>
Delivered-To: mailing list secureshell@securityfocus.com
Delivered-To: moderator for secureshell@securityfocus.com
Date: Sun, 19 Sep 2004 19:14:12 +0900
From: Derek Martin <code@pizzashack.org>
To: secureshell@securityfocus.com
Subject: Re: Locking down ssh config in large env
Mail-Followup-To: secureshell@securityfocus.com
User-Agent: Mutt/1.5.6i
X-MailScanner-Information: Please contact imijit.net for more information
X-MailScanner: Found to be clean

On Mon, Sep 13, 2004 at 09:29:14AM -0400, Brett Anderson wrote:
Perhaps you could create the .ssh files for them, have the .ssh files
owned by another user(i.e. root), and don't give the end-user's write
privileges.

This is not sufficient.  If the user has write permission to their
.ssh directory, they can delete the files in it, and then replace them
with their own.  If the user has write access to their home directory,
the same applies to the entire .ssh directory.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D




<Prev in Thread] Current Thread [Next in Thread>