All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dale Amon <amon@vnl.com>
To: Joshua Brindle <JBrindle@snu.edu>
Cc: SELinux@tycho.nsa.gov
Subject: Re: user transparent encryption
Date: Mon, 17 Feb 2003 15:20:01 +0000	[thread overview]
Message-ID: <20030217152001.GD14914@vnl.com> (raw)
In-Reply-To: <se502174.064@atlas.snu.edu>

On Sun, Feb 16, 2003 at 11:40:01PM -0600, Joshua Brindle wrote:
> I've pondered this myself, suppose you have a great selinux setup
> very secure, no easy way to compromise it, but the machine itself
> was in a hostile environment (not able to be protected from others
> well). What is to stop someone from booting up a non-selinux kernel
> and having at it with your filesystems? Nothing. I've often wondered
> if there is a way to lock down the drive contents so it is not
> accessible 
> (at least easily) by a non-selinux kernel, or even the encrypted fs
> where the key is compiled securely into a selinux-enabled kernel
> so that with a new (possible non-selinux) kernel the filesystem would
> not be readable. Do you guys think this is possible? granted it would
> make system recovery next to impossible but maybe it would be a 
> good option for folks with malicious or ignorant users/-co admins?
> 
> Joshua Brindle
> UNIX Administrator
> Southern Nazarene University

I don't have a full solution (other than what Russell
discusses later in this thread) but you should certainly
assume a well configured secure systems has:

	* a BIOS password
	* a lilo boot password
	* good root and role passwords

If you have reasonable password security, an attacker
now has no choice other than to disassemble the machine
and put the hard drive(s) in another machine. This is
not a full solution, but it stops the casual attacker
in the machine room cold unless they've got enough 
time to:

	* open up the machine
	* connect the IDE/SCSI cables to a preconfigured
	  attack machine
	* attack the disks
		* online: immediate entry and mod
		* offline: make copies of the disks
		  for study and later attack
	* load a log cleansing script
	* reconnect, close up and reboot
	* have the cleanup script run and remove
	  itself.

The online attack can be stopped cold by encrypted
root and user disks. Then, the attacker must

	* get an image of the disk
	* use social engineering, espionage or 
	  theft to get the password

And even then, to get the disk copy they might as
well not even try to hide their tracks because
without the passwords they can't put it back
as it was. They will have left a clear signature
they were there. Which means a serious attacker
might just torch the computer room to hide their
tracks. (hmmm... Twente???)

So if you go with Russell's approach, the machine
is secure against all but the admin with the key
and. If the admin is bent, or not careful with
the key, or his subverted (Mata Hari or missing 
fingers), then all is lost.

Ultimately comes down to internal security 
procedures and a sufficiently large and highly
trained staff to handle those issues.

That's why real security is *very* expensive.

-- 
------------------------------------------------------
       IN MY NAME:            Dale Amon, CEO/MD
  No Mushrooms clouds over    Islandone Society
    London and New York.      www.islandone.org
------------------------------------------------------

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  parent reply	other threads:[~2003-02-17 15:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-17  5:40 user transparent encryption Joshua Brindle
2003-02-17  7:43 ` Thomas Walcott
2003-02-17  9:18 ` Russell Coker
2003-02-17 15:28   ` w9ya
2003-02-17 15:20 ` Dale Amon [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-02-17  2:18 kayo
2003-02-17  2:43 ` Brian May
2003-02-17  5:43 ` kayo
2003-02-17  8:47   ` Carsten Grohmann
2003-02-17 11:54   ` Tom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030217152001.GD14914@vnl.com \
    --to=amon@vnl.com \
    --cc=JBrindle@snu.edu \
    --cc=SELinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.