From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RaBoA-0007jO-FW for garchives@archives.gentoo.org; Mon, 12 Dec 2011 19:45:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DB98D21C0B9; Mon, 12 Dec 2011 19:44:56 +0000 (UTC) Received: from mail-vw0-f53.google.com (mail-vw0-f53.google.com [209.85.212.53]) by pigeon.gentoo.org (Postfix) with ESMTP id E9F24E0484 for ; Mon, 12 Dec 2011 19:44:37 +0000 (UTC) Received: by vbbff1 with SMTP id ff1so4746425vbb.40 for ; Mon, 12 Dec 2011 11:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=xB5D15CBKCF/t0OWloFlLVj1aHklo/xFJ0pvYxfEJh0=; b=iwwdsuEsTybOW2Ym3kaqj4/14YW5uiQGaIFPGjYIibBwnQNTcs0SmcfVC5SST3UIKF 7ZZ1NnaTorhF6PAKd5FEZQfnLRkJXERQDOBBVO4s76kEynvc2n+ljAI6bFXbPK7qejtz xUFZ/BAm/u00GnWOXmYLqjfVxF/u80N/3xv2I= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-hardened@lists.gentoo.org Reply-to: gentoo-hardened@lists.gentoo.org MIME-Version: 1.0 Received: by 10.52.27.196 with SMTP id v4mr1339841vdg.30.1323719077462; Mon, 12 Dec 2011 11:44:37 -0800 (PST) Received: by 10.52.113.197 with HTTP; Mon, 12 Dec 2011 11:44:37 -0800 (PST) In-Reply-To: <20111212184115.65f27c92.ma1l1ists@yahoo.co.uk> References: <4EE3BE6B.6050507@libertytrek.org> <20111210145204.39ec9cba@khorne.mthode.org> <20111211101851.GA1810@gentoo.org> <20111211122043.GD1990@home.power> <20111211142519.GA12313@gentoo.org> <20111211145302.GE1990@home.power> <20111211200846.85ac1405.ma1l1ists@yahoo.co.uk> <4EE5EBDE.2090400@gentoo.org> <20111212133800.7780175b.ma1l1ists@yahoo.co.uk> <20111212140825.73b06f80.ma1l1ists@yahoo.co.uk> <20111212164407.f630eba5.ma1l1ists@yahoo.co.uk> <20111212184115.65f27c92.ma1l1ists@yahoo.co.uk> Date: Mon, 12 Dec 2011 20:44:37 +0100 Message-ID: Subject: Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm... From: =?ISO-8859-1?Q?Javier_Juan_Mart=EDnez_Cabez=F3n?= To: gentoo-hardened@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 6db96d90-d310-4ae4-96d0-217d9d2cb1d0 X-Archives-Hash: ae24ccd720719581fd090eb6e2e7408f =BFWhat can't you understand that you CAN translate one exploit in C in per= l? Are you joking? any user can write in their home directories their own perl exploits. You can't restrict that. You can only restrict them under rbac which scripts can be interpreted even for root, removing execution to perl binary doesn't solve anything, because root can still using it. I think that you don't understand the term rbac, rbac removes root. ROOT doesn't exists anymore. Before talking what rbac does or not first read a bit what is it because you don't understand it. Here you has info: csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf Comparing DAC with RBAC is simply stupid. Daemons chrooted can still uploading untrusted code and get it executed with posibility of privilege scalation even on root jail. Telling me that you dont find sense of rbac in servers you told me everything, this gives fine grained access controls, less privileges approach without getting one full privilege approach for one part of daemon (those permited to SUID to inner user in the daemon and to bind to port < 1024 so before dropping) With rbac a bug in the privilege code of a daemon doesn't grant access to for example /etc/shadow it's confined, this does not happen necessary under servers even under chroot. The openbsd kernel maybe more secure but read it is as horrible as to read one economist reference book. I have never seen so many if UID !=3D0 in so many different places in so many different functions as in its kernel, maybe it's one of the lonely systems that read the source code in assembler is easier even than read it in source C code. Granularity is a word that openbsd developers seems to have forgotten in their vocabulary and the word "comment the code" too. Have you read it? or you have this idea about the goodeness about their code because you read it in some web page? Systrace is so dead that his hair is kilometers of long, when did they do the last modification of their source code? in the 18th century?, you confuse even too rbac with systrace, systrace is not an rbac it just controls only which syscalls can a binary make, no granularity at all. Please repite with me: C exploits could be translated into perl. Any user can write their own exploit in their home directory and with only this sillyness execute it: scriptkiddie@hell:~$/bin/perl ./mysuidpreferedexploit. No need to execute privileges just only read one, users can know howto write perl code. Users can use functions in perl or in python, so users can do everything they want without getting execute priv and only with a write permission to some directory (/tmp and /home/hisdir). This can only be controlled with an RBAC approach nothing more. And not is not a bug perl, is using perl to write exploits they are different questions. 2011/12/12 Kevin Chadwick : > On Mon, 12 Dec 2011 18:38:28 +0100 > Javier Juan Mart=EDnez Cabez=F3n wrote: > >> Now please tell me how under this circunstances could root to make nothi= ng. > > What are you asking? > > The heart of the OS is the kernel. The OpenBSD kernel is more secure > and always will be full stop because that is their main aim. Think about > the exploits in the Linux kernel for all those years whilst they were > present someone could have been exploiting them and still untill the > next one is added and/or found, one of them can likely bypass RBAC. > Restrictions upon root on OpenBSD have been shown to be bypassable > locally on Pentium >2s via cpu management mode by a root user, it's > still difficult. Therefore I try to use certain hardware and will still > use chflags sappnd etc.. > > Your example about execution can be controlled via file permissions, if > someone allows arbitrary running as root, RBAC or not that is dumb. > Your daemons should be chrooted as normal users so for servers rbac > means very little to me but I would use it if I ran Linux servers and > am planning to use it on my Linux desktops and OpenBSD would likely code > it if they had many more developers and got lots of the other stuff they > want done and couldn't find any more bugs. They certainly wouldn't > refuse a working and well written patch. For desktops or more > exploitable systems rbac gains some weight, so does systrace but all > these tools are good things (don't mention the races in systrace > because I'm not interested and it's still useful) and RAWIO is off by > default on OpenBSD. > > Perl can only execute binaries on the system that are there and some > will on a large install contain local exploits or bugs which can be > reduced and fixed but not those introduced by users which could be far > more easily exploited and you can't even hope to prevent that. If you > can exploit the system through perl then that is a perl bug. If perl > scripts are a problem chmod it 750 and/or systrace it or rbac it. Next > you'll be telling me about physical security and bios batteries, well > physical security can exist and lets stop now as it is all irrelevent > and I'm sure everyone here is bored to death of the OpenBSD vs RBAC or > PAX topic. > > All of this comes down to more is better and noexec mounts are one of > those blanket tools possibly with effective grsec logging. Exec logging > is usually too much to handle. > > Also many exploits only do one particular thing, so dismissal like this > is simply wrong and part of the problem. In fact I remember Linux being > criticised for execution on downloads, the best answer was noexec should > be used. There is also the possibility of users loading up limewire > etc.. >