Re: Support for geli onetime encryption for /tmp?
Olivier Smedts
> On 2009.12.12 23:07:58 +0100, Daniel Thiele wrote:
>
>> Is there maybe another way to achieve onetime /tmp encryption that
>> I am missing? Preferably one that does not involve huge changes to
>
> Well, I use the simple one - make /tmp a memory file system. �locate
> is sometimes not too happy with an e.g. 50MB /tmp, but otherwise it
> works very well for me.
>
> [simon@arthur:~] grep tmp /etc/rc.conf
> tmpmfs="YES"
> tmpsize="50M"
What about tmpfs ?
[0:16] zozo@q 1002 ~% grep tmp /etc/fstab
tmpfs /tmp tmpfs rw,mode=1777 0 0
[0:16] zozo@q 1003 ~% df -h /tmp
Filesystem Size Used Avail Capacity Mounted on
tmpfs 2.9G 12K 2.9G 0% /tmp
>
> --
> Simon L. Nielsen
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
>
--
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: oli...@gid0.org - against HTML email & vCards X
www: http://www.gid0.org - against proprietary attachments / \
"Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas."
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Max Laier
> On 2009.12.12 23:07:58 +0100, Daniel Thiele wrote:
> > Is there maybe another way to achieve onetime /tmp encryption that
> > I am missing? Preferably one that does not involve huge changes to
>
> Well, I use the simple one - make /tmp a memory file system. locate
> is sometimes not too happy with an e.g. 50MB /tmp, but otherwise it
> works very well for me.
>
> [simon@arthur:~] grep tmp /etc/rc.conf
> tmpmfs="YES"
> tmpsize="50M"
but tmpfs pages are swappable IIRC. This would mean that the data might end
up unencrypted on secondary storage.
--
Max
Ivan Voras
> On Saturday 12 December 2009 23:40:53 Simon L. Nielsen wrote:
>> On 2009.12.12 23:07:58 +0100, Daniel Thiele wrote:
>>> Is there maybe another way to achieve onetime /tmp encryption that
>>> I am missing? Preferably one that does not involve huge changes to
>> Well, I use the simple one - make /tmp a memory file system. locate
>> is sometimes not too happy with an e.g. 50MB /tmp, but otherwise it
>> works very well for me.
>>
>> [simon@arthur:~] grep tmp /etc/rc.conf
>> tmpmfs="YES"
>> tmpsize="50M"
>
> but tmpfs pages are swappable IIRC. This would mean that the data might end
> up unencrypted on secondary storage.
Not if the swap is encrypted (as it is in the case of the OP).
Gary Jennejohn
"Simon L. Nielsen" <si...@FreeBSD.org> wrote:
> I never looked at tmpfs, as I heard that it isn't really stable yet.
>
I've been using it for months without any problems. But I have lots of
memory and swap.
---
Gary Jennejohn
Shaun Amott
>
> 2009/12/12 Simon L. Nielsen <si...@freebsd.org>:
> > On 2009.12.12 23:07:58 +0100, Daniel Thiele wrote:
> >
> >> Is there maybe another way to achieve onetime /tmp encryption that
> >> I am missing? Preferably one that does not involve huge changes to
> >
> > Well, I use the simple one - make /tmp a memory file system. �locate
> > is sometimes not too happy with an e.g. 50MB /tmp, but otherwise it
> > works very well for me.
> >
> > [simon@arthur:~] grep tmp /etc/rc.conf
> > tmpmfs="YES"
> > tmpsize="50M"
>
> What about tmpfs ?
>
> [0:16] zozo@q 1002 ~% grep tmp /etc/fstab
> tmpfs /tmp tmpfs rw,mode=1777 0 0
> [0:16] zozo@q 1003 ~% df -h /tmp
> Filesystem Size Used Avail Capacity Mounted on
> tmpfs 2.9G 12K 2.9G 0% /tmp
>
Both good ideas, but not always an adequate solution: on at least some
of the systems where I use an encrypted /tmp, the data usually occupy
more space on that filesystem than would fit in RAM.
This is a simple patch, and merely an extension of an idea that is
already for swap partitions. Perhaps someone could commit it?
--
Shaun Amott // PGP: 0x6B387A9A
"A foolish consistency is the hobgoblin
of little minds." - Ralph Waldo Emerson
Gleb Kurtsou
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi,
>
> I am contentedly using a onetime encrypted swap partition through
> the means provided by rc.d/encswap and fstab, i.e. appending '.eli'
> to the swap partition's name. Since some of the things that accumulate
> in /tmp over the time may contain confidential information, I would
> like to encrypt this partition, too. I know of the clear_tmp_enable
> rc.conf option, but this only deletes /tmp's contents simply by
> utilizing rm(1), which helps but I would not consider this as a
> sufficient solution for the problem of making no longer needed
> /tmp-data unaccessible. So, unless I am missing something, currently
> the only way to go seems to be utilizing geli together with a
> passphrase (and a secret key). Now, for /tmp being a file systems
> for which no guarantee towards persistence across reboots is needed,
> a onetime encryption seems to be the better choice, e.g. no one can
> force you to give away the passphrase or key file.
I'd suggest you trying a stackable cryptographic file system (pefs)
developed as a google summer of code project this year.
Think of it as of nullfs + encryption. No need to create/use separate
partition, etc.
You can create one time passwords on boot and let rc.d scripts clean old
staff:
# pefs mount /tmp /tmp
# dd if=/dev/random bs=16 count=1 | pefs addkey -pv -k - /tmp
I use it to encrypt my home directory for some time already, works
pretty good. It also works on top of tmpfs, if anybody needs it :)
More info: http://gleb.blog.com/tag/pefs/
Recent sources on github: http://github.com/glk/pefs
> While I was looking for a solution, I stumbled upon a patch
> (conf/102700, link below) from 2006 by Shaun Amott (CC'ed) that
> adds support for exactly this kind of encryption. Is there a reason
> why this patch has not made it into the base system yet? I think it
> would be a valuable addition to FreeBSD in regard to security. In
> that context it may be even better to enhance the patch to not only
> support onetime encryption for /tmp, but any kind of file system,
> which a user may specify via fstab. Then, however, the issue of how
> to exactly distinguish between onetime and normal encryption in
> fstab needs to be solved.
>
> Is there maybe another way to achieve onetime /tmp encryption that
> I am missing? Preferably one that does not involve huge changes to
> the default config files to minimize the time spent mergmaster-ing
> these files during an update. This last point is basically what keeps
> me from applying conf/102700 locally or implementing my own solution.
>
>
> Kind regards,
> Daniel
Ulrich Spörlein
> Simon L. Nielsen wrote:
> > On 2009.12.12 23:07:58 +0100, Daniel Thiele wrote:
> >
> >> I am missing? Preferably one that does not involve huge changes to
> >
> > is sometimes not too happy with an e.g. 50MB /tmp, but otherwise it
> > works very well for me.
> >
> > [simon@arthur:~] grep tmp /etc/rc.conf
> > tmpmfs="YES"
> > tmpsize="50M"
> >
>
> partition) also crossed my mind. While a small memory based /tmp may be
> sufficient for most desktop workloads, I don't think that I can chum up
> with it. Especially when you consider that disk space is orders of
> magnitudes cheaper than RAM.
>
> Since the tmpmfs option does not scale well with growing /tmp space
> requirements (at least not in a cost-effective way), I am keen to know
> why the patch I dug up in my first mail has never been committed. Was it
> solely a lack of interest or time, or have there been other reasons?
Either my understanding of the FreeBSD VM is wrong, or you fail to
realize that tmpmfs will be swap-backed, so that disk usage is the same
in both scenarios (but more flexible for the tmpfs).
What I'm saying is that you lose almost nothing of physical RAM if you
set tmpsize=1G and increase your swap accordingly. Once you fill /tmp
with 1G, you will eventually use 1G swap. (medium oversimplification).
Regards,
Uli
Simon L. Nielsen
> Since the tmpmfs option does not scale well with growing /tmp space
> requirements (at least not in a cost-effective way), I am keen to know
> why the patch I dug up in my first mail has never been committed. Was it
> solely a lack of interest or time, or have there been other reasons?
There is no discussion in the audit trail, so I think it's most likely
no committer ever looked that much at it.
I took a brief look, and at the very least the patch is missing an
update to the rc.conf manual page. I'm not entirely convinced the way
the patch goes about creating the devices etc. is the best way to do
it, but I don't see any obvious problems.
That said, personally I unfortunately have too many other things on my
plate to commit the patch.
--
Simon L. Nielsen