5

I read the following question (Shell Script mktemp, what's the best method to create temporary named pipe?) but I'm wondering whether it is preferable to use a temporary named pipe to transfer sensitive data between programs as opposed to an unnamed/anonymous shell pipe?

Specifically I'm interested in whether this type of approach (from http://blog.kdecherf.com/2012/11/06/mount-a-luks-partition-with-a-password-protected-gpg-encrypted-key-using-systemd/) is safe:

# Open the encrypted block device
gpg --batch --decrypt $key_file 2>/dev/null | sudo $CRYPTSETUP -d - luksOpen $mount_device $key >& /dev/null || exit 3

In which cases could the Luks Keyfile be hijacked?

Improve this question
8

The command line you are suggesting is secure.

All other things being equal, "normal" anonymous pipes (created with the pipe(2) system call or the shell's familiar | syntax) are always going to be more secure than named pipes because there are fewer ways for something else outside the system to get ahold of either one of the ends of the pipe. For normal anonymous pipes, you can only read or write from the pipe if you already have in your possession a file descriptor for it, which means you must either be the process that created the pipe, or must have inherited it (directly or indirectly) from that process, or some process that had the file descriptor deliberately sent it to you through a socket. For named pipes, you can obtain a file descriptor to the pipe if you don't have one already by opening it by name.

On operating systems like Linux that have /proc there is always the possibility that another process can peek into /proc/pid/fd an access file descriptors belonging to a different process, but this is nothing unique to pipes (of whatever kind), and for that matter they can peek into another process' memory space too. The "peeker" must be either running under the same user as the subject or root, so it's not a security problem.

Improve this answer
  • Sorry to raise the dead, but why is it secure? Does this boil down to security via obscurity? The return value from pipe(2) is two ints. Suppose I write a program to continually try to open random integers. Maybe taking advantage of some pattern in their creation. Isn't it feasible I could eventually open an FD that didn't "belong" to me? – Jeffrey Blattman Oct 31 '16 at 14:38
  • 2
    @JeffreyBlattman You can't ever "accidentally" use an FD that doesn't "belong" to you, in the sense that you mean. If you aren't the process that opened the pipe and you didn't receive a file descriptor for the pipe through any other means (as described in my answer), then there is no file descriptor of yours that designates that pipe. Think of a file descriptor as a pointer to the the in-kernel object that represents the pipe. If the kernel has never at any point given you a pointer to the object in question, you can't point to it. It's not security by obscurity. – Celada Nov 1 '16 at 22:25
  • Thank you for for your explanation so far. "If the kernel has never at any point given you a pointer to the object in question, you can't point to it"- Why? Does the kernel protect it via process ID (I don't think so). What's the difference between it being sent over a socket (or any other xfer method), and another process "guessing" it? What's special about it going through a socket that makes it usable by the other process? What prevents a process from using it if it "guesses" the value of the FD? – Jeffrey Blattman Nov 2 '16 at 17:47
  • 2
    @JeffreyBlattman transmitting a file descriptor over a socket works because the kernel gets involved. It's done with a special system call (sendmsg with ancillary data attached) which requests that the kernel take a file (designated by a file descriptor because that's how you designate files) and make it available to whichever process reads it out of the socket at the other end. From the receiver's perspective, it's only because the kernel agrees to give you a file descriptor corresponding to that file that you can get one. Otherwise, you "don't have a pointer". – Celada Nov 2 '16 at 20:38
  • 1
    Okay I get it. FDs are per-process. You can't just send one it to another process. You have to involve the kernel as an intermediary to "tunnel" the data. The kernel creates the conduit. Thank you. – Jeffrey Blattman Nov 2 '16 at 22:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.