3

I wanted to write a daemon that users can start, and that, every 2 hours, automatically mounts an authenticated network share. The daemon will prompt the user for the password only the first time, and it will keep it mlock()ed then.

My idea was to somehow call the linux program mount(1) (manpage notation). The protocol for the mounting (in my case samba) only allows to give the password via the mount options -o [1]. However, passing the password as a parameter to a shell script makes it visible in the ps-table.

Then, I found out that there's a linux system call mount(2) that takes the same parameters. Is it safe to simply pass the password as plaintext to mount(2)'s parameters?

Things I worry about:

  • mount(2) might be implemented by calling a process where it passes the arguments, including the password. This would leave the password in the ps-table. However, I think system calls won't do that?
  • mount(2) might have its parameters in non-mlock()ed memory, e.g. if the system swaps, the plaintext password is readable on disk. I don't know if a system-calls memory can be swapped, but since the mount call is only active for a short time, I guess this is no real issue.
  • mount(2) might (maybe depending on the file system type) print error or log messages exposing its parameters. (e.g. in system files like /var/log/messages or the dmesg output). At least, I just tested mount(2) with the MS_SILENT flag and did not find any system logs, even on failure.

All in all, how safe is my solution?

Notes: [1] Samba also allows plaintext authentication files or typing the password at a prompt, but that was not useful in my case.

Jedi
  • 3,906
  • 2
  • 24
  • 42
Johannes
  • 165
  • 3
  • Unrelated to the question but you say: *the daemon will prompt the user for the password*. A daemon has normally no user interaction. I assume you meant *the program starting the daemon will ask the user for the password and pass it to the daemon through a pipe* – Serge Ballesta Jan 05 '17 at 17:05
  • Wrong word, what I actually meant was a program that the user would start and which will run in the background until the end of a session. Passing this information to an already running program (deamon) would seem a bit more complicated in terms of security. – Johannes Jan 06 '17 at 00:34

1 Answers1

1

  1. mount(2) might be implemented by calling a process it is just the opposite: mount(1) is a front end ultimately calling mount(2) which being a system call asks the kernel to do the job

  2. mount(2) might have its parameters in non-mlock()ed memory unsure of it, but why do you think that mlock memory is secure? AFAIK root can read /dev/mem and /dev/kmem as (more?) easily as the content of the swap partition...

  3. mount(2) might (maybe depending on the file system type) print error or log messages exposing its parameters it would indeed be a security threat, and I do not know any network mount utility ever logging a password in clear text. Anyway as said in 1, any attempt to mount the network share will ultimately end in a mount(2) call so you cannot avoid it.

TL/DR: it is far more secure to call mount(2) that starting a subprocess to call mount(1) because the parameters passed to the subprocess command will be accessible through the process table and can be displayed with ps with the appropriate options and the error condition processing will be much simpler.

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • you say calling `mount(2)` is more secure than calling `mount(1)`, but is it "secure enough"/good practice? – Johannes Jan 05 '17 at 18:10
  • @Johannes: You can safely use all functions from the standard library (3) and all system calls (2) in your code. Just read carefully the man pages, it there is a caveat, it will be referenced. As a rule of thumb, use commands (1) and (8) when you develop shells and functions (3) and (2) when you develop C (or C++) programs – Serge Ballesta Jan 05 '17 at 18:35