<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Securing laptops with ecryptfs, cryptsetup, and tmpfs</title>
	<atom:link href="http://www.tolaris.com/2009/11/14/securing-laptops-with-ecryptfs-cryptsetup-and-tmpfs/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.tolaris.com/2009/11/14/securing-laptops-with-ecryptfs-cryptsetup-and-tmpfs/</link>
	<description>Back off, man. I'm a scientist.</description>
	<lastBuildDate>Wed, 03 Mar 2010 22:54:18 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: tyler</title>
		<link>http://www.tolaris.com/2009/11/14/securing-laptops-with-ecryptfs-cryptsetup-and-tmpfs/comment-page-1/#comment-129</link>
		<dc:creator>tyler</dc:creator>
		<pubDate>Fri, 25 Dec 2009 22:15:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.tolaris.com/?p=618#comment-129</guid>
		<description>Chuck,

It may be wise to encrypt at least /var/tmp/ or link that into /tmp.  However, most of what you&#039;ll find there are things like KDE thumbnails and favicons from web pages Konqueror visits.  It&#039;s not a major security leak, but it is annoying.  Worse, the data here is expected to persist, so linking it into /tmp is not the best practice.

I wouldn&#039;t bother encrypting /var.  If you have a server with data there that matters, you might as well encrypt the whole disk.</description>
		<content:encoded><![CDATA[<p>Chuck,</p>
<p>It may be wise to encrypt at least /var/tmp/ or link that into /tmp.  However, most of what you&#8217;ll find there are things like KDE thumbnails and favicons from web pages Konqueror visits.  It&#8217;s not a major security leak, but it is annoying.  Worse, the data here is expected to persist, so linking it into /tmp is not the best practice.</p>
<p>I wouldn&#8217;t bother encrypting /var.  If you have a server with data there that matters, you might as well encrypt the whole disk.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chuck</title>
		<link>http://www.tolaris.com/2009/11/14/securing-laptops-with-ecryptfs-cryptsetup-and-tmpfs/comment-page-1/#comment-128</link>
		<dc:creator>Chuck</dc:creator>
		<pubDate>Fri, 25 Dec 2009 21:41:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.tolaris.com/?p=618#comment-128</guid>
		<description>Thanks for the nice guide :)
For some time I had an encrypted LVM with /home, /var, /tmp and swap -- but dealing with LUKS and cryptsetup was always a bit of a hassle...
I wonder if (for professionals) /var needs to be encrypted too -- but I guess for my private use an encrypted var would be overdone ;)</description>
		<content:encoded><![CDATA[<p>Thanks for the nice guide <img src='http://www.tolaris.com/blog/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /><br />
For some time I had an encrypted LVM with /home, /var, /tmp and swap &#8212; but dealing with LUKS and cryptsetup was always a bit of a hassle&#8230;<br />
I wonder if (for professionals) /var needs to be encrypted too &#8212; but I guess for my private use an encrypted var would be overdone <img src='http://www.tolaris.com/blog/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tyler</title>
		<link>http://www.tolaris.com/2009/11/14/securing-laptops-with-ecryptfs-cryptsetup-and-tmpfs/comment-page-1/#comment-122</link>
		<dc:creator>tyler</dc:creator>
		<pubDate>Mon, 16 Nov 2009 11:04:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.tolaris.com/?p=618#comment-122</guid>
		<description>breakpoint,

The advantage of using filesystem-based encryption versus volume-based is that different users can have different keys, all on the same filesystem.  Some information leakage occurs this way: the number of files, approximate sizes, and the size and depth of the directory hierarchy, but I&#039;m not losing any sleep over that.  This won&#039;t protect against access to a running system - it&#039;s already mounted and readable to the OS - but it will do a lot for hardware loss.

We backup our keys, yes, and demand access to and control over company hardware used by employees.  I assure you that my key escrow scheme is more secure than most users&#039; habits.  :)</description>
		<content:encoded><![CDATA[<p>breakpoint,</p>
<p>The advantage of using filesystem-based encryption versus volume-based is that different users can have different keys, all on the same filesystem.  Some information leakage occurs this way: the number of files, approximate sizes, and the size and depth of the directory hierarchy, but I&#8217;m not losing any sleep over that.  This won&#8217;t protect against access to a running system &#8211; it&#8217;s already mounted and readable to the OS &#8211; but it will do a lot for hardware loss.</p>
<p>We backup our keys, yes, and demand access to and control over company hardware used by employees.  I assure you that my key escrow scheme is more secure than most users&#8217; habits.  <img src='http://www.tolaris.com/blog/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: breakpoint</title>
		<link>http://www.tolaris.com/2009/11/14/securing-laptops-with-ecryptfs-cryptsetup-and-tmpfs/comment-page-1/#comment-121</link>
		<dc:creator>breakpoint</dc:creator>
		<pubDate>Mon, 16 Nov 2009 09:38:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.tolaris.com/?p=618#comment-121</guid>
		<description>Fedora has allowed install-time filesystem encryption for some time.  Additionally, it&#039;s possible do a manual LVM setup that creates a LUKS encrypted LVM partition which in turn has (secondarily encrypted with another key) LUKS encrypted logical volumes.  Whether or not this is actually advantageous vs. just using encryption at only one of those layers depends on your situation-- the only use I&#039;ve really thought of is allowing somebody to at least get the system to boot using a lower security password but ensure that sensitive systems and data can&#039;t be started or accessed-- but it is interesting to note that the performance hit from two layers of crypto was not nearly what I would have expected (admittedly, though, this was running on a stripe set).

From a consultant&#039;s point of view, the weak point of practically any corporate network is the fact that they&#039;re going to want the keys, they&#039;re going to want to test them, and they&#039;re going to scream bloody murder the first time you try to really lock things down.  I&#039;ve been able to get people to choke down restricted access MUCH easier than password hygiene.

I do, however, make people sign things when they reject my advice these days.  My contracts almost always include a clause releasing me from liability for any security incident on a system or network not secured to generally accepted standards and practices (i.e., you use strong passwords, sensitive data is encrypted, physical access to machines is restricted to those with a need to service them, etc.).

Sounds like your firm has had to react to a few... incidents.  Hope none of them were major.</description>
		<content:encoded><![CDATA[<p>Fedora has allowed install-time filesystem encryption for some time.  Additionally, it&#8217;s possible do a manual LVM setup that creates a LUKS encrypted LVM partition which in turn has (secondarily encrypted with another key) LUKS encrypted logical volumes.  Whether or not this is actually advantageous vs. just using encryption at only one of those layers depends on your situation&#8211; the only use I&#8217;ve really thought of is allowing somebody to at least get the system to boot using a lower security password but ensure that sensitive systems and data can&#8217;t be started or accessed&#8211; but it is interesting to note that the performance hit from two layers of crypto was not nearly what I would have expected (admittedly, though, this was running on a stripe set).</p>
<p>From a consultant&#8217;s point of view, the weak point of practically any corporate network is the fact that they&#8217;re going to want the keys, they&#8217;re going to want to test them, and they&#8217;re going to scream bloody murder the first time you try to really lock things down.  I&#8217;ve been able to get people to choke down restricted access MUCH easier than password hygiene.</p>
<p>I do, however, make people sign things when they reject my advice these days.  My contracts almost always include a clause releasing me from liability for any security incident on a system or network not secured to generally accepted standards and practices (i.e., you use strong passwords, sensitive data is encrypted, physical access to machines is restricted to those with a need to service them, etc.).</p>
<p>Sounds like your firm has had to react to a few&#8230; incidents.  Hope none of them were major.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tyler</title>
		<link>http://www.tolaris.com/2009/11/14/securing-laptops-with-ecryptfs-cryptsetup-and-tmpfs/comment-page-1/#comment-119</link>
		<dc:creator>tyler</dc:creator>
		<pubDate>Sun, 15 Nov 2009 15:58:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.tolaris.com/?p=618#comment-119</guid>
		<description>My only experience with FileVault is reading the relevant wikipedia page, so I can only speculate.  From what I read the feature is comparable, but ecryptfs can also be used to encrypt only specific directories.  For instance, it is common now to have a ~/Private for this purpose, which is what the ecryptfs-setup-private command does if you just stop there.

The biggest advantage I can see is that ecryptfs is open source and FileVault is not.  Lack of peer review is very bad for cryptographic security.</description>
		<content:encoded><![CDATA[<p>My only experience with FileVault is reading the relevant wikipedia page, so I can only speculate.  From what I read the feature is comparable, but ecryptfs can also be used to encrypt only specific directories.  For instance, it is common now to have a ~/Private for this purpose, which is what the ecryptfs-setup-private command does if you just stop there.</p>
<p>The biggest advantage I can see is that ecryptfs is open source and FileVault is not.  Lack of peer review is very bad for cryptographic security.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daryl</title>
		<link>http://www.tolaris.com/2009/11/14/securing-laptops-with-ecryptfs-cryptsetup-and-tmpfs/comment-page-1/#comment-118</link>
		<dc:creator>Daryl</dc:creator>
		<pubDate>Sun, 15 Nov 2009 12:10:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.tolaris.com/?p=618#comment-118</guid>
		<description>Practical advantages of this over using, say FileVault on the Mac ? (still loves the Ubuntu but use it on the servers... though feel bad I use OSX all the time... =] ).</description>
		<content:encoded><![CDATA[<p>Practical advantages of this over using, say FileVault on the Mac ? (still loves the Ubuntu but use it on the servers&#8230; though feel bad I use OSX all the time&#8230; =] ).</p>
]]></content:encoded>
	</item>
</channel>
</rss>
