[Fwd: [gentoo-hardened] Tin Hat = hardened Gentoo distro in RAM]

[Fwd: [gentoo-hardened] Tin Hat = hardened Gentoo distro in RAM]

[Ferris McCormick]

[-- Attachment #1: Type: text/plain, Size: 2274 bytes --]

Most interesting.  Perhaps of use to you?

-------- Forwarded Message --------
From: dante <dante@virtualblueness.net>
Reply-To: gentoo-hardened@lists.gentoo.org
To: gentoo-hardened@lists.gentoo.org
Subject: [gentoo-hardened] Tin Hat = hardened Gentoo distro in RAM
Date: Fri, 01 Aug 2008 08:24:01 -0400

Hi everyone,

My students and I have started a new gnome-based desktop linux distro
derived from hardened Gentoo.   It may be of interest to people on this
list.

Tin Hat is pretty much Gentoo, but it runs purely in RAM.  It boots from
CD or pen drive, but is not a liveCD in that it doesn't mount a file
system from the boot device.  Rather it copies its squashfs from CD to
tmpfs in RAM.  Booting is slow, it requres 4 GB of RAM or more, but it
is lightening fast once up.  ("emerge --sync" takes about a minute
between a Tin Hat system offering portage, and one sync-ing from
scratch.  Firefox starts in about 1 second.)

Tin Hat was started before the recent coldboot attacks.  Within the
limit of such attacks, Tin Hat aims at "zero information loss" if
physical access is obtained to a system which is powered down.  We add
Ruusu's loop-aes patch to the kernel so that any hard drives are mounted
using one of the best implimentations of block cipher encryptions we
know of.  During power up, Tin Hat uses GRSEC/PaX hardening to hedge
against all the usual attacks.  We are now thinking about our own patch
to obfuscate data in RAM to protect against coldboot --- but to be
honest, we think we can only make it harder, not impossible.

Tin Hat is stable.  We run 6 systems persistently on clean power and
have typical up times of a couple of months.

We never intended on releasing Tin Hat, but the students love it so much
(the speed!) we thought of announcing it on freshmeat.  I thought I'd
post to this list because of it is a successful implementation of
hardened Gentoo.

Home page: http://opensource.dyc.edu/tinhat
Freshmeat: http://freshmeat.net/projects/tinhat

Anthony G. Basile
Chair of Information Technology
D'Youville College
Buffalo NY 14201

(716) 829-8197


Regards,
Ferris

-- 
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-hardened] Tin Hat memory requirements?

[Jan Klod]

Hello,
I am interested in setting up distro in RAM for file server, but the thing is: 
I only have 1GB of RAM (max in board). Since fileserver really doesn't 
require much of software, I was consider asking this question: can Tin Hat 
help here?
How booting is done?
How back-synchronization happens (from RAM to backup)? Only manually by 
copying?

Hope you give some advices,
Jan

Re: [gentoo-hardened] Tin Hat memory requirements?

[Natanael Copa]

On Wed, 2008-08-20 at 13:37 +0300, Jan Klod wrote:
> Hello,
> I am interested in setting up distro in RAM for file server, but the thing is: 
> I only have 1GB of RAM (max in board). Since fileserver really doesn't 
> require much of software, I was consider asking this question: can Tin Hat 
> help here?
> How booting is done?
> How back-synchronization happens (from RAM to backup)? Only manually by 
> copying?
> 
> Hope you give some advices,

If you dont need xorg you might want to take a look at alpine linux,
distro based on gentoo hardened with uclibc/busybox. It is designed to
run firewalls and vpns from RAM but can also be used for ISCSI, vserver
hosts, samba/nfs and others.

during boot it installs all the needed packages to RAM. There is a local
backup utility that helps to backup your /etc to USB memory together
with the list of installed packages so get your configuration back.

http://alpinelinux.org

-nc

Re: [gentoo-hardened] Tin Hat memory requirements?

[Jan Klod]

