LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 01-06-2015, 06:36 AM   #31
Ulysses_
Senior Member
 
Registered: Jul 2009
Posts: 1,160

Original Poster
Rep: Reputation: 45

I was hoping any keylogger is loaded AFTER you type the password/passphrase, in other words you would boot a live CD on a diskless pc, then enter the passphrase to mount one container out of a 100, then browse the internet, then get infected, then the malware can only see the one container but not the other 99 containers.

Unless it steals the passphrase from ram from my little binary executable. Containers would have different keys but the same passphrase so it is only typed once, so keyloggers cannot steal it.

If an SElinux setup makes it impossible to steal the passphrase from ram, that's what I need. But SElinux seems way too hard to set up.

Last edited by Ulysses_; 01-06-2015 at 07:12 AM.
 
Old 01-06-2015, 06:51 AM   #32
Ulysses_
Senior Member
 
Registered: Jul 2009
Posts: 1,160

Original Poster
Rep: Reputation: 45
Does an SElinux live CD exist, with instructions for editing the live CD to add a browser, truecrypt-like software and ssh?
 
Old 01-06-2015, 06:55 AM   #33
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,842

Rep: Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472
The best instructions I know are at: http://selinuxproject.org/page/Main_Page
and http://billauer.co.il/selinux-policy-module-howto.html

No it isn't easy yet, but it is the most complete.
 
Old 01-06-2015, 06:59 AM   #34
cepheus11
Member
 
Registered: Nov 2010
Location: Germany
Distribution: Gentoo
Posts: 286

Rep: Reputation: 89
Quote:
Originally Posted by Ulysses_ View Post
then the malware can only see the one container but not the other 99 containers, unless it steals the passphrase from ram.
The passphrase is no longer needed once the key has been derived from container header and passphrase. Good encryption software should 1) allocate the memory for the passphrase in such a way that is is never swapped out, 2) Overwrite the memory for the passphrase once it is no longer needed.

I can only guess that cryptsetup-luks or truecrypt do it in the right way, more research is required to be sure. I recommend not working with the passphrase in own scripts - you only add more copies of the passphrase, which are neither swap-protected nor sanitized after usage. You can call the crypto backend in your script and display it's password prompt, though. That way, your script process never keeps the passphrase in own memory.

The key is another beast: It has to remain in memory the whole time the container is open, because encryption and decryption of blocks occur all the time. If your 100 containers are created independently (and not copied from each other), all of them have a different key and one compromised container does not compromise the others. That is, if it is compromised by getting the key.

Some cues:

Hardened Kernel grsecurity.net - Trusted Path execution, sanitize freed memory, AppArmor/SELinux
Firefox with noscript addon, and webgl disabled in about:config

^That way it should be very, very difficult for code from the web to be even executed in the first place. Always keep the software up to date, best in a still supported long-term version. Especially browser and kernel.

Last edited by cepheus11; 01-06-2015 at 07:00 AM. Reason: typo
 
Old 01-06-2015, 07:10 AM   #35
Ulysses_
Senior Member
 
Registered: Jul 2009
Posts: 1,160

Original Poster
Rep: Reputation: 45
Thanks, and please have another look at my last edited post, the passphrase is held in ram in order to avoid typing it more than once which would expose it to a keylogger. It is needed because the keys generated from it are deliberately different for each container.

Last edited by Ulysses_; 01-06-2015 at 07:27 AM.
 
Old 01-06-2015, 07:50 AM   #36
cepheus11
Member
 
Registered: Nov 2010
Location: Germany
Distribution: Gentoo
Posts: 286

Rep: Reputation: 89
Ah sorry I did not notice this detail. But I think a keyfile instead of a passphrase would be a better option in that case. Maybe put the key file in a new container protected with an own passphrase. Once opened, the keyfile is accessible for the work with the 100 containers. Neither passphrase nor keyfile remain in application memory.
 
Old 01-06-2015, 08:08 AM   #37
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176
That's what you need to do: access is controlled by a unique, cryptographically-generated key. Use of the key, then, is controlled by a passphrase which must be used to decrypt the key. (Or, perhaps this latter step is optional.)

The host, perhaps using LDAP on its end for key-management, identifies each unique key and individually grants (or denies) access to each one. The host might know other things, such as the IP-address that the client will be coming from. In any case, you must possess both the key and the means to use it. If the client machine is compromised, the specific key that it is known to have held is promptly revoked by the host. (When "Eve" tries to use the now no-good key thereafter, you'll also know where she's coming from, and that it must be Eve.)
 
Old 01-06-2015, 10:02 AM   #38
Ulysses_
Senior Member
 
Registered: Jul 2009
Posts: 1,160

