Re: Perforce client: security hole by design
- From: Crispin Cowan <crispin@xxxxxxxxxx>
- Date: Thu, 11 Jan 2007 11:27:50 -0800
Ben Bucksch wrote:
= Abstract =Eww :)
The Perforce client has a huge gapping security hole by design. It
totally trusts the Perforce server and does whatever the server tells
it, writing arbitrary files.
= Risk =You could use any of the security policy systems (AppArmor, SELinux,
Critical. The server has full access to *all* files that *any* of its
users has.
"We can trust the server" is not an appropriate answer:
* I am a contractor and have access to many companies' sources, and
I do *not* allow any company I work for to have full access to all
files on my computer, including the source of the all other
companies I work for and even personal files.
LIDS, etc.) to confine the client to be only able to access the files
you want it to have access to. I would argue that AppArmor is the
easiest tool to achieve that (but I'm biased) as it directly supports a
policy model of "this program gets to access these pathnames" e.g.
here's the confinement profile for ntpd:
/usr/sbin/ntpd {
#include <abstractions/base>
#include <abstractions/nameservice>
capability ipc_lock,
capability net_bind_service,
capability setgid,
capability setuid,
capability sys_chroot,
capability sys_resource,
capability sys_time,
/drift/ntp.drift rwl,
/drift/ntp.drift.TEMP rwl,
/etc/ntp.conf r,
/etc/ntp/drift* rwl,
/etc/ntp/keys r,
/etc/ntp/step-tickers r,
/tmp/ntp* rwl,
/usr/sbin/ntpd rmix,
/var/lib/ntp/etc/ntp.conf.iburst r,
/var/lib/ntp/drift rwl,
/var/lib/ntp/drift.TEMP rwl,
/var/lib/ntp/drift/ntp.drift r,
/var/lib/ntp/var/run/ntp/ntpd.pid w,
/var/log/ntp w,
/var/log/ntp.log w,
/var/run/ntpd.pid w,
}
AppArmor will also let you change the policy for a running process on
the fly, so you could edit the file and push the policy-reload button as
you move between one work site and another without even having to
restart your Perforce client. AppArmor is GPL and available for SUSE,
Slackware, Ubuntu, and Gentoo.
* Also, there are many ways to fool DNS, so that your client goes toAgreed. An agent that totally trusts a remote computer is dangerous, and
another, hostile server.
* And, lastly, a server is not 100% bulletproof either.
you shouldn't do that unless absolutely necessary.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering, Novell http://novell.com
Hacking is exploiting the gap between "intent" and "implementation"
- References:
- Perforce client: security hole by design
- From: Ben Bucksch
- Perforce client: security hole by design
- Prev by Date: [security bulletin] HPSBMA02176 SSRT051035 rev.1 - HP OpenView Network Node Manager (OV NNM) Remote Unauthorized Execution of Arbitrary Code
- Next by Date: LS-20061002 - Computer Associates BrightStor ARCserve Backup Remote Code Execution Vulnerability
- Previous by thread: Re: Perforce client: security hole by design
- Next by thread: SAP Security
- Index(es):
Relevant Pages
|