On Wednesday 20 August 2008 14:14:24 Natanael Copa wrote:
> On Wed, 2008-08-20 at 13:37 +0300, Jan Klod wrote:
> > Hello,
> > I am interested in setting up distro in RAM for file server, but the
> > thing is: I only have 1GB of RAM (max in board). Since fileserver really
> > doesn't require much of software, I was consider asking this question:
> > can Tin Hat help here?
> > How booting is done?
> > How back-synchronization happens (from RAM to backup)? Only manually by
> > copying?
> >
> > Hope you give some advices,
>
> If you dont need xorg you might want to take a look at alpine linux,
> distro based on gentoo hardened with uclibc/busybox. It is designed to
> run firewalls and vpns from RAM but can also be used for ISCSI, vserver
> hosts, samba/nfs and others.
>
> during boot it installs all the needed packages to RAM. There is a local
> backup utility that helps to backup your /etc to USB memory together
> with the list of installed packages so get your configuration back.
>
> http://alpinelinux.org
>
> -nc

Thank you Natanael, but, before I start long reading about it, what could be 
memory requirements for alpine and is it a real hardened gentoo with portage 
accessible or, if not, how all the install / compiling is done there?

Jan

Re: [gentoo-hardened] Tin Hat memory requirements?

[Natanael Copa]

On Wed, 2008-08-20 at 14:54 +0300, Jan Klod wrote:
> On Wednesday 20 August 2008 14:14:24 Natanael Copa wrote:
> > On Wed, 2008-08-20 at 13:37 +0300, Jan Klod wrote:
> > > Hello,
> > > I am interested in setting up distro in RAM for file server, but the
> > > thing is: I only have 1GB of RAM (max in board). Since fileserver really
> > > doesn't require much of software, I was consider asking this question:
> > > can Tin Hat help here?
> > > How booting is done?
> > > How back-synchronization happens (from RAM to backup)? Only manually by
> > > copying?
> > >
> > > Hope you give some advices,
> >
> > If you dont need xorg you might want to take a look at alpine linux,
> > distro based on gentoo hardened with uclibc/busybox. It is designed to
> > run firewalls and vpns from RAM but can also be used for ISCSI, vserver
> > hosts, samba/nfs and others.
> >
> > during boot it installs all the needed packages to RAM. There is a local
> > backup utility that helps to backup your /etc to USB memory together
> > with the list of installed packages so get your configuration back.
> >
> > http://alpinelinux.org
> >
> > -nc
> 
> Thank you Natanael, but, before I start long reading about it, what could be 
> memory requirements for alpine 

Depends on what you plan to run. You can boot it up with 16MB RAM but
then you have nothing in there but busybox and openssl.

> and is it a real hardened gentoo with portage 
> accessible or, if not, how all the install / compiling is done there?

no. Its built with gentoo but the binary packages are converted to .apk
(which is a tar.gz with some extra files with dependencies etc)

The reason I don't use the gentoo tbz2 is becuase it does not support
package splitting (i.e separate documentation and developer packages
for /usr/share/doc and .h and .a files)

you can install precompield binaries using apk_add:

apk_add openssh samba

packages get installed in tmpfs. Running the local backup utility will
make sure your pacages are reinstalled next reboot:

lbu commit


There are around 500 available packages:
http://distrib-coffee.ipsl.jussieu.fr/pub/linux/alpine/alpine/v1.7/apks/

The drawback with this approach is that it is too difficult to set up a
developer environment to build your own stuff from gentoo. you need
gentoo stage, gentoo portage + alpine overlay + a set of convert
Makefiles.


> 
> Jan
> 

Re: [gentoo-hardened] Tin Hat memory requirements?

[Jan Klod]

> The reason I don't use the gentoo tbz2 is becuase it does not support
> package splitting (i.e separate documentation and developer packages
> for /usr/share/doc and .h and .a files)
>
> you can install precompield binaries using apk_add:

Well, not so bad for a special-purpose machine, but is it hard to make those 
binary packages (*.apk) for quick install with apk_add? 

[gentoo-hardened] Updates: a way too simplified security question I am asking anyway

[Jan Klod]

Hello,
some people in gentoo forum made me ask this one: it is supposed, that regular 
updates of system is a wise thing to do, but, excuse me, ... those bugs and 
holes are there before someone say "update them" -- so do you agree, nowdays 
Linux is never safe?
OpenBSD has its own slogan about only very few remote holes in long time -- so 
it makes an impression, I can install an OpenBSD machine and let it do it's 
job. 
Can anyone crash my impression about OpenBSD (and is it still alive enough, by 
the way?)?
How about hardened gentoo in this regard (create system for few, specific 
purposes and leave it for years without damn update hustle)?