Original Poster
Rep: Reputation: 45
Thing is, we do not trust any remote host. This is why client-side encryption is preferred.

We do not trust our client either, once it has been infected.

Hopefully part of the client can be protected, ie most of the 100 containers and the passphrase that opens them all.
 
Old 01-06-2015, 11:54 AM   #39
dugan
LQ Guru
 
Registered: Nov 2003
Location: Canada
Distribution: distro hopper
Posts: 9,097

Rep: Reputation: 3932Reputation: 3932Reputation: 3932Reputation: 3932Reputation: 3932Reputation: 3932Reputation: 3932Reputation: 3932Reputation: 3932Reputation: 3932Reputation: 3932
Quote:
Originally Posted by Ulysses_ View Post
I was hoping any keylogger is loaded AFTER you type the password/passphrase, in other words you would...

Unless it steals the passphrase from ram from my little binary executable.
When would you be able to load malware that steals passwords from RAM, but not malware that logs keystrokes?
 
Old 01-06-2015, 01:11 PM   #40
Ulysses_
Senior Member
 
Registered: Jul 2009
Posts: 1,160

Original Poster
Rep: Reputation: 45
Malware cannot log keystrokes because you never type passphrase with malware loaded, only when you boot the live CD, and the live CD has been edited to never allow internet access before the passphrase has been typed.

Last edited by Ulysses_; 01-06-2015 at 01:53 PM.
 
Old 01-06-2015, 05:35 PM   #41
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,842

Rep: Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472
Quote:
Originally Posted by Ulysses_ View Post
Malware cannot log keystrokes because you never type passphrase with malware loaded, only when you boot the live CD, and the live CD has been edited to never allow internet access before the passphrase has been typed.
Doesn't prevent the malware from having gotten in before the CD was made.
 
Old 01-06-2015, 05:41 PM   #42
Ulysses_
Senior Member
 
Registered: Jul 2009
Posts: 1,160

Original Poster
Rep: Reputation: 45
Maybe the live CD can be made in a live CD session.
 
Old 01-06-2015, 05:46 PM   #43
metaschima
Senior Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 1,982

Rep: Reputation: 491Reputation: 491Reputation: 491Reputation: 491Reputation: 491
Quote:
Originally Posted by metaschima View Post
Here's an idea. Have a password file inside an encrypted container. All you need to do is mount this container and use the password file inside for opening any further containers. That way you put the password only once and it isn't stored in RAM.
I'm pretty sure that this would prevent people stealing the password from RAM. If you use cryptsetup it should handle the password correctly so it doesn't stay in RAM, and mounting an encrypted partition does not leak unencrypted data to RAM, AFAIK.

I'm mostly concerned about keeping the password in a bash variable, then they could use strace to find it because bash isn't designed to be particularly secure with its variables.
 
Old 01-06-2015, 05:47 PM   #44
dugan
LQ Guru
 
Registered: Nov 2003
Location: Canada
Distribution: distro hopper
Posts: 9,097

Rep: Reputation: 3932Reputation: 3932Reputation: 3932Reputation: 3932Reputation: 3932Reputation: 3932Reputation: 3932Reputation: 3932Reputation: 3932Reputation: 3932Reputation: 3932
Quote:
Originally Posted by jpollard View Post
Doesn't prevent the malware from having gotten in before the CD was made.
Yeah, seriously. Are you really assuming that the "container" is the only place where malware can be loaded from?

Also, if I'm understanding you right, then all you need to do is use memset to zero out the variables in your little binary executable that contain the password, right after your executable opens the container.

Last edited by dugan; 01-06-2015 at 05:59 PM.
 
Old 01-06-2015, 06:28 PM   #45
Ulysses_
Senior Member
 
Registered: Jul 2009
Posts: 1,160

Original Poster
Rep: Reputation: 45
They won't steal the passphrase but they will steal all the data, if it's only one container.

If it's more than one container, with different keys each container, then the passphrase has to stay in ram or you type it over and over every time you open yet another container.

You want to work with 3 containers, say, in a live CD session, out of 100, so only these 3 are exposed to spying malware.

Last edited by Ulysses_; 01-06-2015 at 06:37 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
could SystemTap be used by malicious person to steal ssh password easily ? wzis Linux - Security 4 05-03-2014 07:43 PM
how to specify password for sudo command when running bg process? sneakyimp Linux - Newbie 9 06-30-2010 02:14 PM
Freeing I/O resource held by zombie process kronesr Linux - Software 2 02-22-2010 11:29 AM
child process usses same amount of ram as parent process socialjazz Programming 7 10-19-2006 05:48 PM
Forward X / Steal a process sval Linux - General 0 12-30-2004 10:32 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 03:33 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration