通过管道传输的数据是否保密?

jun*_*jun 6 security pipe

我阅读了以下问题(Shell Script mktemp,创建临时命名管道的最佳方法是什么?)但我想知道是否最好使用临时命名管道在程序之间传输敏感数据而不是未命名/匿名 shell管道?

具体来说,我对这种方法是否感兴趣(来自http://blog.kdecherf.com/2012/11/06/mount-a-luks-partition-with-a-password-protected-gpg-encrypted-key -using-systemd/ ) 是安全的:

# Open the encrypted block device
gpg --batch --decrypt $key_file 2>/dev/null | sudo $CRYPTSETUP -d - luksOpen $mount_device $key >& /dev/null || exit 3
Run Code Online (Sandbox Code Playgroud)

在哪些情况下可以劫持 Luks 密钥文件?

Cel*_*ada 9

您建议的命令行是安全的。

在所有其他条件相同的情况下,“普通”匿名管道(使用pipe(2)系统调用或 shell 熟悉的|语法创建)总是比命名管道更安全,因为系统外的其他东西获得其中任何一个的方法更少管的末端。对于普通的匿名管道,如果您已经拥有管道的文件描述符,则只能从管道读取或写入,这意味着您必须是创建管道的进程,或者必须(直接或间接)继承它来自该进程,或者某个具有文件描述符的进程故意通过套接字将其发送给您。对于命名管道,如果您还没有通过按名称打开管道的文件描述符,则可以获取该管道的文件描述符。

在像 Linux 这样的操作系统上,/proc总是有可能另一个进程可以窥视/proc/pid/fd属于不同进程的访问文件描述符,但这并不是管道(任何类型)独有的,就此而言,它们可以窥视另一个进程的内存空间也是如此。“窥视者”必须在与主题或 root 相同的用户下运行,因此这不是安全问题。

  • @JeffreyBlattman 从您的意思来看,您永远不能“意外”使用不“属于”您的 FD。如果您不是打开管道的进程,并且您没有通过任何其他方式收到管道的文件描述符(如我的回答中所述),那么您的文件描述符就没有指定该管道的文件描述符。将文件描述符视为指向代表管道的内核对象的指针。如果内核从来没有给你一个指向相关对象的指针,你就不能指向它。这不是默默无闻的安全。 (2认同)
  • @JeffreyBlattman 通过套接字传输文件描述符有效,因为内核参与其中。它是通过一个特殊的系统调用(带有辅助数据的`sendmsg`)完成的,它请求内核获取一个文件(由文件描述符指定,因为这是你指定文件的方式),并使其可用于从套接字中读取它的任何进程在另一端。从接收者的角度来看,只是因为内核同意给你一个与该文件对应的文件描述符,你才能得到一个。否则,您“没有指针”。 (2认同)