I realize, this is "in general", but the question is about software writing 
style (think when write it or wait for someone to find what is wrong) and 
ways to protect from bugs (like overflows etc) in software.

In ideal world, updates are necessary only to get software, that has new 
functions -- do we seam to approach it?

Jan

Re: [gentoo-hardened] Updates: a way too simplified security question I am asking anyway

[Arne Morten Johansen]

Interesting points. But I don't think the hardened mailinglist is the 
right place to discuss general software-design, even if it's security 
related. But who am  I to say what's allowed here? :-)

My personal view is that software will always have bugs and security 
holes. That's why it's important to have multiple layers of security. If 
a program/package has a software bug that could lead to security issues 
it doesn't make the whole system unsafe. I think the hardened-project 
comes a long way to address this. It's never gonna be perfect but 
atleast it is IMO a very good start. Secure your services with good 
secure network design, educated users (this goes a long way), patched 
software, correctly and securely configured software, and lastly 
hardening technologies like the stuff gentoo-hardened provides.

Claiming that Linux-developers don't think about security is pretty 
unfair. Even if openbsd have had few remote exploits in its default 
install. There have been alot of remote exploits after you start adding 
usefull applications. An OS is nothing without its apps ;)

As for updates, just upgrade stuff with known holes? Limit the number of 
packages and the number of holes to fix won't be so big. I've also set 
up a glsa-check script to run on cron to e-mail me warnings. No need to 
do emerge -uavD world every week. But I do agree the patching arms-race 
is not optimal. But openBSD and other platforms suffers from the very 
same problem. I don't think we're gonna see a solution to that problem 
in the nearest future.

Probably not the educated answer you were looking for. I mainly wrote it 
for my self to see what i'd come up with. Hope someone else will answer to.

Arne Morten

Jan Klod skrev:
> Hello,
> some people in gentoo forum made me ask this one: it is supposed, that regular 
> updates of system is a wise thing to do, but, excuse me, ... those bugs and 
> holes are there before someone say "update them" -- so do you agree, nowdays 
> Linux is never safe?
> OpenBSD has its own slogan about only very few remote holes in long time -- so 
> it makes an impression, I can install an OpenBSD machine and let it do it's 
> job. 
> Can anyone crash my impression about OpenBSD (and is it still alive enough, by 
> the way?)?
> How about hardened gentoo in this regard (create system for few, specific 
> purposes and leave it for years without damn update hustle)?
>
> I realize, this is "in general", but the question is about software writing 
> style (think when write it or wait for someone to find what is wrong) and 
> ways to protect from bugs (like overflows etc) in software.
>
> In ideal world, updates are necessary only to get software, that has new 
> functions -- do we seam to approach it?
>
> Jan
>
>   

Re: [gentoo-hardened] Updates: a way too simplified security question I am asking anyway

[RB]

On Wed, Aug 20, 2008 at 12:14 PM, Jan Klod <janklodvan@gmail.com> wrote:
<snip rambling flame>

I'm not going to address each of the fallacies I see in your
statements, but you have an exceedingly idealistic view of software
development and particular OS' perceived security.  [Insert project
here] may have a slogan, but the developers are still human and thus
still make mistakes and are inherently lazy.  Short of being powered
by unicorn farts, there is no way any reasonably complex system can
approach that ideal.

In regard to your philosophy of updates, do you build a wall and not
defend it?  Do you plant a garden and not water it?  In the same
light, no system can be "permanently" secured.  Safes are rated by the
amount of time it would take a dedicated, skilled cracker to open it;
none are ever deemed uncrackable.  If you want more time, you purchase
[or build] one that better matches your needs.  System security is no
different.


RB

Re: [gentoo-hardened] Updates: a way too simplified security question I am asking anyway

[Javier Martínez]

Well, first bugs are always there, maybe the unique difference between
this two OS is that OpenBSD have found more of them (maybe), this does
not means that OpenBSD is free of bugs, it stills having them be sure
of this, if this statement is not true why they are still making
auditories to their code if there are not bugs?.

This is not an ideal world, software is written by humans so since
humans are not perfect, software is not perfect too, bugs will exist
forever, the only thing developers can do is searching for them,
nothing more.

