Re: Change proc file permissions with sysctls
>> The permissions of files in /proc/1 (usually belonging to init) are >> kept as they are. The idea is to let system processes be freely >> visible by anyone, just as before. Especially interesting in this >> regard would be instances of login. I don't know how to easily >> discriminate between system processes and "normal" processes inside >> the kernel (apart from pid == 1 and uid == 0 (which is too broad)). >> Any ideas? As a side note, I have not experienced any problems when also "hiding" system processes by making e.g. /proc/1 mode 0700. Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][0/6] Change proc file permissions with sysctls
On Sun, 2005-03-20 at 01:22 +0100, Rene Scharfe wrote: > The permissions of files in /proc/1 (usually belonging to init) are > kept as they are. The idea is to let system processes be freely > visible by anyone, just as before. Especially interesting in this > regard would be instances of login. I don't know how to easily > discriminate between system processes and "normal" processes inside > the kernel (apart from pid == 1 and uid == 0 (which is too broad)). > Any ideas? The ideal would be to allow viewing: 1. killable processes (that is, YOU can kill them) 2. processes sharing a tty with a killable process Optionally, add: 3. processes controlling a tty master of a killable process 4. ancestors of all of the above 5. children of killable processes This is of course expensive, but maybe you can get some of it cheaply. For example, allow viewing a process if the session leader, group leader, parent, or tpgid process is killable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][0/6] Change proc file permissions with sysctls
On Sun, 20 Mar 2005, Rene Scharfe wrote: > The permissions of files in /proc/1 (usually belonging to init) are > kept as they are. The idea is to let system processes be freely > visible by anyone, just as before. Especially interesting in this > regard would be instances of login. I think you mean login shells, the login process is just the thing asking for the password agter the (m)ingetty got the username. These processes are usurally created with the '-' sign in argv[0][0], but the users may replace that string at will. I think it's still OK to depend on that if you want a semi-secure system. > I don't know how to easily > discriminate between system processes and "normal" processes inside > the kernel (apart from pid Do you mean ppid? > == 1 and uid == 0 (which is too broad)). > Any ideas? This feature seems to be frequently requested. I don't remember the outcome, though. >From a quick view, it seems the symlinks in /proc are empty for kernel threads and non-empty for user processes. Since you're messing with the proc entries, this could be a cheap way to find the kernel threads. Another possibility is by looking at the blocked signals, signal 9 may not be blocked by mortals. For the system daemons, you could additionally check for the absence of a controlling tty, but that's still no safe distinction from a process run by nohup. Checking for sid=pid will filter additional processes, but it the shell in midnight commander and screen are still false positives. Checking for */sbin*/ in $PID/command will fail as soon as the daemon overwrites argv[0]. I don't think there is a relaible way to tell the system service daemons from screen except for the name, and you'll want to detect screen-alike programs, too. -- Top 100 things you don't want the sysadmin to say: 40. The sprinkler system isn't supposed to leak is it? Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][0/6] Change proc file permissions with sysctls
The following patches implement another interface that allows an admin to restrict permissions inside /proc/ to enhance the privacy of users. Following a suggestion by Albert Calahan this set of patches introduces five sysctls, each one changes the permissions of a certain file in /proc/. It works by implementing getattr and permission methods that update the files' permissions (btw. Al Viro suggested doing it this way right from the start..). To "cloak" as much as currently possible: # sysctl -q proc.cmdline=0400 # sysctl -q proc.maps=0400 # sysctl -q proc.stat=0400 # sysctl -q proc.statm=0400 # sysctl -q proc.status=0400 This will set the permissions of /proc/*/cmdline etc. to the given value. The permissions of files in /proc/1 (usually belonging to init) are kept as they are. The idea is to let system processes be freely visible by anyone, just as before. Especially interesting in this regard would be instances of login. I don't know how to easily discriminate between system processes and "normal" processes inside the kernel (apart from pid == 1 and uid == 0 (which is too broad)). Any ideas? It's easy to make more files' permissions configurable, if the need arises. This implementation is a lot bigger than the quick hacks I sent earlier. Is this feature growing too fat? Also I'm unsure about the #ifdef'ery in fs/proc/base.c, I just wanted to be consistent with the surrounding code. :-P Rene - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
