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 <gentoo-hardened+bounces-2334-garchives=archives.gentoo.org@lists.gentoo.org>)
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 <gentoo-hardened@lists.gentoo.org>; Sat, 27 Dec 2008 20:30:12 +0000 (UTC)
Received: by bwz5 with SMTP id 5so4798146bwz.10
for <gentoo-hardened@lists.gentoo.org>; 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 <emailgrant@gmail.com>
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: <mailto:gentoo-hardened@lists.gentoo.org>
List-Help: <mailto:gentoo-hardened+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-hardened+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-hardened+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-hardened.gentoo.org>
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