Do you want something to be safe?, first make your system a B1 one
(orange book), configure rsbac/Selinux to do so, configure PaX, make
an trusted path execution to avoid execution of untrusted software
(exploits) and then control the execution of perl an python (between
others) scripts (in the way of perl blablabla.pl, which does not need
execution rights). You under this two frameworks you can do it. Can
you do this under OpenBSD ;).

2008/8/20, Jan Klod <janklodvan@gmail.com>:
> Hello,
> some people in gentoo forum made me ask this one: it is supposed, that
> regular
> updates of system is a wise thing to do, but, excuse me, ... those bugs and
> holes are there before someone say "update them" -- so do you agree, nowdays
> Linux is never safe?
> OpenBSD has its own slogan about only very few remote holes in long time --
> so
> it makes an impression, I can install an OpenBSD machine and let it do it's
> job.
> Can anyone crash my impression about OpenBSD (and is it still alive enough,
> by
> the way?)?
> How about hardened gentoo in this regard (create system for few, specific
> purposes and leave it for years without damn update hustle)?
>
> I realize, this is "in general", but the question is about software writing
> style (think when write it or wait for someone to find what is wrong) and
> ways to protect from bugs (like overflows etc) in software.
>
> In ideal world, updates are necessary only to get software, that has new
> functions -- do we seam to approach it?
>
> Jan
>
>

Re: [gentoo-hardened] Updates: a way too simplified security question I am asking anyway

[Jan Klod]

On Wednesday 20 August 2008 22:31:30 RB wrote:
> On Wed, Aug 20, 2008 at 12:14 PM, Jan Klod <janklodvan@gmail.com> wrote:
> <snip rambling flame>
No problem, we can cut it. 

> I'm not going to address each of the fallacies I see in your
> statements, but you have an exceedingly idealistic view of software
> development and particular OS' perceived security.  [Insert project
> here] may have a slogan, but the developers are still human and thus
> still make mistakes and are inherently lazy.  Short of being powered
> by unicorn farts, there is no way any reasonably complex system can
> approach that ideal.
[sorry, as you see, writing what I don't know much about]
In this light I was assuming, that file server is much less complex than it 
is. Give you my word to remember this when I write my next code :)

>
> In regard to your philosophy of updates, do you build a wall and not
> defend it?  Do you plant a garden and not water it?  In the same
> light, no system can be "permanently" secured.  Safes are rated by the
> amount of time it would take a dedicated, skilled cracker to open it;
> none are ever deemed uncrackable.  If you want more time, you purchase
> [or build] one that better matches your needs.  System security is no
> different.
Complexity matter again... Theoretically.. is it possible to enumerate all the 
possible scenarios for a file server? (or, I might have wrote - all of its 
states) Oh, sure, it has finite amount of memory :)
Human problem. 
Is easy to say "security", hard to give an action for all the possibilities 
(right action by our judgement)...

I started this as a "flame", but the rest might go out of scope of this list 
and send me to theoretical computer science.

Javier Martínez: 
"control the execution of perl an python (between
others) scripts (in the way of perl blablabla.pl, which does not need
execution rights). You under this two frameworks you can do it. Can
you do this under OpenBSD ;)"

Thanks, just you put me on my way, if I really need a reliable system, that I 
can get NOW AND HERE :)

[gentoo-hardened] aa

[Daniel Svensson]

unsubscribe

Re: [gentoo-hardened] Updates: a way too simplified security question I am asking anyway

[RB]

> Complexity matter again... Theoretically.. is it possible to enumerate all the
> possible scenarios for a file server? (or, I might have wrote - all of its
> states) Oh, sure, it has finite amount of memory :)

Those firmly on the "Threat modeling" side of the camp say you can.
The key is limiting your system's scope and using a positive
(default-deny) security model.  It's resource-intensive for the
implementer on the front end and inflexible, but can work for some
scenarios.

> I started this as a "flame", but the rest might go out of scope of this list
> and send me to theoretical computer science.

In spite of my CS degree (and probable pursuit of an advanced degree),
I don't esteem academia very highly.  Theory makes for pretty graphs
on thesis papers, but real-world application is the only way anything
will actually be solved.

