From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LGfna-0003ke-LI for garchives@archives.gentoo.org; Sat, 27 Dec 2008 20:30:15 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0FE96E0077; Sat, 27 Dec 2008 20:30:13 +0000 (UTC) Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by pigeon.gentoo.org (Postfix) with ESMTP id 6E480E0077 for ; Sat, 27 Dec 2008 20:30:12 +0000 (UTC) Received: by bwz5 with SMTP id 5so4798146bwz.10 for ; Sat, 27 Dec 2008 12:30:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=JMUK/1pLpFBIBNY0cZKx4wqQc7vxw27phzLeggzue44=; b=qZYGIa/0S7YvUiVXnOFWRmoOWcI1tXVNuSMz+IYqRjtcE+CYhkDhJ2hrEmGv3qfR6r Ty6k81SBssceTuEq8ojOqZO+xeBzUJy8HQvc9FDzvZXtUGWPs9iG4XojzI7evEdINzvj lSfeT2ZpYzsp7DcWUdMD94QUJe/iIwfTLqJNc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jGerXHhQ6pnjG9m3r6pELxQxeRlXuDFWl4Wy6M0y1zLWdQWHx9QxMsMiKR2E/wu8YN 46TX29iyb8jewKvukx3oFJMI6gSORliTfR930VCKJ/wpilAHhBRg7LrlsXLdfItMmKyh TK9Vw8ooXHakGdUNPf8g2W8n5CzoXlrfD9QJo= Received: by 10.181.138.20 with SMTP id q20mr4503284bkn.209.1230409810601; Sat, 27 Dec 2008 12:30:10 -0800 (PST) Received: by 10.180.204.12 with HTTP; Sat, 27 Dec 2008 12:30:10 -0800 (PST) Message-ID: <49bf44f10812271230p7558e8fbt819e595e1cbc960b@mail.gmail.com> Date: Sat, 27 Dec 2008 12:30:10 -0800 From: Grant To: gentoo-hardened@lists.gentoo.org Subject: Re: [gentoo-hardened] Profile switch: hardened to non-hardened? In-Reply-To: <897813410812270818u49459nd83e9f628e946e07@mail.gmail.com> 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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49bf44f10812231323t7b5371eaj6a082f56f17b01e0@mail.gmail.com> <200812241621.13188.gengor@gentoo.org> <49bf44f10812250712u35f87d71l750fd67f97204dad@mail.gmail.com> <897813410812250830i2f910883n62b426dbe5a0329a@mail.gmail.com> <49bf44f10812251752j6ab40c33jd31c15f5a849454c@mail.gmail.com> <897813410812261117t40f2fecdu8b42f530788f47ec@mail.gmail.com> <49bf44f10812261247l2997a51axe9a3b5a581994f0b@mail.gmail.com> <897813410812270049x661a7a3el7913d39fe4fbd108@mail.gmail.com> <49bf44f10812270747y9f5bee3jb192efa6e911b999@mail.gmail.com> <897813410812270818u49459nd83e9f628e946e07@mail.gmail.com> X-Archives-Salt: ec20e4fc-604b-4a11-b67a-60ff801ace00 X-Archives-Hash: b396d799356f5eb06a0ecb29a849de58 > Low grsecurity level: > > linking restrictions > fifo restrictions > random pids > enforcing nproc on execve() > restricted dmesg > random ip ids > enforced chdir("/") on chroot > > Medium grsecurity level (include low grsec level) > > random tcp source ports > failed fork logging > time change logging > signal logging > deny mounts in chroot > deny double chrooting > deny sysctl writes in chroot > deny mknod in chroot > deny access to abstract AF_UNIX sockets out of chroot > deny pivot_root in chroot > denied writes of /dev/kmem, /dev/mem, and /dev/port > /proc restrictions with special gid set to 10 (generalmente wheel) > address space layout randomization > removal of addresses from /proc//[maps|stat] > > high grsecurity level (include low and medium): > > additional /proc restrictions > chmod restrictions in chroot > no signals, ptrace, or viewing processes outside of chroot > capability restrictions in chroot > deny fchdir out of chroot > priority restrictions in chroot > segmentation-based implementation of PaX > mprotect restrictions > kernel stack randomization > mount/unmount/remount logging > kernel symbol hiding > > I took this from the grsecurity-hacktimes-v1.0.pdf. Let's see. > > Low level: it enforces the chroot creation a bit and protect against > linking attacks. Protects against a few D.O.S. Is a very low low low > low level of security (this and nothing is something like the same. > > Medium level: This introduces two things interesting, it protects > memory devices from alteration (rootkits could do this). It harden the > chroots creation closing some doors that could make people escape from > it. I think it has not sense that ASLR appears here since the stack > probably stays executable and so is not needed one return into libc > attack to get success. The same for the restrictions to > /proc/self/maps. > > High level: It enforces the no executable stack and heap and the > mprotect restrictions to make it useful (so no memory could be > simultaneously writeable and executable. Now is needed the ASLR > approach and the hiding of address to make it useful against buffer > overflows. > > It would be useful to activate Trusted Path Execution by default > (maybe could appears in custom level?). Thank you for that. What I'm looking for is one or more easy methods for hardening my Gentoo systems. I have two desktops, a laptop, and a remote server. The desktops and laptop run a hardened kernel with grsecurity "Low" and the server runs a hardened profile and a hardened kernel with grsecurity "Medium". I don't run a hardened profile or grsecurity "Medium" on the desktops or laptops because problems pop up with Xorg apps and I don't have time to delve into them. I need something easy like enabling "Low", "Medium", or "High" and recompiling the kernel. What else would you recommend for me? - Grant >>> Why don't you tell what you didn't understand to us explain it >>> properly to you?. You can't assure nothing if you don't know what do >>> you need to assure. >>> You can't implement Mandatory Access Controls such as GRSEC rbac >>> without a bit of known. You need to make one policy for your system >>> and the kernel makes it enforcing their function. >>> >>> If you are not a sysadmin, how did you keep servers running?, to keep >>> servers you need to know how does them work internaly (for example DNS >>> rfc for DNS servers etc.). >> >> When I say I'm not a real sysadmin, I mean I have many duties and I'm >> not able to dive all the way in with sysadmin stuff. This is due to >> time constraints. >> >>> As bad is not getting one MAC system running (as the RBAC of >>> grsecurity) as get one incorrectly configured running, for example >>> granting all capabilities (CAP_SYS_RAWIO...) to the user running >>> skype. GRSEC has one TPE function in himself read about it. >>> >>> Sorry but you have to read documentation (start for example with >>> gentoo hardened docs). >> >> You're right. I thought that I was hardening my system just by >> running a hardened profile and a hardened kernel at the "Medium" >> Grsecurity setting. Does that provide no extra security if I don't >> configure it beyond that? >> >> - Grant >> >> >>>>> Without hardened userland only in access controls. You can implement >>>>> for example one Trusted Path Execution with LIDS, RSBAC, GRSEC or >>>>> SELinux. They could try to stop crackers that gain unpriviledge access >>>>> to the host (with a remote exploit for example) to execute exploits to >>>>> scale priviledges. They could give you one least priviledge approach >>>>> (as PaX does) and other useful things, as isolation of daemons, >>>>> resources controls. And a lot of more. With TPE however, untrusted >>>>> scripts (exploits) could be launched without execution rights, and >>>>> even restricting the use of perl and python, you must grant your users >>>>> the access to bash. >>>> >>>> Thank you for taking the time to explain, but I'm afraid I don't >>>> understand. I'm looking for things I can implement that don't require >>>> me to understand their inner workings. This is not ideal, but I only >>>> have so much time to devote to sysadmin duties since I'm not a real >>>> sysadmin. My server runs a hardened profile because it hasn't caused >>>> any problems, but running a hardened profile on my desktops has proven >>>> to be too difficult. All of my systems run a hardened kernel but the >>>> only hardened feature I've enabled in the kernel is Grsecurity set to >>>> medium or low depending on the system. >>>> >>>> Do the hardened profile and hardened kernels do me any good without >>>> further configuration? >>>> >>>> - Grant >>>> >>>>>>> In terms of userland, non hardened profile doesn't protect you at all >>>>>>> against buffer overflows, you are removing one important security >>>>>>> layer. SSP protects you against buffer overflows in terms that the >>>>>>> vulnerable application gets killed when the canary is modified before >>>>>>> the execution of the arbitrary code. PIE protects you against return >>>>>>> into libc attacks that doesn't need an executable stack. PaX is not >>>>>>> perfect and needs them as complementary solutions. For example I think >>>>>>> that RANDEXEC was removed from PaX time ago, one buffer overflow that >>>>>>> uses return into libc attack could be succesfully against one >>>>>>> non-hardened binary. Since skype is a network oriented software... >>>>>> >>>>>> In what situations is a hardened kernel useful? >>>>>> >>>>>> - Grant