CODEWITHSUNDEEP
linuxsecuritylinux-kernelexecfork
Bhuvan
Bhuvan

Reputation: 4187

Is linux fork insecure

I was reading this article

It says that the fork create a copy of itself and fork man also says so

. The entire virtual address space of the parent is replicated in the child

Does this mean child process can read all my process memory state ?

Can child process dump the entire parent memory state and it can be analysed to extract parent variable and its value. ?

But the article also says that two process cannot ready each other data. So i am confused ?

Upvotes: 4

Views: 1138

Answers (2)

Basile Starynkevitch
Basile Starynkevitch

Reputation: 1

Yes, the child process can read a pristine copy of all of the parent process state (but when writing, only its own address space is affected) just after a fork(2). However, most of the time, the child would eventually use execve(2) to start a new program, and that would "clear" and replace the copy of the original parent's address space (by a fresh address space). Notice that execve and mmap(2) (see also shared memory in shm_overview(7)...) are the common ways to change the address space in virtual memory of some process (and how the kernel handles page faults).

The kernel uses (and sets up the MMU for) lazy copy on write machinery to make the child's address space a copy of the parent's one, so fork is quite efficient in practice.

Read also proc(5), then type the follow commands:

cat /proc/self/maps
cat /proc/$$/maps
sudo cat /proc/1/maps

and understand what is happening

Read also the wikipage on fork, and the Advanced Linux Programming book.

There is no insecurity, because if the child is changing some data (e.g. a variable, a heap or stack location, ...) it does not affect the parent process.

If the program doing the fork is keeping some password in some virtual memory location, the child process would be able to read that location as long as it is executing the same program. Once the child did a successful execve (which is the common situation, and what any shell is doing) the previous address space is gone and replaced by a new one, described in the ELF executable of that exec-ed program.

There is no "lie" or "insecurity" in that Unix model. But contrarily to several other operating systems, Unix & POSIX have two separate system calls for creating a new process (fork) and executing a new program (execve). Other systems might have some single spawn operation mixing the two abilities. posix_spawn is often implemented by a mixture of fork & execve (and so are system(3) & popen(3), also using waitpid(2) & /bin/sh....).

The advantage of that Unix approach (having separated fork & execve) is that after the fork and before the execve in the child you can do a lot of useful things (e.g. closing useless file descriptors, ...). Operating Systems not separating the two features may need to have a quite complex spawning primitive.

There are rare occasions where a fork is not followed by some execve. Some MPI implementations might do that, and you might also do that. But then you know that you are able to read all the parent's address space thru your own copy - so what you felt was an insecurity is becoming a useful feature. In the old days you had the obsolete vfork which blocked the parents. There is not need to use it today; actually, fork is often implemented thru clone(2) which you should not use directly in practice (see futex(7)...) but only thru POSIX pthreads. But thinking of fork as a magical cloner of your process might help.

When coding (even in C) don't forget to test against failure of fork and of execve. See perror(3)

PS. the fork syscall is as difficult to understand as the multiverse idea. Both are "forking" the time!

Upvotes: 4

kamituel
kamituel

Reputation: 35970

When you call fork(), the new process will get access to the copy of the parent process memory (i.e. variables, file descriptors etc).

This is in contrast with threads, where all threads share the same memory space, i.e. variable modified in one thread will get a new value in all other threads.

So if, after forking, parent process modifies memory, the child process will not see that change - because the memory has been copied, the child process' memory would not get altered.

Upvotes: 2

Related Questions