已解决 btrfs有严重的安全隐患

[anth]

偶然发现btrfs snapshot可以穿透挂载限制 也就是说snapshot只是不能穿透其他子卷 但是挂载过的任何东西 无论是u盘还是虚拟盘 无论是加密不加密 通通现出原形

在snap文件夹找旧脚本 无意中翻出了密钥 这个密钥从来不上电脑 放在加密u盘的加密虚拟磁盘上 依然明文显示了

这个问题并不是简单的系统错误 每个子系统都没错 加密解密模块非常安全 磁盘luks加密安全 u盘不联网是安全的 合在一起就挂了 关键问题是系统安全不高的前提下其他都是徒劳的 举个例子 luks是有提供isluks函数了 就是说很容易用ls和cryptsetup遍历全盘现出虚拟磁盘 众所周知 人脑一般不记长密码 只要虚拟磁盘位置暴露 luks磁盘破解只是时间问题 或者换个思路 守株待兔 用inode监控看住/dev/mapper目录 只要有变动就启用df命令找位置 一抓一个准

所以必须加密 多层加密之后至少一个要永远不挂载 那么就必须有一个新的解密手段来完成私钥的使用工作 这很困难 可以考虑iPhone新开发一个rsa解密 投入的时间和钱都不少 不现实 如果最后还是用电脑使用私钥 那么只要挂载 所有的准备都是没有意义的

还有最后一个办法 人脑是不过文件系统的 大部分的入侵针对硬盘并不监控内存 所以用复杂口令加密私钥好像是最后的办法了 顺便系统切回ext4 数据盘留在btrfs 确保挂载点无法snapshot 好麻烦

[astolia]

你说的问题跟btrfs有个屁关系，照你的思路，一切可以复制文件的程序都有安全隐患了。你该反思的是为什么没有把加密分区的快照放到同一个u盘的加密分区上，或者更进一步的为什么要进行快照操作

[anth]

我并没有给加密分区拍照 只是给系统拍照的时候恰好u盘的加密数据是挂载的 感觉btrfs可以直接保留挂载点 这个实在有点牛逼

[astolia]

btrfs在snapshot的时候不可能保存其他挂载点上的数据，从原理和实践上都是如此

代码： 全选

# ls -l
总用量 20
drwxr-xr-x  1 root root    0 Apr  1 09:38 ./
drwxr-xr-x 19 root root 4096 Dec 23 10:55 ../
# btrfs subvolume create test
Create subvolume './test'
# mkdir test/m
# mount /dev/sda1 test/m
# ls test/m
bin   cdrom  etc   lib    lib64       media  opt   root  sbin  sys  usr
boot  dev    home  lib32  lost+found  mnt    proc  run   srv   tmp  var
# btrfs subvolume snapshot test test1
Create a snapshot of 'test' in './test1'
# ls -l test1/m/
总用量 0

你最好再仔细调查一下是什么原因

[anth]

为了安全已经删除快照了 很难直接给你证明 但是备份脚本还在 我洗完澡待会再审查代码 尽快把错误复现出来

当时检查的结果是可以穿透挂载点一层主目录一层子目录 争取尽快复现出来

[anth]

复现出来了 居然是低级错误 很隐蔽

备份脚本自动向挂载点发文件 生成非对称加密密钥那次没接u盘动用了备份脚本 当时没有发现 也没重视 随后接u盘 u盘改luks加密 另外再隐藏luks加密虚拟磁盘 所有全部完成之后都没发现第一步就错了 挂载点是不是空目录 由于平时使用是调用解密脚本 不会再出现不挂载就进入挂载点的情况 所以一直没发现挂载点不是空的

刚才snapshot直接发现私钥又明文泄露了 由于我已经更改算法 已经不再保留明文私钥 所以第一时间意识到不是来源于u盘

[anth]

这个问题其实还是需要接着说

我的备份函数是backup 只有三行 分别是调用back2btr back2usb back2email 由于脚本修补之后会下意识备份到网上 会顺路调用back2usb函数 这就是错误的根源

解决方法是加一行判断语句 用df或者test -s来判断挂载点状态

另外 back2usb是用rsync写的 和btrfs无关 幸好没切回ext4 不然又折腾了 这两天加密算法改了又改 基本全是全部完工了 也算是塞翁失马