Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am just answering another question here :-) and thus had a look – wanted to have a look at /proc/$PID/fd of ssh-agent in order to find out which socket it uses. But I can't. I am quite surprised to notice that most files and directories belong to root. ssh-agent runs as my user (so does its parent process) and is not installed SUID root. I wasn't able to find out where exactly KDE starts it. I am curious; can someone tell my what's happening here?

Or is this not about the user at all, can processes use some kernel magic in order to hide (most of) their /proc info from the public (and even other processes of the same user)?

I just checked the /proc/$PID/fd of all my processes and noticed that ssh-agent is not the only process with this strange attribute. The others are the bunch of Chrome processes and kdesud (no SUID root binary either).

share|improve this question
    
What Linux distro is this? –  slm May 8 '13 at 2:54
    
@slm openSUSE 12.2 –  Hauke Laging May 8 '13 at 15:11
    
I think @msw's answer is the reason. What do you think? –  slm May 8 '13 at 15:26
    
@slm No, it's not. See my comment there. –  Hauke Laging May 8 '13 at 17:52
2  
Since that's not it here's what I was thinking lastnight before I saw @msw's answer. Perhaps it's this: chromium.org/chromium-os/chromiumos-design-docs/…. On that page they discuss cgroups, which seems to be what's going on with Chrome anyway. –  slm May 8 '13 at 18:09

3 Answers 3

Your display manager (lightdm, openbox, etc.) is a child of init which is owned by root. Init isn't set-uid because it's a very special process and is just started with uid of 0. The command ps -eaH gives a structured view of parentage, the relevant bits are:

r    1 ?        00:00:00 init
r 1521 ?        00:00:00   lightdm
r 1531 tty7     00:00:12     Xorg
m 2035 ?        00:00:00     lightdm
m 2177 ?        00:00:00       gnome-session
m 2225 ?        00:00:00         ssh-agent

Where I prepended the owner (Root or Me) of the process. Remember that /proc isn't a real filesystem, but provides file-like access into internal kernel structures and the kernel can set whatever permissions deemed appropriate. Even though 2035 has a real and effective UID of me, the entries in /proc/2035 are owned by root and /proc/2035/fd has permissions 0700 (-r-x------). It isn't until we get to 2177 that I own the pseudo-files in proc because the PPID of 2177 was not UID root.

Why? Because if I was spawned by a root program, some of my files might allow me to leverage into system security. This used to be otherwise as the proc(5) man notes under /proc/sys/fs/protected_hardlinks:

The default value in this file is 0. Setting the value to 1 prevents a longstanding class of security issues caused by hard- link-based time-of-check, time-of-use races, most commonly seen in world-writable directories such as /tmp. The common method of exploiting this flaw is to cross privilege boundaries when following a given hard link (i.e., a root process follows a hard link created by another user). Additionally, on systems without separated partitions, this stops unauthorized users from "pinning" vulnerable set-user-ID and set-group-ID files against being upgraded by the administrator, or linking to special files.

While this note doesn't speak exactly to why the /proc/fd attack vector can be exploited, it does give the feel better than a few thousand lines of code from kernel/fs/proc.

share|improve this answer
    
This is not the correct answer. The session start programs are not called as root. That would be insane from a security perspective. So ssh-agent is not started as root, too. Chrome is not even related to the session start processes. I just checked with sudo: If a process changes its (E)UID then the files in /proc/$PID adapt their owner. All of them. In my case most but not all files (and directories) belong to root. –  Hauke Laging May 8 '13 at 17:52
    
I didn't say they were called as root. I said they inherited their real, effective, saved set, and file system UIDs from the parent. Indeed, until the display manager asks who you are, it can't rightly assign any owner to the process. As I showed above Xorg runs with UID 0, check it out in /proc/n/status. As I also showed above, its subordinate processes run as me. As far as your chrome goes, mine runs as me; what's screwed up with your installation? –  msw May 8 '13 at 20:26
    
What makes you think my installation was screwed up? Chrome does not run as root here but most of its /proc/$PID content is owned by root. I just noticed that this is not even true for the two first Chrome processes but only for chrome-sandbox and its children. –  Hauke Laging May 8 '13 at 20:32
    
hardlink protection has nothing to do with the described issue. –  Ulrich Dangel Jun 3 '13 at 1:18

For chrome the reason is that chrome-sandbox has the suid bit so it runs with root privileges.

Regarding your issue with ssh-agent I am not sure though in my case /usr/bin/ssh-agent has a suid bit set, i.e. the root entries make sense. I don't know how kde handles the ssh-agent but I am pretty sure there is an suid helper involved.

In general there are no magic things, typically a program has to either have a suid bit, explicitly specified the CAPABILITIES or utilize some kind of external helper, either via directly executing it or something like polkit.

As these programs run as root, but dropped then their privileges, you see them running as your user in ps but files are still owned by suid bit owner.

share|improve this answer

/proc is a special pseudo filesystem. From proc(5) (man 5 proc):

   The proc file system is a pseudo-file system which is used as an inter-
   face to kernel data structures.  It is commonly mounted at /proc.  Most
   of  it  is  read-only,  but  some  files  allow  kernel variables to be
   changed.

I recommend reading the complete man page for an explanation.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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