Re: [PATCH] add umask parameter to procfs
On Fri, Feb 18, 2005 at 04:56:01AM +0100, Herbert Poetzl wrote: > hmm, so what about debugger and similar not able to find the > parent process or something like that? You can walk the parentage chain up until you reach your login shell. So you can look up info about the parent of every one of your processes except for your login shell and any zombies. > I'd say this needs some more investigation what tools and > applications will break once it is enabled ... Sure, that can't be bad. I didn't really do anything so far that warrants being called testing (compiles, runs, doesn't crash on boot -- send patch! ;). But I also didn't invent this feature: it has been in OpenWall and grsecurity for a long time now, so a form of restricted /proc has received at least *some* testing. 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/
Re: [PATCH] add umask parameter to procfs
On Thu, Feb 17, 2005 at 03:41:19PM -0800, Andrew Morton wrote:
> The feature seems fairly obscure, although very simple. Is anyone actually
> likely to use this?
Yes, it's an obscure obscurity feature. :) There certainly seems to be
some interest in it: both GrSecurity and OpenWall contain something
similar. They set the mask at compile time, though. But being able to
change it at boot time makes it much easier for mainstream distros to
include it in their kernels.
Personally I felt the need for the feature when I was a student sharing
a server with hundreds others. Sure, it's not very useful on machines
offering no shell access at all.
> > +static umode_t umask = 0;
>
> a) I think the above should be called proc_umask.
>
> b) You shouldn't initialise it.
>
> c) When adding a kernel parameter you should update
>Documentation/kernel-parameters.txt
Like below?
Hrm, maybe the option should be named pidumask instead of simply umask?
diff -urp linux-2.6.11-rc4/Documentation/kernel-parameters.txt
linux-2.6.11-rc4+/Documentation/kernel-parameters.txt
--- linux-2.6.11-rc4/Documentation/kernel-parameters.txt2005-02-11
21:16:00.0 +0100
+++ linux-2.6.11-rc4+/Documentation/kernel-parameters.txt 2005-02-12
01:37:42.0 +0100
@@ -1037,16 +1037,19 @@ running once the system is up.
[ISAPNP] Exclude memory regions for the
autoconfiguration
Ranges are in pairs (memory base and size).
+ processor.max_cstate= [HW, ACPI]
+ Limit processor to maximum C-state
+ max_cstate=9 overrides any DMI blacklist limit.
+
+ proc.umask= [KNL] Restrict permissions of process specific
+ entries in /proc (i.e. the numerical directories).
+
profile=[KNL] Enable kernel profiling via /proc/profile
{ schedule | }
(param: schedule - profile schedule points}
(param: profile step/bucket size as a power of 2 for
statistical time based profiling)
- processor.max_cstate= [HW, ACPI]
- Limit processor to maximum C-state
- max_cstate=9 overrides any DMI blacklist limit.
-
prompt_ramdisk= [RAM] List of RAM disks to prompt for floppy disk
before loading.
See Documentation/ramdisk.txt.
diff -urp linux-2.6.11-rc4/fs/proc/base.c linux-2.6.11-rc4+/fs/proc/base.c
--- linux-2.6.11-rc4/fs/proc/base.c 2005-02-11 21:16:13.0 +0100
+++ linux-2.6.11-rc4+/fs/proc/base.c2005-02-12 01:33:14.0 +0100
@@ -32,8 +32,14 @@
#include
#include
#include
+#include
+#include
#include "internal.h"
+static umode_t proc_umask;
+module_param_named(umask, proc_umask, ushort, 0);
+MODULE_PARM_DESC(umask, "umask for the numerical directories in /proc");
+
/*
* For hysterical raisins we keep the same inumbers as in the old procfs.
* Feel free to change the macro below - just keep the range distinct from
@@ -1369,7 +1375,7 @@ static struct dentry *proc_pident_lookup
goto out;
ei = PROC_I(inode);
- inode->i_mode = p->mode;
+ inode->i_mode = p->mode & ~(proc_umask & S_IALLUGO);
/*
* Yes, it does not scale. And it should not. Don't add
* new entries into /proc// without very good reasons.
@@ -1699,7 +1705,7 @@ struct dentry *proc_pid_lookup(struct in
put_task_struct(task);
goto out;
}
- inode->i_mode = S_IFDIR|S_IRUGO|S_IXUGO;
+ inode->i_mode = S_IFDIR | ((S_IRUGO|S_IXUGO) & ~proc_umask);
inode->i_op = _tgid_base_inode_operations;
inode->i_fop = _tgid_base_operations;
inode->i_nlink = 3;
@@ -1754,7 +1760,7 @@ static struct dentry *proc_task_lookup(s
if (!inode)
goto out_drop_task;
- inode->i_mode = S_IFDIR|S_IRUGO|S_IXUGO;
+ inode->i_mode = S_IFDIR | ((S_IRUGO|S_IXUGO) & ~proc_umask);
inode->i_op = _tid_base_inode_operations;
inode->i_fop = _tid_base_operations;
inode->i_nlink = 3;
-
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] add umask parameter to procfs
On Thu, Feb 17, 2005 at 03:41:19PM -0800, Andrew Morton wrote:
The feature seems fairly obscure, although very simple. Is anyone actually
likely to use this?
Yes, it's an obscure obscurity feature. :) There certainly seems to be
some interest in it: both GrSecurity and OpenWall contain something
similar. They set the mask at compile time, though. But being able to
change it at boot time makes it much easier for mainstream distros to
include it in their kernels.
Personally I felt the need for the feature when I was a student sharing
a server with hundreds others. Sure, it's not very useful on machines
offering no shell access at all.
+static umode_t umask = 0;
a) I think the above should be called proc_umask.
b) You shouldn't initialise it.
c) When adding a kernel parameter you should update
Documentation/kernel-parameters.txt
Like below?
Hrm, maybe the option should be named pidumask instead of simply umask?
diff -urp linux-2.6.11-rc4/Documentation/kernel-parameters.txt
linux-2.6.11-rc4+/Documentation/kernel-parameters.txt
--- linux-2.6.11-rc4/Documentation/kernel-parameters.txt2005-02-11
21:16:00.0 +0100
+++ linux-2.6.11-rc4+/Documentation/kernel-parameters.txt 2005-02-12
01:37:42.0 +0100
@@ -1037,16 +1037,19 @@ running once the system is up.
[ISAPNP] Exclude memory regions for the
autoconfiguration
Ranges are in pairs (memory base and size).
+ processor.max_cstate= [HW, ACPI]
+ Limit processor to maximum C-state
+ max_cstate=9 overrides any DMI blacklist limit.
+
+ proc.umask= [KNL] Restrict permissions of process specific
+ entries in /proc (i.e. the numerical directories).
+
profile=[KNL] Enable kernel profiling via /proc/profile
{ schedule | number }
(param: schedule - profile schedule points}
(param: profile step/bucket size as a power of 2 for
statistical time based profiling)
- processor.max_cstate= [HW, ACPI]
- Limit processor to maximum C-state
- max_cstate=9 overrides any DMI blacklist limit.
-
prompt_ramdisk= [RAM] List of RAM disks to prompt for floppy disk
before loading.
See Documentation/ramdisk.txt.
diff -urp linux-2.6.11-rc4/fs/proc/base.c linux-2.6.11-rc4+/fs/proc/base.c
--- linux-2.6.11-rc4/fs/proc/base.c 2005-02-11 21:16:13.0 +0100
+++ linux-2.6.11-rc4+/fs/proc/base.c2005-02-12 01:33:14.0 +0100
@@ -32,8 +32,14 @@
#include linux/mount.h
#include linux/security.h
#include linux/ptrace.h
+#include linux/module.h
+#include linux/moduleparam.h
#include internal.h
+static umode_t proc_umask;
+module_param_named(umask, proc_umask, ushort, 0);
+MODULE_PARM_DESC(umask, umask for the numerical directories in /proc);
+
/*
* For hysterical raisins we keep the same inumbers as in the old procfs.
* Feel free to change the macro below - just keep the range distinct from
@@ -1369,7 +1375,7 @@ static struct dentry *proc_pident_lookup
goto out;
ei = PROC_I(inode);
- inode-i_mode = p-mode;
+ inode-i_mode = p-mode ~(proc_umask S_IALLUGO);
/*
* Yes, it does not scale. And it should not. Don't add
* new entries into /proc/tgid/ without very good reasons.
@@ -1699,7 +1705,7 @@ struct dentry *proc_pid_lookup(struct in
put_task_struct(task);
goto out;
}
- inode-i_mode = S_IFDIR|S_IRUGO|S_IXUGO;
+ inode-i_mode = S_IFDIR | ((S_IRUGO|S_IXUGO) ~proc_umask);
inode-i_op = proc_tgid_base_inode_operations;
inode-i_fop = proc_tgid_base_operations;
inode-i_nlink = 3;
@@ -1754,7 +1760,7 @@ static struct dentry *proc_task_lookup(s
if (!inode)
goto out_drop_task;
- inode-i_mode = S_IFDIR|S_IRUGO|S_IXUGO;
+ inode-i_mode = S_IFDIR | ((S_IRUGO|S_IXUGO) ~proc_umask);
inode-i_op = proc_tid_base_inode_operations;
inode-i_fop = proc_tid_base_operations;
inode-i_nlink = 3;
-
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] add umask parameter to procfs
On Fri, Feb 18, 2005 at 04:56:01AM +0100, Herbert Poetzl wrote: hmm, so what about debugger and similar not able to find the parent process or something like that? You can walk the parentage chain up until you reach your login shell. So you can look up info about the parent of every one of your processes except for your login shell and any zombies. I'd say this needs some more investigation what tools and applications will break once it is enabled ... Sure, that can't be bad. I didn't really do anything so far that warrants being called testing (compiles, runs, doesn't crash on boot -- send patch! ;). But I also didn't invent this feature: it has been in OpenWall and grsecurity for a long time now, so a form of restricted /proc has received at least *some* testing. 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/
Re: [PATCH] add umask parameter to procfs
On Fri, Feb 18, 2005 at 04:22:49AM +0100, Bodo Eggert wrote: > Herbert Poetzl <[EMAIL PROTECTED]> wrote: > > On Thu, Feb 17, 2005 at 03:41:19PM -0800, Andrew Morton wrote: > >> Rene Scharfe <[EMAIL PROTECTED]> wrote: > > >> > Add proc.umask kernel parameter. It can be used to restrict permissions > >> > on the numerical directories in the root of a proc filesystem, i.e. the > >> > directories containing process specific information. > >> > > >> > E.g. add proc.umask=077 to your kernel command line and all users except > >> > root can only see their own process details (like command line > >> > parameters) with ps or top. It can be useful to add a bit of privacy to > >> > multi-user servers. > > >> The feature seems fairly obscure, although very simple. > >> Is anyone actually likely to use this? > > I'm using a openwall-patched kernel on some of my boxes with a similar > feature. I did not yet test this patch, but I like it. It's cheap, and > it fixes a potential security leak. don't get me wrong, I'm all for something like this, as a matter of fact we are using something more specialized for linux-vserver to hide processes between contexts ... > > what about parents (and especially the init process) > > some tools like pstree (or ps in certain cases) depend > > on their visibility/accessability ... > > pstree will break if /proc/1 isn't readable, unless you specify a readable > starting pid. Since this is not the default case, this is IMO ok. (It should > be easy to rewrite it to trace the ppid-chains like "ps auxf" already does > correctly, or rather implement it in ps where it belongs). hmm, so what about debugger and similar not able to find the parent process or something like that? I'd say this needs some more investigation what tools and applications will break once it is enabled ... > None of my other tools seemed to stop working in an unintended way, but I > don't usurally spend my time watching processes. > > Sample output of "ps auxf" on a openwall-patched system: > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > 7eggert 22504 5.0 3.5 2800 1608 pts/4S04:14 0:00 -bash > 7eggert 22522 0.0 1.7 2856 792 pts/4R04:14 0:00 \_ ps auxf > 7eggert 22483 2.3 3.4 2800 1588 pts/2S04:14 0:00 -bash > > > what if you want to change it afterwards (when tools > > did break)? > > Change the kernel command line back and reboot (or reload the module). hmm, reload the procfs module? not very likely ;) best, Herbert - 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] add umask parameter to procfs
Herbert Poetzl <[EMAIL PROTECTED]> wrote: > On Thu, Feb 17, 2005 at 03:41:19PM -0800, Andrew Morton wrote: >> Rene Scharfe <[EMAIL PROTECTED]> wrote: >> > Add proc.umask kernel parameter. It can be used to restrict permissions >> > on the numerical directories in the root of a proc filesystem, i.e. the >> > directories containing process specific information. >> > >> > E.g. add proc.umask=077 to your kernel command line and all users except >> > root can only see their own process details (like command line >> > parameters) with ps or top. It can be useful to add a bit of privacy to >> > multi-user servers. >> The feature seems fairly obscure, although very simple. >> Is anyone actually likely to use this? I'm using a openwall-patched kernel on some of my boxes with a similar feature. I did not yet test this patch, but I like it. It's cheap, and it fixes a potential security leak. > what about parents (and especially the init process) > some tools like pstree (or ps in certain cases) depend > on their visibility/accessability ... pstree will break if /proc/1 isn't readable, unless you specify a readable starting pid. Since this is not the default case, this is IMO ok. (It should be easy to rewrite it to trace the ppid-chains like "ps auxf" already does correctly, or rather implement it in ps where it belongs). None of my other tools seemed to stop working in an unintended way, but I don't usurally spend my time watching processes. Sample output of "ps auxf" on a openwall-patched system: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 7eggert 22504 5.0 3.5 2800 1608 pts/4S04:14 0:00 -bash 7eggert 22522 0.0 1.7 2856 792 pts/4R04:14 0:00 \_ ps auxf 7eggert 22483 2.3 3.4 2800 1588 pts/2S04:14 0:00 -bash > what if you want to change it afterwards (when tools > did break)? Change the kernel command line back and reboot (or reload the module). - 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] add umask parameter to procfs
On Thu, Feb 17, 2005 at 03:41:19PM -0800, Andrew Morton wrote: > Rene Scharfe <[EMAIL PROTECTED]> wrote: > > > > Add proc.umask kernel parameter. It can be used to restrict permissions > > on the numerical directories in the root of a proc filesystem, i.e. the > > directories containing process specific information. > > > > E.g. add proc.umask=077 to your kernel command line and all users except > > root can only see their own process details (like command line > > parameters) with ps or top. It can be useful to add a bit of privacy to > > multi-user servers. > > > > The patch has been inspired by a similar feature in GrSecurity. > > > > It could have also been implemented as a mount option to procfs, but at > > a higher cost and no apparent benefit -- changes to this umask are not > > supposed to happen very often. Actually, the previous incarnation of > > this patch was implemented as a half-assed mount option, but I didn't > > know then how easy it is to add a kernel parameter. > > The feature seems fairly obscure, although very simple. > Is anyone actually likely to use this? what about parents (and especially the init process) some tools like pstree (or ps in certain cases) depend on their visibility/accessability ... was this tested except for the trivial case where just plain everything is visible? what if you want to change it afterwards (when tools did break)? best, Herbert > > +static umode_t umask = 0; > > a) I think the above should be called proc_umask. > > b) You shouldn't initialise it. > > c) When adding a kernel parameter you should update >Documentation/kernel-parameters.txt > - > 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/ - 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] add umask parameter to procfs
Rene Scharfe <[EMAIL PROTECTED]> wrote: > > Add proc.umask kernel parameter. It can be used to restrict permissions > on the numerical directories in the root of a proc filesystem, i.e. the > directories containing process specific information. > > E.g. add proc.umask=077 to your kernel command line and all users except > root can only see their own process details (like command line > parameters) with ps or top. It can be useful to add a bit of privacy to > multi-user servers. > > The patch has been inspired by a similar feature in GrSecurity. > > It could have also been implemented as a mount option to procfs, but at > a higher cost and no apparent benefit -- changes to this umask are not > supposed to happen very often. Actually, the previous incarnation of > this patch was implemented as a half-assed mount option, but I didn't > know then how easy it is to add a kernel parameter. The feature seems fairly obscure, although very simple. Is anyone actually likely to use this? > > +static umode_t umask = 0; a) I think the above should be called proc_umask. b) You shouldn't initialise it. c) When adding a kernel parameter you should update Documentation/kernel-parameters.txt - 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] add umask parameter to procfs
Add proc.umask kernel parameter. It can be used to restrict permissions on the numerical directories in the root of a proc filesystem, i.e. the directories containing process specific information. E.g. add proc.umask=077 to your kernel command line and all users except root can only see their own process details (like command line parameters) with ps or top. It can be useful to add a bit of privacy to multi-user servers. The patch has been inspired by a similar feature in GrSecurity. It could have also been implemented as a mount option to procfs, but at a higher cost and no apparent benefit -- changes to this umask are not supposed to happen very often. Actually, the previous incarnation of this patch was implemented as a half-assed mount option, but I didn't know then how easy it is to add a kernel parameter. Comments about usefulness or implementation are very welcome. Thanks, Rene --- linux-2.6.11-rc4/fs/proc/base.c~2005-02-11 21:16:13.0 +0100 +++ linux-2.6.11-rc4/fs/proc/base.c 2005-02-11 23:38:17.0 +0100 @@ -32,8 +32,14 @@ #include #include #include +#include +#include #include "internal.h" +static umode_t umask = 0; +module_param(umask, ushort, 0); +MODULE_PARM_DESC(umask, "umask for the numerical directories in /proc"); + /* * For hysterical raisins we keep the same inumbers as in the old procfs. * Feel free to change the macro below - just keep the range distinct from @@ -1369,7 +1375,7 @@ static struct dentry *proc_pident_lookup goto out; ei = PROC_I(inode); - inode->i_mode = p->mode; + inode->i_mode = p->mode & ~(umask & S_IRWXUGO); /* * Yes, it does not scale. And it should not. Don't add * new entries into /proc// without very good reasons. @@ -1699,7 +1705,7 @@ struct dentry *proc_pid_lookup(struct in put_task_struct(task); goto out; } - inode->i_mode = S_IFDIR|S_IRUGO|S_IXUGO; + inode->i_mode = S_IFDIR | ((S_IRUGO|S_IXUGO) & ~umask); inode->i_op = _tgid_base_inode_operations; inode->i_fop = _tgid_base_operations; inode->i_nlink = 3; @@ -1754,7 +1760,7 @@ static struct dentry *proc_task_lookup(s if (!inode) goto out_drop_task; - inode->i_mode = S_IFDIR|S_IRUGO|S_IXUGO; + inode->i_mode = S_IFDIR | ((S_IRUGO|S_IXUGO) & ~umask); inode->i_op = _tid_base_inode_operations; inode->i_fop = _tid_base_operations; inode->i_nlink = 3; - 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] add umask parameter to procfs
Add proc.umask kernel parameter. It can be used to restrict permissions on the numerical directories in the root of a proc filesystem, i.e. the directories containing process specific information. E.g. add proc.umask=077 to your kernel command line and all users except root can only see their own process details (like command line parameters) with ps or top. It can be useful to add a bit of privacy to multi-user servers. The patch has been inspired by a similar feature in GrSecurity. It could have also been implemented as a mount option to procfs, but at a higher cost and no apparent benefit -- changes to this umask are not supposed to happen very often. Actually, the previous incarnation of this patch was implemented as a half-assed mount option, but I didn't know then how easy it is to add a kernel parameter. Comments about usefulness or implementation are very welcome. Thanks, Rene --- linux-2.6.11-rc4/fs/proc/base.c~2005-02-11 21:16:13.0 +0100 +++ linux-2.6.11-rc4/fs/proc/base.c 2005-02-11 23:38:17.0 +0100 @@ -32,8 +32,14 @@ #include linux/mount.h #include linux/security.h #include linux/ptrace.h +#include linux/module.h +#include linux/moduleparam.h #include internal.h +static umode_t umask = 0; +module_param(umask, ushort, 0); +MODULE_PARM_DESC(umask, umask for the numerical directories in /proc); + /* * For hysterical raisins we keep the same inumbers as in the old procfs. * Feel free to change the macro below - just keep the range distinct from @@ -1369,7 +1375,7 @@ static struct dentry *proc_pident_lookup goto out; ei = PROC_I(inode); - inode-i_mode = p-mode; + inode-i_mode = p-mode ~(umask S_IRWXUGO); /* * Yes, it does not scale. And it should not. Don't add * new entries into /proc/tgid/ without very good reasons. @@ -1699,7 +1705,7 @@ struct dentry *proc_pid_lookup(struct in put_task_struct(task); goto out; } - inode-i_mode = S_IFDIR|S_IRUGO|S_IXUGO; + inode-i_mode = S_IFDIR | ((S_IRUGO|S_IXUGO) ~umask); inode-i_op = proc_tgid_base_inode_operations; inode-i_fop = proc_tgid_base_operations; inode-i_nlink = 3; @@ -1754,7 +1760,7 @@ static struct dentry *proc_task_lookup(s if (!inode) goto out_drop_task; - inode-i_mode = S_IFDIR|S_IRUGO|S_IXUGO; + inode-i_mode = S_IFDIR | ((S_IRUGO|S_IXUGO) ~umask); inode-i_op = proc_tid_base_inode_operations; inode-i_fop = proc_tid_base_operations; inode-i_nlink = 3; - 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] add umask parameter to procfs
Rene Scharfe [EMAIL PROTECTED] wrote: Add proc.umask kernel parameter. It can be used to restrict permissions on the numerical directories in the root of a proc filesystem, i.e. the directories containing process specific information. E.g. add proc.umask=077 to your kernel command line and all users except root can only see their own process details (like command line parameters) with ps or top. It can be useful to add a bit of privacy to multi-user servers. The patch has been inspired by a similar feature in GrSecurity. It could have also been implemented as a mount option to procfs, but at a higher cost and no apparent benefit -- changes to this umask are not supposed to happen very often. Actually, the previous incarnation of this patch was implemented as a half-assed mount option, but I didn't know then how easy it is to add a kernel parameter. The feature seems fairly obscure, although very simple. Is anyone actually likely to use this? +static umode_t umask = 0; a) I think the above should be called proc_umask. b) You shouldn't initialise it. c) When adding a kernel parameter you should update Documentation/kernel-parameters.txt - 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] add umask parameter to procfs
On Thu, Feb 17, 2005 at 03:41:19PM -0800, Andrew Morton wrote: Rene Scharfe [EMAIL PROTECTED] wrote: Add proc.umask kernel parameter. It can be used to restrict permissions on the numerical directories in the root of a proc filesystem, i.e. the directories containing process specific information. E.g. add proc.umask=077 to your kernel command line and all users except root can only see their own process details (like command line parameters) with ps or top. It can be useful to add a bit of privacy to multi-user servers. The patch has been inspired by a similar feature in GrSecurity. It could have also been implemented as a mount option to procfs, but at a higher cost and no apparent benefit -- changes to this umask are not supposed to happen very often. Actually, the previous incarnation of this patch was implemented as a half-assed mount option, but I didn't know then how easy it is to add a kernel parameter. The feature seems fairly obscure, although very simple. Is anyone actually likely to use this? what about parents (and especially the init process) some tools like pstree (or ps in certain cases) depend on their visibility/accessability ... was this tested except for the trivial case where just plain everything is visible? what if you want to change it afterwards (when tools did break)? best, Herbert +static umode_t umask = 0; a) I think the above should be called proc_umask. b) You shouldn't initialise it. c) When adding a kernel parameter you should update Documentation/kernel-parameters.txt - 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/ - 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] add umask parameter to procfs
Herbert Poetzl [EMAIL PROTECTED] wrote: On Thu, Feb 17, 2005 at 03:41:19PM -0800, Andrew Morton wrote: Rene Scharfe [EMAIL PROTECTED] wrote: Add proc.umask kernel parameter. It can be used to restrict permissions on the numerical directories in the root of a proc filesystem, i.e. the directories containing process specific information. E.g. add proc.umask=077 to your kernel command line and all users except root can only see their own process details (like command line parameters) with ps or top. It can be useful to add a bit of privacy to multi-user servers. The feature seems fairly obscure, although very simple. Is anyone actually likely to use this? I'm using a openwall-patched kernel on some of my boxes with a similar feature. I did not yet test this patch, but I like it. It's cheap, and it fixes a potential security leak. what about parents (and especially the init process) some tools like pstree (or ps in certain cases) depend on their visibility/accessability ... pstree will break if /proc/1 isn't readable, unless you specify a readable starting pid. Since this is not the default case, this is IMO ok. (It should be easy to rewrite it to trace the ppid-chains like ps auxf already does correctly, or rather implement it in ps where it belongs). None of my other tools seemed to stop working in an unintended way, but I don't usurally spend my time watching processes. Sample output of ps auxf on a openwall-patched system: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 7eggert 22504 5.0 3.5 2800 1608 pts/4S04:14 0:00 -bash 7eggert 22522 0.0 1.7 2856 792 pts/4R04:14 0:00 \_ ps auxf 7eggert 22483 2.3 3.4 2800 1588 pts/2S04:14 0:00 -bash what if you want to change it afterwards (when tools did break)? Change the kernel command line back and reboot (or reload the module). - 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] add umask parameter to procfs
On Fri, Feb 18, 2005 at 04:22:49AM +0100, Bodo Eggert wrote: Herbert Poetzl [EMAIL PROTECTED] wrote: On Thu, Feb 17, 2005 at 03:41:19PM -0800, Andrew Morton wrote: Rene Scharfe [EMAIL PROTECTED] wrote: Add proc.umask kernel parameter. It can be used to restrict permissions on the numerical directories in the root of a proc filesystem, i.e. the directories containing process specific information. E.g. add proc.umask=077 to your kernel command line and all users except root can only see their own process details (like command line parameters) with ps or top. It can be useful to add a bit of privacy to multi-user servers. The feature seems fairly obscure, although very simple. Is anyone actually likely to use this? I'm using a openwall-patched kernel on some of my boxes with a similar feature. I did not yet test this patch, but I like it. It's cheap, and it fixes a potential security leak. don't get me wrong, I'm all for something like this, as a matter of fact we are using something more specialized for linux-vserver to hide processes between contexts ... what about parents (and especially the init process) some tools like pstree (or ps in certain cases) depend on their visibility/accessability ... pstree will break if /proc/1 isn't readable, unless you specify a readable starting pid. Since this is not the default case, this is IMO ok. (It should be easy to rewrite it to trace the ppid-chains like ps auxf already does correctly, or rather implement it in ps where it belongs). hmm, so what about debugger and similar not able to find the parent process or something like that? I'd say this needs some more investigation what tools and applications will break once it is enabled ... None of my other tools seemed to stop working in an unintended way, but I don't usurally spend my time watching processes. Sample output of ps auxf on a openwall-patched system: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 7eggert 22504 5.0 3.5 2800 1608 pts/4S04:14 0:00 -bash 7eggert 22522 0.0 1.7 2856 792 pts/4R04:14 0:00 \_ ps auxf 7eggert 22483 2.3 3.4 2800 1588 pts/2S04:14 0:00 -bash what if you want to change it afterwards (when tools did break)? Change the kernel command line back and reboot (or reload the module). hmm, reload the procfs module? not very likely ;) best, Herbert - 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/