> Javier Martínez:
> "control the execution of perl an python (between
> others) scripts (in the way of perl blablabla.pl, which does not need
> execution rights). You under this two frameworks you can do it. Can
> you do this under OpenBSD ;)"
>
> Thanks, just you put me on my way, if I really need a reliable system, that I
> can get NOW AND HERE :)

Yes - good, actionable suggestions.  Of course, the threat modeling
crew makes a good argument that anything beyond a MAC (selinux, RSBAC,
etc.) is wasted effort.  That, of course, assumes you've perfectly
succeeded in least-privilege.

Re: [gentoo-hardened] Updates: a way too simplified security question I am asking anyway

[Javier Martínez]

Well, then neither GNU/Linux and OpenBSD are systems for you, since
them both are not reliable since both are only a C2 systems by default
under the orange book, maybe you should look for a system as CaprOS
that reach to the A1 level and with other things has an exokernel
(instead of an monolithic kernel as OpenBSD and Linux).

Sorry but as I said you before, you can't make an OpenBSD trusted
since it needs a B1 classification, and the B1 needs Mandatory Access
Controls that doesn't exist in OpenBSD, at least in GNU/Linux we could
reach to the B1, enough to mark it as "trusted Operating system".

Conclussion: You will never find an secure from the box Operating
system, you will have to work (hard) to assure it under yours needs,
and for this you will need and MAC system.

2008/8/20, Jan Klod <janklodvan@gmail.com>:
> On Wednesday 20 August 2008 22:31:30 RB wrote:
>> On Wed, Aug 20, 2008 at 12:14 PM, Jan Klod <janklodvan@gmail.com> wrote:
>> <snip rambling flame>
> No problem, we can cut it.
>
>> I'm not going to address each of the fallacies I see in your
>> statements, but you have an exceedingly idealistic view of software
>> development and particular OS' perceived security.  [Insert project
>> here] may have a slogan, but the developers are still human and thus
>> still make mistakes and are inherently lazy.  Short of being powered
>> by unicorn farts, there is no way any reasonably complex system can
>> approach that ideal.
> [sorry, as you see, writing what I don't know much about]
> In this light I was assuming, that file server is much less complex than it
> is. Give you my word to remember this when I write my next code :)
>
>>
>> In regard to your philosophy of updates, do you build a wall and not
>> defend it?  Do you plant a garden and not water it?  In the same
>> light, no system can be "permanently" secured.  Safes are rated by the
>> amount of time it would take a dedicated, skilled cracker to open it;
>> none are ever deemed uncrackable.  If you want more time, you purchase
>> [or build] one that better matches your needs.  System security is no
>> different.
> Complexity matter again... Theoretically.. is it possible to enumerate all
> the
> possible scenarios for a file server? (or, I might have wrote - all of its
> states) Oh, sure, it has finite amount of memory :)
> Human problem.
> Is easy to say "security", hard to give an action for all the possibilities
> (right action by our judgement)...
>
> I started this as a "flame", but the rest might go out of scope of this list
> and send me to theoretical computer science.
>
> Javier Martínez:
> "control the execution of perl an python (between
> others) scripts (in the way of perl blablabla.pl, which does not need
> execution rights). You under this two frameworks you can do it. Can
> you do this under OpenBSD ;)"
>
> Thanks, just you put me on my way, if I really need a reliable system, that
> I
> can get NOW AND HERE :)
>
>

Re: [gentoo-hardened] Tin Hat memory requirements?

[Natanael Copa]

On Wed, 2008-08-20 at 19:03 +0300, Jan Klod wrote:
> > The reason I don't use the gentoo tbz2 is becuase it does not support
> > package splitting (i.e separate documentation and developer packages
> > for /usr/share/doc and .h and .a files)
> >
> > you can install precompield binaries using apk_add:
> 
> Well, not so bad for a special-purpose machine, but is it hard to make those 
> binary packages (*.apk) for quick install with apk_add? 

techincall no. You can actually rename any tar.gz file to foo-1.0.apk
and it just works. You can even install it remotely: 

apk_add scp://host/path/to/foo-1.0.apk

You might want to add a DEPEND file inside if you want dependencies.

If you are going to convert a gentoo package using the build env its a
bigger job, unfortunally.

-nc