Re: [PATCH 0/7] procfs privacy
El lun, 18-04-2005 a las 16:01 -0400, Rik van Riel escribió: > On Mon, 18 Apr 2005, Lorenzo Hernández García-Hierro wrote: > > > Adding a "trusted user group"-like configuration option could be useful, > > as it's done within grsecurity, among that the whole thing might be good > > to depend on a config. option, but that implies using weird ifdef's and > > the other folks. > > I'd rather see something like this implemented as an LSM > module - or better yet, an SELinux security policy. For this purpose I (re)submitted a patch originally made by Serge E. Hallyn that adds a hook in order to catch task lookups, thus, providing an easy way to handle and determine when a task can lookup'ed. It's at: http://pearls.tuxedo-es.org/patches/lsm/lsm-task_lookup-hook.patch vSecurity currently provides support for it (optional). SELinux policy can handle in a much more fine-grained these restrictions, just that it's still something that not all people can deploy without some special effort and "tweak up" (if their system doesn't provide support for it, of course, currently Red Hat has done a great job in that terms). > > There's no need to sprinkle security policy all over the > kernel. I completely agree. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
Re: [PATCH 2/7] procfs privacy: tasks/processes lookup
El lun, 18-04-2005 a las 15:24 -0400, Rik van Riel escribió: > This looks like a very bad default to me! > > Your patch would force people to run system monitoring > applications as root, because otherwise they cannot get > some of the information they can get now. Forcing that > these applications run with root rights is a security > risk, not a benefit... Right, that's why I would say "fall back to the config. option" behavior, trusting in a certain user group defined in configuration-time or via sysctl, or just keeping it simple as it's right now, split up so anyone can decide what to apply and what shouldn't be applied. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
Re: [PATCH] TCP ipv4 source port randomization
El lun, 18-04-2005 a las 12:26 -0700, David S. Miller escribió: > Stephen Hemminger has already added TCP port randomization on > connect() to the 2.6.x tree. See > net/ipv4/tcp_ipv4.c:tcp_v4_hash_connect(), where randomized port > selection occurs. And unlike your patch, Stephen did add ipv6 > support (via net/ipv6/tcp_ipv6.c:tcp_v6_hash_connect()) for > port randomization as well. I missed Hemminger's bits there. I apologize for any inconvenience. > > 1) That you use netdev@oss.sgi.com for networking patches as that >is where the networking developers listen. OK. > 2) That you do some checking to see that the feature you're adding >is not already present in the tree. I do, just missed that ;) Among that I have the patch done since time ago, just didn't submitted it to the list, so, during the transition I forgot all about any change (nor I checked the CSETs). Thanks for the advice, Cheers. -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
Re: [PATCH 3/7] procfs privacy: misc. entries
El lun, 18-04-2005 a las 15:05 -0400, Dave Jones escribió: > This is utterly absurd. You can find out anything thats in /proc/cpuinfo > by calling cpuid instructions yourself. Right, it doesn't make it worthy enough to represent any risk. > Please enlighten me as to what security gains we achieve > by not allowing users to see this ? It's more obscurity than anything else. At least that's what privacy means usually. It doesn't assure at all the unavailability of your information to others, it just tries to hide it from the public eye. > Restricting lots of the other files are equally absurd. > > I'd also be very surprised if various random bits of userspace > broke subtley due to this nonsense. I agree, as an example, grsecurity allows the configuration of a group with rights over the restricted entries, that's why I split up the patch for these entries. Thanks for the comments. Cheers. -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/7] procfs privacy
El lun, 18-04-2005 a las 15:27 -0400, Rik van Riel escribió: > The same "this forces people to run system monitoring tasks > as root, potentially opening themselves up to security holes" > comment applies to this patch. That's because the patch is split up, those bits are on the proc_misc one. I agree, btw. ;) Adding a "trusted user group"-like configuration option could be useful, as it's done within grsecurity, among that the whole thing might be good to depend on a config. option, but that implies using weird ifdef's and the other folks. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
[PATCH] TCP ipv4 source port randomization
Hi,
"When source port is generated on the fly for the TCP protocol (ie. with
connect() ) will
be altered so that the source port is generated at random, instead of a simple
incrementing algorithm."
Ported from grsecurity (http://www.grsecurity.net by Brad Spengler).
Instead of using the PaX & grsecurity-dependent get_random_long() function, we
use
the new randomization infrastructure introduced by Arjan van de Ven <[EMAIL
PROTECTED]>,
providing the helpers get_random_int() and randomize_range().
More information at:
http://people.redhat.com/arjanv/randomize/02-randomize-infrastructure
The patch is also available at:
http://pearls.tuxedo-es.org/patches/security/tcp-rand_src-ports.patch
Signed-off-by: Lorenzo Hernandez Garcia-Hierro <[EMAIL PROTECTED]>
Cheers,
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
When source port is generated on the fly for the TCP protocol (ie. with connect() ) will
be altered so that the source port is generated at random, instead of a simple
incrementing algorithm.
Ported from grsecurity (http://www.grsecurity.net by Brad Spengler).
Instead of using the PaX & grsecurity-dependent get_random_long() function, we use
the new randomization infrastructure introduced by Arjan van de Ven <[EMAIL PROTECTED]>,
providing the helpers get_random_int() and randomize_range().
More information at:
http://people.redhat.com/arjanv/randomize/02-randomize-infrastructure
Signed-off-by: Lorenzo Hernandez Garcia-Hierro <[EMAIL PROTECTED]>
---
linux-2.6.11-lorenzo/net/ipv4/tcp_ipv4.c |5 +
1 files changed, 5 insertions(+)
diff -puN net/ipv4/tcp_ipv4.c~tcp-rand_src-ports net/ipv4/tcp_ipv4.c
--- linux-2.6.11/net/ipv4/tcp_ipv4.c~tcp-rand_src-ports 2005-04-17 17:31:27.233438208 +0200
+++ linux-2.6.11-lorenzo/net/ipv4/tcp_ipv4.c 2005-04-17 17:37:03.528313616 +0200
@@ -224,6 +224,9 @@ static int tcp_v4_get_port(struct sock *
spin_lock(_portalloc_lock);
rover = tcp_port_rover;
+ if (high > low)
+ rover = low + (get_random_int() % remaining);
+
do {
rover++;
if (rover < low || rover > high)
@@ -666,6 +669,8 @@ static inline int tcp_v4_hash_connect(st
struct hlist_node *node;
struct tcp_tw_bucket *tw = NULL;
+ offset = get_random_int();
+
local_bh_disable();
for (i = 1; i <= range; i++) {
port = low + (i + offset) % range;
_
signature.asc
Description: This is a digitally signed message part
[PATCH 7/7] procfs privacy: /proc/iomem & /proc/ioports
This patch changes the permissions of the procfs entries ioports and
iomem to restrict non-root users from accessing them.
It's also available at
http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_kernel_resource.c.patch.
(last patch from the procfs privacy patch-set)
The whole patch is available at:
http://pearls.tuxedo-es.org/patches/security/proc-privacy-1.patch
Cheers,
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
diff -puN kernel/resource.c~proc-privacy-1 kernel/resource.c
--- linux-2.6.11/kernel/resource.c~proc-privacy-1 2005-04-17 18:06:56.221782784 +0200
+++ linux-2.6.11-lorenzo/kernel/resource.c 2005-04-17 18:07:55.685742888 +0200
@@ -136,10 +136,10 @@ static int __init ioresources_init(void)
{
struct proc_dir_entry *entry;
- entry = create_proc_entry("ioports", 0, NULL);
+ entry = create_proc_entry("ioports", S_IRUSR, NULL);
if (entry)
entry->proc_fops = _ioports_operations;
- entry = create_proc_entry("iomem", 0, NULL);
+ entry = create_proc_entry("iomem", S_IRUSR, NULL);
if (entry)
entry->proc_fops = _iomem_operations;
return 0;
signature.asc
Description: This is a digitally signed message part
[PATCH 5/7] procfs privacy: /proc/config.gz
This patch changes the permissions of the procfs entry config.gz, thus,
non-root users are restricted from accessing it.
It's also available at:
http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_kernel_configs.c.patch
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
diff -puN kernel/configs.c~proc-privacy-1 kernel/configs.c
--- linux-2.6.11/kernel/configs.c~proc-privacy-1 2005-04-17 18:04:39.281600856 +0200
+++ linux-2.6.11-lorenzo/kernel/configs.c 2005-04-17 18:05:33.478361696 +0200
@@ -89,7 +89,7 @@ static int __init ikconfig_init(void)
struct proc_dir_entry *entry;
/* create the current config file */
- entry = create_proc_entry("config.gz", S_IFREG | S_IRUGO,
+ entry = create_proc_entry("config.gz", S_IFREG | S_IRUSR,
_root);
if (!entry)
return -ENOMEM;
signature.asc
Description: This is a digitally signed message part
[PATCH 6/7] procfs privacy: /proc/kallsyms
This patch changes the permissions of the procfs entry kallsyms, thus,
non-root users are restricted from accessing it.
It's also available at:
http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_kernel_kallsyms.c.patch
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
diff -puN kernel/kallsyms.c~proc-privacy-1 kernel/kallsyms.c
--- linux-2.6.11/kernel/kallsyms.c~proc-privacy-1 2005-04-17 18:06:01.380119984 +0200
+++ linux-2.6.11-lorenzo/kernel/kallsyms.c 2005-04-17 18:06:27.378167680 +0200
@@ -388,7 +388,7 @@ int __init kallsyms_init(void)
{
struct proc_dir_entry *entry;
- entry = create_proc_entry("kallsyms", 0444, NULL);
+ entry = create_proc_entry("kallsyms", S_IFREG | S_IRUSR, NULL);
if (entry)
entry->proc_fops = _operations;
return 0;
signature.asc
Description: This is a digitally signed message part
[PATCH 4/7] procfs privacy: /proc/bus & /proc/net directory entries
This patch changes the permissions of the /proc/net and /proc/bus
directory entries so non-root users are restricted from accessing them.
It's also available at:
http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_fs_proc_root.c.patch
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
diff -puN fs/proc/root.c~proc-privacy-1 fs/proc/root.c
--- linux-2.6.11/fs/proc/root.c~proc-privacy-1 2005-04-17 18:02:38.832911840 +0200
+++ linux-2.6.11-lorenzo/fs/proc/root.c 2005-04-17 18:03:59.102708976 +0200
@@ -52,7 +52,7 @@ void __init proc_root_init(void)
return;
}
proc_misc_init();
- proc_net = proc_mkdir("net", NULL);
+ proc_net = proc_mkdir_mode("net", S_IRUSR | S_IXUSR, NULL);
proc_net_stat = proc_mkdir("net/stat", NULL);
#ifdef CONFIG_SYSVIPC
@@ -76,7 +76,7 @@ void __init proc_root_init(void)
#ifdef CONFIG_PROC_DEVICETREE
proc_device_tree_init();
#endif
- proc_bus = proc_mkdir("bus", NULL);
+ proc_bus = proc_mkdir_mode("bus", S_IRUSR | S_IXUSR, NULL);
}
static struct dentry *proc_root_lookup(struct inode * dir, struct dentry * dentry, struct nameidata *nd)
signature.asc
Description: This is a digitally signed message part
[PATCH 3/7] procfs privacy: misc. entries
This patch changes the permissions of the following procfs entries to
restrict non-root users from accessing them:
- /proc/devices
- /proc/cmdline
- /proc/version
- /proc/uptime
- /proc/cpuinfo
- /proc/partitions
- /proc/stat
- /proc/interrupts
- /proc/slabinfo
- /proc/diskstats
- /proc/modules
- /proc/schedstat
It's also available at:
http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_fs_proc_proc_misc.c.patch
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
diff -puN fs/proc/proc_misc.c~proc-privacy-1 fs/proc/proc_misc.c
--- linux-2.6.11/fs/proc/proc_misc.c~proc-privacy-1 2005-04-17 18:09:40.615791096 +0200
+++ linux-2.6.11-lorenzo/fs/proc/proc_misc.c 2005-04-17 18:20:13.763538008 +0200
@@ -552,18 +552,14 @@ void __init proc_misc_init(void)
int (*read_proc)(char*,char**,off_t,int,int*,void*);
} *p, simple_ones[] = {
{"loadavg", loadavg_read_proc},
- {"uptime", uptime_read_proc},
{"meminfo", meminfo_read_proc},
- {"version", version_read_proc},
#ifdef CONFIG_PROC_HARDWARE
{"hardware", hardware_read_proc},
#endif
#ifdef CONFIG_STRAM_PROC
{"stram", stram_read_proc},
#endif
- {"devices", devices_read_proc},
{"filesystems", filesystems_read_proc},
- {"cmdline", cmdline_read_proc},
{"locks", locks_read_proc},
{"execdomains", execdomains_read_proc},
{NULL,}
@@ -571,25 +567,30 @@ void __init proc_misc_init(void)
for (p = simple_ones; p->name; p++)
create_proc_read_entry(p->name, 0, NULL, p->read_proc, NULL);
+ create_proc_read_entry("devices", S_IRUSR, NULL, _read_proc, NULL);
+ create_proc_read_entry("cmdline", S_IRUSR, NULL, _read_proc, NULL);
+ create_proc_read_entry("version", S_IRUSR, NULL, _read_proc, NULL);
+ create_proc_read_entry("uptime", S_IRUSR, NULL, _read_proc, NULL);
+
proc_symlink("mounts", NULL, "self/mounts");
/* And now for trickier ones */
entry = create_proc_entry("kmsg", S_IRUSR, _root);
if (entry)
entry->proc_fops = _kmsg_operations;
- create_seq_entry("cpuinfo", 0, _cpuinfo_operations);
- create_seq_entry("partitions", 0, _partitions_operations);
- create_seq_entry("stat", 0, _stat_operations);
- create_seq_entry("interrupts", 0, _interrupts_operations);
- create_seq_entry("slabinfo",S_IWUSR|S_IRUGO,_slabinfo_operations);
+ create_seq_entry("cpuinfo", S_IRUSR, _cpuinfo_operations);
+ create_seq_entry("partitions", S_IRUSR, _partitions_operations);
+ create_seq_entry("stat", S_IRUSR, _stat_operations);
+ create_seq_entry("interrupts", S_IRUSR, _interrupts_operations);
+ create_seq_entry("slabinfo",S_IWUSR|S_IRUSR,_slabinfo_operations);
create_seq_entry("buddyinfo",S_IRUGO, _file_operations);
create_seq_entry("vmstat",S_IRUGO, _vmstat_file_operations);
- create_seq_entry("diskstats", 0, _diskstats_operations);
+ create_seq_entry("diskstats", S_IRUSR, _diskstats_operations);
#ifdef CONFIG_MODULES
- create_seq_entry("modules", 0, _modules_operations);
+ create_seq_entry("modules", S_IRUSR, _modules_operations);
#endif
#ifdef CONFIG_SCHEDSTATS
- create_seq_entry("schedstat", 0, _schedstat_operations);
+ create_seq_entry("schedstat", S_IRUSR, _schedstat_operations);
#endif
#ifdef CONFIG_PROC_KCORE
proc_root_kcore = create_proc_entry("kcore", S_IRUSR, NULL);
_
signature.asc
Description: This is a digitally signed message part
[PATCH 0/7] procfs privacy
As extracted from grsecurity's config. documentation: "non-root users will only be able to view their own processes, and restricts them from viewing network-related information, and viewing kernel symbol and module information." This is a procfs "privacy" split-up patch based in grsecurity procfs restrictions with some changes, more concretely, the restricted sections and entries are: - /proc/bus /pci - /proc/net - /proc/config.gz - /proc/kallsyms - /proc/ioports - /proc/iomem - /proc/devices - /proc/cmdline - /proc/version - /proc/uptime - /proc/cpuinfo - /proc/partitions - /proc/stat - /proc/interrupts - /proc/slabinfo - /proc/diskstats - /proc/modules - /proc/schedstat Signed-off-by: Lorenzo Hernandez Garcia-Hierro <[EMAIL PROTECTED]> --- linux-2.6.11-lorenzo/drivers/pci/proc.c |4 ++-- linux-2.6.11-lorenzo/fs/proc/base.c | 10 +- linux-2.6.11-lorenzo/fs/proc/proc_misc.c | 25 + linux-2.6.11-lorenzo/fs/proc/root.c |4 ++-- linux-2.6.11-lorenzo/kernel/configs.c|2 +- linux-2.6.11-lorenzo/kernel/kallsyms.c |2 +- linux-2.6.11-lorenzo/kernel/resource.c |4 ++-- 7 files changed, 30 insertions(+), 21 deletions(-) -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
[PATCH 2/7] procfs privacy: tasks/processes lookup
This patch restricts non-root users to view only their own processes.
It's also available at:
http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_fs_proc_base.c.patch
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
diff -puN fs/proc/base.c~proc-privacy-1 fs/proc/base.c
--- linux-2.6.11/fs/proc/base.c~proc-privacy-1 2005-04-17 17:56:45.623607816 +0200
+++ linux-2.6.11-lorenzo/fs/proc/base.c 2005-04-17 18:01:14.988658104 +0200
@@ -1692,6 +1692,11 @@ struct dentry *proc_pid_lookup(struct in
if (!task)
goto out;
+ if (current->uid && (task->uid != current->uid)) {
+ put_task_struct(task);
+ goto out;
+ }
+
inode = proc_pid_make_inode(dir->i_sb, task, PROC_TGID_INO);
@@ -1699,7 +1704,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_IRUSR|S_IXUSR;
inode->i_op = _tgid_base_inode_operations;
inode->i_fop = _tgid_base_operations;
inode->i_nlink = 3;
@@ -1783,6 +1788,7 @@ out:
static int get_tgid_list(int index, unsigned long version, unsigned int *tgids)
{
struct task_struct *p;
+ struct task_struct *tmp = current;
int nr_tgids = 0;
index--;
@@ -1803,6 +1809,8 @@ static int get_tgid_list(int index, unsi
int tgid = p->pid;
if (!pid_alive(p))
continue;
+ if (tmp->uid && (p->uid != tmp->uid))
+ continue;
if (--index >= 0)
continue;
tgids[nr_tgids] = tgid;
signature.asc
Description: This is a digitally signed message part
[PATCH 1/7] procfs privacy: /proc/bus/pci
This patch changes the permissions of the /proc/bus/pci directory entry,
so, non-root users are restricted of accessing it's content.
It's also available at:
http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_drivers_pci_proc.c.patch
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
diff -puN drivers/pci/proc.c~proc-privacy-1 drivers/pci/proc.c
--- linux-2.6.11/drivers/pci/proc.c~proc-privacy-1 2005-04-17 17:50:49.033817704 +0200
+++ linux-2.6.11-lorenzo/drivers/pci/proc.c 2005-04-17 17:55:11.321943848 +0200
@@ -565,7 +565,7 @@ static struct file_operations proc_pci_o
static void legacy_proc_init(void)
{
- struct proc_dir_entry * entry = create_proc_entry("pci", 0, NULL);
+ struct proc_dir_entry * entry = create_proc_entry("pci", S_IRUSR, NULL);
if (entry)
entry->proc_fops = _pci_operations;
}
@@ -594,7 +594,7 @@ static int __init pci_proc_init(void)
{
struct proc_dir_entry *entry;
struct pci_dev *dev = NULL;
- proc_bus_pci_dir = proc_mkdir("pci", proc_bus);
+ proc_bus_pci_dir = proc_mkdir_mode("pci", S_IRUSR | S_IXUSR, proc_bus);
entry = create_proc_entry("devices", 0, proc_bus_pci_dir);
if (entry)
entry->proc_fops = _bus_pci_dev_operations;
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] RLIMIT_NPROC enforcement during execve() calls
El lun, 18-04-2005 a las 18:43 +0100, Christoph Hellwig escribió: > On Mon, Apr 18, 2005 at 07:38:57PM +0200, Lorenzo Hern?ndez Garc?a-Hierro > wrote: > > Enforces the RLIMIT_NPROC limit by adding an additional check for > > execve(), as > > such limit is checked only during fork() calls. > > What's the point? exec doesn't create new process and exec() shouldn't > start to fail just because someone lowered the rlimit a short while ago. The limit is only checked when process is created on a fork() call, but during execution it's uid can change, thus, the limit for the new uid could be exceed. It comes from the Openwall kernel patch, as well implemented in grSecurity and vSecurity. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
[PATCH] RLIMIT_NPROC enforcement during execve() calls
Enforces the RLIMIT_NPROC limit by adding an additional check for
execve(), as
such limit is checked only during fork() calls.
The patch is also available at:
http://pearls.tuxedo-es.org/patches/security/rlimit_nproc-enforcing-execve.patch
Signed-off-by: Lorenzo Hernandez Garcia-Hierro <[EMAIL PROTECTED]>
---
linux-2.6.11-lorenzo/fs/compat.c |8
linux-2.6.11-lorenzo/fs/exec.c |9 +
2 files changed, 17 insertions(+)
diff -puN fs/exec.c~rlimit_nproc-enforcing-execve fs/exec.c
--- linux-2.6.11/fs/exec.c~rlimit_nproc-enforcing-execve2005-04-16
16:28:56.0 +0200
+++ linux-2.6.11-lorenzo/fs/exec.c 2005-04-16 19:26:47.0 +0200
@@ -1140,6 +1140,15 @@ int do_execve(char * filename,
if (IS_ERR(file))
goto out_kfree;
+ /* RLIMIT_NPROC enforcement */
+ if (current->user && (atomic_read(>user->processes) >
+current->signal->rlim[RLIMIT_NPROC].rlim_cur) &&
+ !capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE)) {
+ allow_write_access(file);
+ fput(file);
+ return -EAGAIN;
+ }
+
sched_exec();
bprm->p = PAGE_SIZE*MAX_ARG_PAGES-sizeof(void *);
diff -puN fs/compat.c~rlimit_nproc-enforcing-execve fs/compat.c
--- linux-2.6.11/fs/compat.c~rlimit_nproc-enforcing-execve 2005-04-16
16:28:56.0 +0200
+++ linux-2.6.11-lorenzo/fs/compat.c2005-04-16 19:26:58.0 +0200
@@ -1450,6 +1450,14 @@ int compat_do_execve(char * filename,
if (!bprm->mm)
goto out_file;
+ /* RLIMIT_NPROC enforcement */
+ retval = -EAGAIN;
+ if (current->user && (atomic_read(>user->processes) >
+current->signal->rlim[RLIMIT_NPROC].rlim_cur) &&
+ !capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE)) {
+ goto out_file;
+ }
+
retval = init_new_context(current, bprm->mm);
if (retval < 0)
goto out_mm;
_
Cheers,
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
signature.asc
Description: This is a digitally signed message part
[PATCH] RLIMIT_NPROC enforcement during execve() calls
Enforces the RLIMIT_NPROC limit by adding an additional check for
execve(), as
such limit is checked only during fork() calls.
The patch is also available at:
http://pearls.tuxedo-es.org/patches/security/rlimit_nproc-enforcing-execve.patch
Signed-off-by: Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED]
---
linux-2.6.11-lorenzo/fs/compat.c |8
linux-2.6.11-lorenzo/fs/exec.c |9 +
2 files changed, 17 insertions(+)
diff -puN fs/exec.c~rlimit_nproc-enforcing-execve fs/exec.c
--- linux-2.6.11/fs/exec.c~rlimit_nproc-enforcing-execve2005-04-16
16:28:56.0 +0200
+++ linux-2.6.11-lorenzo/fs/exec.c 2005-04-16 19:26:47.0 +0200
@@ -1140,6 +1140,15 @@ int do_execve(char * filename,
if (IS_ERR(file))
goto out_kfree;
+ /* RLIMIT_NPROC enforcement */
+ if (current-user (atomic_read(current-user-processes)
+current-signal-rlim[RLIMIT_NPROC].rlim_cur)
+ !capable(CAP_SYS_ADMIN) !capable(CAP_SYS_RESOURCE)) {
+ allow_write_access(file);
+ fput(file);
+ return -EAGAIN;
+ }
+
sched_exec();
bprm-p = PAGE_SIZE*MAX_ARG_PAGES-sizeof(void *);
diff -puN fs/compat.c~rlimit_nproc-enforcing-execve fs/compat.c
--- linux-2.6.11/fs/compat.c~rlimit_nproc-enforcing-execve 2005-04-16
16:28:56.0 +0200
+++ linux-2.6.11-lorenzo/fs/compat.c2005-04-16 19:26:58.0 +0200
@@ -1450,6 +1450,14 @@ int compat_do_execve(char * filename,
if (!bprm-mm)
goto out_file;
+ /* RLIMIT_NPROC enforcement */
+ retval = -EAGAIN;
+ if (current-user (atomic_read(current-user-processes)
+current-signal-rlim[RLIMIT_NPROC].rlim_cur)
+ !capable(CAP_SYS_ADMIN) !capable(CAP_SYS_RESOURCE)) {
+ goto out_file;
+ }
+
retval = init_new_context(current, bprm-mm);
if (retval 0)
goto out_mm;
_
Cheers,
--
Lorenzo Hernández García-Hierro [EMAIL PROTECTED]
[1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org]
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] RLIMIT_NPROC enforcement during execve() calls
El lun, 18-04-2005 a las 18:43 +0100, Christoph Hellwig escribió: On Mon, Apr 18, 2005 at 07:38:57PM +0200, Lorenzo Hern?ndez Garc?a-Hierro wrote: Enforces the RLIMIT_NPROC limit by adding an additional check for execve(), as such limit is checked only during fork() calls. What's the point? exec doesn't create new process and exec() shouldn't start to fail just because someone lowered the rlimit a short while ago. The limit is only checked when process is created on a fork() call, but during execution it's uid can change, thus, the limit for the new uid could be exceed. It comes from the Openwall kernel patch, as well implemented in grSecurity and vSecurity. Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
[PATCH 1/7] procfs privacy: /proc/bus/pci
This patch changes the permissions of the /proc/bus/pci directory entry,
so, non-root users are restricted of accessing it's content.
It's also available at:
http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_drivers_pci_proc.c.patch
--
Lorenzo Hernández García-Hierro [EMAIL PROTECTED]
[1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org]
diff -puN drivers/pci/proc.c~proc-privacy-1 drivers/pci/proc.c
--- linux-2.6.11/drivers/pci/proc.c~proc-privacy-1 2005-04-17 17:50:49.033817704 +0200
+++ linux-2.6.11-lorenzo/drivers/pci/proc.c 2005-04-17 17:55:11.321943848 +0200
@@ -565,7 +565,7 @@ static struct file_operations proc_pci_o
static void legacy_proc_init(void)
{
- struct proc_dir_entry * entry = create_proc_entry(pci, 0, NULL);
+ struct proc_dir_entry * entry = create_proc_entry(pci, S_IRUSR, NULL);
if (entry)
entry-proc_fops = proc_pci_operations;
}
@@ -594,7 +594,7 @@ static int __init pci_proc_init(void)
{
struct proc_dir_entry *entry;
struct pci_dev *dev = NULL;
- proc_bus_pci_dir = proc_mkdir(pci, proc_bus);
+ proc_bus_pci_dir = proc_mkdir_mode(pci, S_IRUSR | S_IXUSR, proc_bus);
entry = create_proc_entry(devices, 0, proc_bus_pci_dir);
if (entry)
entry-proc_fops = proc_bus_pci_dev_operations;
signature.asc
Description: This is a digitally signed message part
[PATCH 2/7] procfs privacy: tasks/processes lookup
This patch restricts non-root users to view only their own processes.
It's also available at:
http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_fs_proc_base.c.patch
--
Lorenzo Hernández García-Hierro [EMAIL PROTECTED]
[1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org]
diff -puN fs/proc/base.c~proc-privacy-1 fs/proc/base.c
--- linux-2.6.11/fs/proc/base.c~proc-privacy-1 2005-04-17 17:56:45.623607816 +0200
+++ linux-2.6.11-lorenzo/fs/proc/base.c 2005-04-17 18:01:14.988658104 +0200
@@ -1692,6 +1692,11 @@ struct dentry *proc_pid_lookup(struct in
if (!task)
goto out;
+ if (current-uid (task-uid != current-uid)) {
+ put_task_struct(task);
+ goto out;
+ }
+
inode = proc_pid_make_inode(dir-i_sb, task, PROC_TGID_INO);
@@ -1699,7 +1704,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_IRUSR|S_IXUSR;
inode-i_op = proc_tgid_base_inode_operations;
inode-i_fop = proc_tgid_base_operations;
inode-i_nlink = 3;
@@ -1783,6 +1788,7 @@ out:
static int get_tgid_list(int index, unsigned long version, unsigned int *tgids)
{
struct task_struct *p;
+ struct task_struct *tmp = current;
int nr_tgids = 0;
index--;
@@ -1803,6 +1809,8 @@ static int get_tgid_list(int index, unsi
int tgid = p-pid;
if (!pid_alive(p))
continue;
+ if (tmp-uid (p-uid != tmp-uid))
+ continue;
if (--index = 0)
continue;
tgids[nr_tgids] = tgid;
signature.asc
Description: This is a digitally signed message part
[PATCH 0/7] procfs privacy
As extracted from grsecurity's config. documentation: non-root users will only be able to view their own processes, and restricts them from viewing network-related information, and viewing kernel symbol and module information. This is a procfs privacy split-up patch based in grsecurity procfs restrictions with some changes, more concretely, the restricted sections and entries are: - /proc/bus /pci - /proc/net - /proc/config.gz - /proc/kallsyms - /proc/ioports - /proc/iomem - /proc/devices - /proc/cmdline - /proc/version - /proc/uptime - /proc/cpuinfo - /proc/partitions - /proc/stat - /proc/interrupts - /proc/slabinfo - /proc/diskstats - /proc/modules - /proc/schedstat Signed-off-by: Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED] --- linux-2.6.11-lorenzo/drivers/pci/proc.c |4 ++-- linux-2.6.11-lorenzo/fs/proc/base.c | 10 +- linux-2.6.11-lorenzo/fs/proc/proc_misc.c | 25 + linux-2.6.11-lorenzo/fs/proc/root.c |4 ++-- linux-2.6.11-lorenzo/kernel/configs.c|2 +- linux-2.6.11-lorenzo/kernel/kallsyms.c |2 +- linux-2.6.11-lorenzo/kernel/resource.c |4 ++-- 7 files changed, 30 insertions(+), 21 deletions(-) -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
[PATCH 3/7] procfs privacy: misc. entries
This patch changes the permissions of the following procfs entries to
restrict non-root users from accessing them:
- /proc/devices
- /proc/cmdline
- /proc/version
- /proc/uptime
- /proc/cpuinfo
- /proc/partitions
- /proc/stat
- /proc/interrupts
- /proc/slabinfo
- /proc/diskstats
- /proc/modules
- /proc/schedstat
It's also available at:
http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_fs_proc_proc_misc.c.patch
--
Lorenzo Hernández García-Hierro [EMAIL PROTECTED]
[1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org]
diff -puN fs/proc/proc_misc.c~proc-privacy-1 fs/proc/proc_misc.c
--- linux-2.6.11/fs/proc/proc_misc.c~proc-privacy-1 2005-04-17 18:09:40.615791096 +0200
+++ linux-2.6.11-lorenzo/fs/proc/proc_misc.c 2005-04-17 18:20:13.763538008 +0200
@@ -552,18 +552,14 @@ void __init proc_misc_init(void)
int (*read_proc)(char*,char**,off_t,int,int*,void*);
} *p, simple_ones[] = {
{loadavg, loadavg_read_proc},
- {uptime, uptime_read_proc},
{meminfo, meminfo_read_proc},
- {version, version_read_proc},
#ifdef CONFIG_PROC_HARDWARE
{hardware, hardware_read_proc},
#endif
#ifdef CONFIG_STRAM_PROC
{stram, stram_read_proc},
#endif
- {devices, devices_read_proc},
{filesystems, filesystems_read_proc},
- {cmdline, cmdline_read_proc},
{locks, locks_read_proc},
{execdomains, execdomains_read_proc},
{NULL,}
@@ -571,25 +567,30 @@ void __init proc_misc_init(void)
for (p = simple_ones; p-name; p++)
create_proc_read_entry(p-name, 0, NULL, p-read_proc, NULL);
+ create_proc_read_entry(devices, S_IRUSR, NULL, devices_read_proc, NULL);
+ create_proc_read_entry(cmdline, S_IRUSR, NULL, cmdline_read_proc, NULL);
+ create_proc_read_entry(version, S_IRUSR, NULL, version_read_proc, NULL);
+ create_proc_read_entry(uptime, S_IRUSR, NULL, uptime_read_proc, NULL);
+
proc_symlink(mounts, NULL, self/mounts);
/* And now for trickier ones */
entry = create_proc_entry(kmsg, S_IRUSR, proc_root);
if (entry)
entry-proc_fops = proc_kmsg_operations;
- create_seq_entry(cpuinfo, 0, proc_cpuinfo_operations);
- create_seq_entry(partitions, 0, proc_partitions_operations);
- create_seq_entry(stat, 0, proc_stat_operations);
- create_seq_entry(interrupts, 0, proc_interrupts_operations);
- create_seq_entry(slabinfo,S_IWUSR|S_IRUGO,proc_slabinfo_operations);
+ create_seq_entry(cpuinfo, S_IRUSR, proc_cpuinfo_operations);
+ create_seq_entry(partitions, S_IRUSR, proc_partitions_operations);
+ create_seq_entry(stat, S_IRUSR, proc_stat_operations);
+ create_seq_entry(interrupts, S_IRUSR, proc_interrupts_operations);
+ create_seq_entry(slabinfo,S_IWUSR|S_IRUSR,proc_slabinfo_operations);
create_seq_entry(buddyinfo,S_IRUGO, fragmentation_file_operations);
create_seq_entry(vmstat,S_IRUGO, proc_vmstat_file_operations);
- create_seq_entry(diskstats, 0, proc_diskstats_operations);
+ create_seq_entry(diskstats, S_IRUSR, proc_diskstats_operations);
#ifdef CONFIG_MODULES
- create_seq_entry(modules, 0, proc_modules_operations);
+ create_seq_entry(modules, S_IRUSR, proc_modules_operations);
#endif
#ifdef CONFIG_SCHEDSTATS
- create_seq_entry(schedstat, 0, proc_schedstat_operations);
+ create_seq_entry(schedstat, S_IRUSR, proc_schedstat_operations);
#endif
#ifdef CONFIG_PROC_KCORE
proc_root_kcore = create_proc_entry(kcore, S_IRUSR, NULL);
_
signature.asc
Description: This is a digitally signed message part
[PATCH 4/7] procfs privacy: /proc/bus /proc/net directory entries
This patch changes the permissions of the /proc/net and /proc/bus directory entries so non-root users are restricted from accessing them. It's also available at: http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_fs_proc_root.c.patch -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] diff -puN fs/proc/root.c~proc-privacy-1 fs/proc/root.c --- linux-2.6.11/fs/proc/root.c~proc-privacy-1 2005-04-17 18:02:38.832911840 +0200 +++ linux-2.6.11-lorenzo/fs/proc/root.c 2005-04-17 18:03:59.102708976 +0200 @@ -52,7 +52,7 @@ void __init proc_root_init(void) return; } proc_misc_init(); - proc_net = proc_mkdir(net, NULL); + proc_net = proc_mkdir_mode(net, S_IRUSR | S_IXUSR, NULL); proc_net_stat = proc_mkdir(net/stat, NULL); #ifdef CONFIG_SYSVIPC @@ -76,7 +76,7 @@ void __init proc_root_init(void) #ifdef CONFIG_PROC_DEVICETREE proc_device_tree_init(); #endif - proc_bus = proc_mkdir(bus, NULL); + proc_bus = proc_mkdir_mode(bus, S_IRUSR | S_IXUSR, NULL); } static struct dentry *proc_root_lookup(struct inode * dir, struct dentry * dentry, struct nameidata *nd) signature.asc Description: This is a digitally signed message part
[PATCH 6/7] procfs privacy: /proc/kallsyms
This patch changes the permissions of the procfs entry kallsyms, thus,
non-root users are restricted from accessing it.
It's also available at:
http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_kernel_kallsyms.c.patch
--
Lorenzo Hernández García-Hierro [EMAIL PROTECTED]
[1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org]
diff -puN kernel/kallsyms.c~proc-privacy-1 kernel/kallsyms.c
--- linux-2.6.11/kernel/kallsyms.c~proc-privacy-1 2005-04-17 18:06:01.380119984 +0200
+++ linux-2.6.11-lorenzo/kernel/kallsyms.c 2005-04-17 18:06:27.378167680 +0200
@@ -388,7 +388,7 @@ int __init kallsyms_init(void)
{
struct proc_dir_entry *entry;
- entry = create_proc_entry(kallsyms, 0444, NULL);
+ entry = create_proc_entry(kallsyms, S_IFREG | S_IRUSR, NULL);
if (entry)
entry-proc_fops = kallsyms_operations;
return 0;
signature.asc
Description: This is a digitally signed message part
[PATCH 5/7] procfs privacy: /proc/config.gz
This patch changes the permissions of the procfs entry config.gz, thus, non-root users are restricted from accessing it. It's also available at: http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_kernel_configs.c.patch -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] diff -puN kernel/configs.c~proc-privacy-1 kernel/configs.c --- linux-2.6.11/kernel/configs.c~proc-privacy-1 2005-04-17 18:04:39.281600856 +0200 +++ linux-2.6.11-lorenzo/kernel/configs.c 2005-04-17 18:05:33.478361696 +0200 @@ -89,7 +89,7 @@ static int __init ikconfig_init(void) struct proc_dir_entry *entry; /* create the current config file */ - entry = create_proc_entry(config.gz, S_IFREG | S_IRUGO, + entry = create_proc_entry(config.gz, S_IFREG | S_IRUSR, proc_root); if (!entry) return -ENOMEM; signature.asc Description: This is a digitally signed message part
[PATCH 7/7] procfs privacy: /proc/iomem /proc/ioports
This patch changes the permissions of the procfs entries ioports and
iomem to restrict non-root users from accessing them.
It's also available at
http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_kernel_resource.c.patch.
(last patch from the procfs privacy patch-set)
The whole patch is available at:
http://pearls.tuxedo-es.org/patches/security/proc-privacy-1.patch
Cheers,
--
Lorenzo Hernández García-Hierro [EMAIL PROTECTED]
[1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org]
diff -puN kernel/resource.c~proc-privacy-1 kernel/resource.c
--- linux-2.6.11/kernel/resource.c~proc-privacy-1 2005-04-17 18:06:56.221782784 +0200
+++ linux-2.6.11-lorenzo/kernel/resource.c 2005-04-17 18:07:55.685742888 +0200
@@ -136,10 +136,10 @@ static int __init ioresources_init(void)
{
struct proc_dir_entry *entry;
- entry = create_proc_entry(ioports, 0, NULL);
+ entry = create_proc_entry(ioports, S_IRUSR, NULL);
if (entry)
entry-proc_fops = proc_ioports_operations;
- entry = create_proc_entry(iomem, 0, NULL);
+ entry = create_proc_entry(iomem, S_IRUSR, NULL);
if (entry)
entry-proc_fops = proc_iomem_operations;
return 0;
signature.asc
Description: This is a digitally signed message part
[PATCH] TCP ipv4 source port randomization
Hi,
When source port is generated on the fly for the TCP protocol (ie. with
connect() ) will
be altered so that the source port is generated at random, instead of a simple
incrementing algorithm.
Ported from grsecurity (http://www.grsecurity.net by Brad Spengler).
Instead of using the PaX grsecurity-dependent get_random_long() function, we
use
the new randomization infrastructure introduced by Arjan van de Ven [EMAIL
PROTECTED],
providing the helpers get_random_int() and randomize_range().
More information at:
http://people.redhat.com/arjanv/randomize/02-randomize-infrastructure
The patch is also available at:
http://pearls.tuxedo-es.org/patches/security/tcp-rand_src-ports.patch
Signed-off-by: Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED]
Cheers,
--
Lorenzo Hernández García-Hierro [EMAIL PROTECTED]
[1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org]
When source port is generated on the fly for the TCP protocol (ie. with connect() ) will
be altered so that the source port is generated at random, instead of a simple
incrementing algorithm.
Ported from grsecurity (http://www.grsecurity.net by Brad Spengler).
Instead of using the PaX grsecurity-dependent get_random_long() function, we use
the new randomization infrastructure introduced by Arjan van de Ven [EMAIL PROTECTED],
providing the helpers get_random_int() and randomize_range().
More information at:
http://people.redhat.com/arjanv/randomize/02-randomize-infrastructure
Signed-off-by: Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED]
---
linux-2.6.11-lorenzo/net/ipv4/tcp_ipv4.c |5 +
1 files changed, 5 insertions(+)
diff -puN net/ipv4/tcp_ipv4.c~tcp-rand_src-ports net/ipv4/tcp_ipv4.c
--- linux-2.6.11/net/ipv4/tcp_ipv4.c~tcp-rand_src-ports 2005-04-17 17:31:27.233438208 +0200
+++ linux-2.6.11-lorenzo/net/ipv4/tcp_ipv4.c 2005-04-17 17:37:03.528313616 +0200
@@ -224,6 +224,9 @@ static int tcp_v4_get_port(struct sock *
spin_lock(tcp_portalloc_lock);
rover = tcp_port_rover;
+ if (high low)
+ rover = low + (get_random_int() % remaining);
+
do {
rover++;
if (rover low || rover high)
@@ -666,6 +669,8 @@ static inline int tcp_v4_hash_connect(st
struct hlist_node *node;
struct tcp_tw_bucket *tw = NULL;
+ offset = get_random_int();
+
local_bh_disable();
for (i = 1; i = range; i++) {
port = low + (i + offset) % range;
_
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 0/7] procfs privacy
El lun, 18-04-2005 a las 15:27 -0400, Rik van Riel escribió: The same this forces people to run system monitoring tasks as root, potentially opening themselves up to security holes comment applies to this patch. That's because the patch is split up, those bits are on the proc_misc one. I agree, btw. ;) Adding a trusted user group-like configuration option could be useful, as it's done within grsecurity, among that the whole thing might be good to depend on a config. option, but that implies using weird ifdef's and the other folks. Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
Re: [PATCH 3/7] procfs privacy: misc. entries
El lun, 18-04-2005 a las 15:05 -0400, Dave Jones escribió: This is utterly absurd. You can find out anything thats in /proc/cpuinfo by calling cpuid instructions yourself. Right, it doesn't make it worthy enough to represent any risk. Please enlighten me as to what security gains we achieve by not allowing users to see this ? It's more obscurity than anything else. At least that's what privacy means usually. It doesn't assure at all the unavailability of your information to others, it just tries to hide it from the public eye. Restricting lots of the other files are equally absurd. I'd also be very surprised if various random bits of userspace broke subtley due to this nonsense. I agree, as an example, grsecurity allows the configuration of a group with rights over the restricted entries, that's why I split up the patch for these entries. Thanks for the comments. Cheers. -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
Re: [PATCH] TCP ipv4 source port randomization
El lun, 18-04-2005 a las 12:26 -0700, David S. Miller escribió: Stephen Hemminger has already added TCP port randomization on connect() to the 2.6.x tree. See net/ipv4/tcp_ipv4.c:tcp_v4_hash_connect(), where randomized port selection occurs. And unlike your patch, Stephen did add ipv6 support (via net/ipv6/tcp_ipv6.c:tcp_v6_hash_connect()) for port randomization as well. I missed Hemminger's bits there. I apologize for any inconvenience. 1) That you use netdev@oss.sgi.com for networking patches as that is where the networking developers listen. OK. 2) That you do some checking to see that the feature you're adding is not already present in the tree. I do, just missed that ;) Among that I have the patch done since time ago, just didn't submitted it to the list, so, during the transition I forgot all about any change (nor I checked the CSETs). Thanks for the advice, Cheers. -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
Re: [PATCH 2/7] procfs privacy: tasks/processes lookup
El lun, 18-04-2005 a las 15:24 -0400, Rik van Riel escribió: This looks like a very bad default to me! Your patch would force people to run system monitoring applications as root, because otherwise they cannot get some of the information they can get now. Forcing that these applications run with root rights is a security risk, not a benefit... Right, that's why I would say fall back to the config. option behavior, trusting in a certain user group defined in configuration-time or via sysctl, or just keeping it simple as it's right now, split up so anyone can decide what to apply and what shouldn't be applied. Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/7] procfs privacy
El lun, 18-04-2005 a las 16:01 -0400, Rik van Riel escribió: On Mon, 18 Apr 2005, Lorenzo Hernández García-Hierro wrote: Adding a trusted user group-like configuration option could be useful, as it's done within grsecurity, among that the whole thing might be good to depend on a config. option, but that implies using weird ifdef's and the other folks. I'd rather see something like this implemented as an LSM module - or better yet, an SELinux security policy. For this purpose I (re)submitted a patch originally made by Serge E. Hallyn that adds a hook in order to catch task lookups, thus, providing an easy way to handle and determine when a task can lookup'ed. It's at: http://pearls.tuxedo-es.org/patches/lsm/lsm-task_lookup-hook.patch vSecurity currently provides support for it (optional). SELinux policy can handle in a much more fine-grained these restrictions, just that it's still something that not all people can deploy without some special effort and tweak up (if their system doesn't provide support for it, of course, currently Red Hat has done a great job in that terms). There's no need to sprinkle security policy all over the kernel. I completely agree. Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
vsecurity 0.2-cvs (security fix revision)
Hi, A week ago, some buffer overflow conditions inside the ACL handling code of vsecurity were fixed, more concretely in the *_read_file functions used within the vsecfs (sysfs) code to read ACL parameters. I apologize for the inconveniences of being away for a week and not announcing it before. These buffer overflow conditions were noticed at first time by Brad Spengler and more later by Nguyen Anh Quynh (who contributed many TPE related enhancements to the under-development 0.3 revision). Subsequently, the TPE code at issue, based in the first work made by IBM and more concretely, by Niki Rahimi, is also vulnerable, and if the user base makes it worthy, it should be fixed ASAP. No proof of concept code is available, at least in the public eye or under my knowledge, nor I have intention to prepare any as it's already fixed. The changes can be found in the CVS, also it's worthy to say that currently vsecurity is not prepared for the new API changes since 2.6.10, and this is on-going work for the 0.3 release (among many other enhancements and changes). http://cvs.tuxedo-es.org/cgi-bin/viewcvs.cgi/vsecurity/ Thanks for your attention, Cheers. -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
vsecurity 0.2-cvs (security fix revision)
Hi, A week ago, some buffer overflow conditions inside the ACL handling code of vsecurity were fixed, more concretely in the *_read_file functions used within the vsecfs (sysfs) code to read ACL parameters. I apologize for the inconveniences of being away for a week and not announcing it before. These buffer overflow conditions were noticed at first time by Brad Spengler and more later by Nguyen Anh Quynh (who contributed many TPE related enhancements to the under-development 0.3 revision). Subsequently, the TPE code at issue, based in the first work made by IBM and more concretely, by Niki Rahimi, is also vulnerable, and if the user base makes it worthy, it should be fixed ASAP. No proof of concept code is available, at least in the public eye or under my knowledge, nor I have intention to prepare any as it's already fixed. The changes can be found in the CVS, also it's worthy to say that currently vsecurity is not prepared for the new API changes since 2.6.10, and this is on-going work for the 0.3 release (among many other enhancements and changes). http://cvs.tuxedo-es.org/cgi-bin/viewcvs.cgi/vsecurity/ Thanks for your attention, Cheers. -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
Re: [patch 1/1] /proc/$$/ipaddr and per-task networking bits
El jue, 10-03-2005 a las 16:38 +0100, Arjan van de Ven escribió: > but tasks don't have an IP address. Hosts do. Hosts can have > multiple IP addresses. Both ipv4 and ipv6. Users don't have IP > addresses either (they do have user IDs so that link is clear). > I think I'm missing something big here. What does it *mean* for a task > to have an IP address. Once that is clear maybe I can start to > understand the rest, but until the meaning of "task has an IP address" > is better explained/more clear I think I'm stuck. (and no the output in > a log isn't a meaning, it's only a result) I think I've explained it well, more concretely, it tries to fill the ipaddr member of the task_struct structure with the IP address associated to the user running @current task/process,if available. Then, it will be attached within the proc fs in an entry called ipaddr, under the proper pid directory. The whole thing is almost self-explaining by just looking at the code. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
Re: [patch 1/1] /proc/$$/ipaddr and per-task networking bits
El jue, 10-03-2005 a las 15:26 +0100, Arjan van de Ven escribió: > a few questions > 1) Why is this a config option; if it's useful it should just be always > on really Just to be removed if it applies for mainline. > 2) Can you explain briefly what this is useful for? For keeping track on the "originating ip address of the task/process" (the ipv4 address of the user that started the task/process). It adds an ipaddr entry if available for each /proc/ entry, among the API changes. Example: [EMAIL PROTECTED]:/usr/src# cat /proc/5907/ipaddr 192.128.102.93 > 3) How does this work for existing stuff if, say, your dhcp lease > changes and your machine no longer owns a certain IP, what will happen > to the tasks? > 4) if a machine has multiple IPs.. which one is chosen ? The patch has nothing to do with this, as it's objective is different. See http://lkml.org/lkml/2005/3/10/108 and http://pearls.tuxedo-es.org/patches/selinux-avc_audit-log-curr_ip.patch if you want useful and real examples on how it works and helps. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
[patch 1/1] SELinux AVC audit log ipaddr field support (for task_struct->curr_ip)
Provides support for a new field ipaddr within the SELinux
AVC audit log, relying in task_struct->curr_ip (ipv4 only)
provided by the task-curr_ip or grSecurity patch to be applied
before.It was first implemented by Joshua Brindle (a.k.a Method)
from the Hardened Gentoo project.
An example of the audit messages with ipaddr field:
audit(1110432234.161:0): avc: denied { search } for pid=19057
exe=/usr/bin/wget name=portage dev=hda3 ino=1024647 ipaddr=192.168.1.30
scontext=root:sysadm_r:portage_fetch_t tcontext=system_u:object_r:portage_tmp_t
tclass=dir
It's also available at
http://pearls.tuxedo-es.org/patches/selinux-avc_audit-log-curr_ip.patch
Signed-off-by: Lorenzo Hernandez Garcia-Hierro <[EMAIL PROTECTED]>
---
linux-2.6.11-lorenzo/security/selinux/avc.c |6 ++
1 files changed, 6 insertions(+)
diff -puN security/selinux/avc.c~selinux-avc_audit-log-curr_ip
security/selinux/avc.c
--- linux-2.6.11/security/selinux/avc.c~selinux-avc_audit-log-curr_ip
2005-03-10 15:52:12.810227040 +0100
+++ linux-2.6.11-lorenzo/security/selinux/avc.c 2005-03-10 15:52:12.817225976
+0100
@@ -205,6 +205,12 @@ void avc_dump_query(struct audit_buffer
char *scontext;
u32 scontext_len;
+/* CONFIG_GRKERNSEC_PROC_IPADDR if grSecurity is present */
+#ifdef CONFIG_PROC_IPADDR
+ if (current->curr_ip)
+ audit_log_format(ab, "ipaddr=%u.%u.%u.%u ",
NIPQUAD(current->curr_ip));
+#endif /* CONFIG_PROC_IPADDR */
+
rc = security_sid_to_context(ssid, , _len);
if (rc)
audit_log_format(ab, "ssid=%d", ssid);
_
Cheers,
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
signature.asc
Description: This is a digitally signed message part
[patch 1/1] /proc/$$/ipaddr and per-task networking bits
return ((daddr + saddr + (sport << 8) + (dport << 16)) % size);
+}
+
+static __inline__ int
+conn_match(const struct task_struct *task, __u32 saddr, __u32 daddr,
+ __u16 sport, __u16 dport)
+{
+ if (unlikely(task != deleted_conn && task->net_saddr == saddr &&
+task->net_daddr == daddr && task->net_sport == sport &&
+task->net_dport == dport))
+ return 1;
+ else
+ return 0;
+}
+
+void net_add_to_task_ip_table(struct task_struct *task)
+{
+ unsigned int index;
+
+ if (unlikely(net_conn_table == NULL))
+ return;
+
+ if (!thread_group_leader(task))
+ task = task->group_leader;
+
+ index = conn_hash(task->net_saddr, task->net_daddr,
+ task->net_sport, task->net_dport,
+ net_conn_table_size);
+
+ spin_lock(_conn_table_lock);
+
+ while (net_conn_table[index] && net_conn_table[index] != deleted_conn) {
+ index = (index + 1) % net_conn_table_size;
+ }
+
+ net_conn_table[index] = task;
+
+ spin_unlock(_conn_table_lock);
+
+ return;
+}
+
+void net_del_task_from_ip_table_nolock(struct task_struct *task)
+{
+ unsigned int index;
+
+ if (unlikely(net_conn_table == NULL))
+ return;
+
+ if (!thread_group_leader(task))
+ task = task->group_leader;
+
+ index = conn_hash(task->net_saddr, task->net_daddr,
+ task->net_sport, task->net_dport,
+ net_conn_table_size);
+
+ while (net_conn_table[index] && !conn_match(net_conn_table[index],
+ task->net_saddr, task->net_daddr, task->net_sport,
+ task->net_dport)) {
+ index = (index + 1) % net_conn_table_size;
+ }
+
+ if (net_conn_table[index]) {
+ if (net_conn_table[(index + 1) % net_conn_table_size])
+ net_conn_table[index] = deleted_conn;
+ else
+ net_conn_table[index] = NULL;
+ }
+
+ return;
+}
+
+struct task_struct * net_lookup_task_ip_table(__u32 saddr, __u32 daddr,
+__u16 sport, __u16 dport)
+{
+ unsigned int index;
+
+ if (unlikely(net_conn_table == NULL))
+ return NULL;
+
+ index = conn_hash(saddr, daddr, sport, dport, net_conn_table_size);
+
+ while (net_conn_table[index] && !conn_match(net_conn_table[index],
+ saddr, daddr, sport, dport)) {
+ index = (index + 1) % net_conn_table_size;
+ }
+
+ return net_conn_table[index];
+}
+#endif
+
+void net_del_task_from_ip_table(struct task_struct *task)
+{
+#ifdef CONFIG_PROC_IPADDR
+ spin_lock(_conn_table_lock);
+ if (!thread_group_leader(task))
+ net_del_task_from_ip_table_nolock(task->group_leader);
+ else
+ net_del_task_from_ip_table_nolock(task);
+ spin_unlock(_conn_table_lock);
+#endif
+ return;
+}
+
+void
+proc_attach_curr_ip(const struct sock *sk)
+{
+#ifdef CONFIG_PROC_IPADDR
+ struct task_struct *p;
+ struct task_struct *set;
+ const struct inet_sock *inet = inet_sk(sk);
+
+ if (unlikely(sk->sk_protocol != IPPROTO_TCP))
+ return;
+
+ set = current;
+ if (!thread_group_leader(set))
+ set = set->group_leader;
+
+ spin_lock(_conn_table_lock);
+ p = net_lookup_task_ip_table(inet->daddr, inet->rcv_saddr,
+ inet->dport, inet->sport);
+ if (unlikely(p != NULL)) {
+ set->curr_ip = p->curr_ip;
+ set->used_accept = 1;
+ net_del_task_from_ip_table_nolock(p);
+ spin_unlock(_conn_table_lock);
+ return;
+ }
+ spin_unlock(_conn_table_lock);
+
+ set->curr_ip = inet->daddr;
+ set->used_accept = 1;
+#endif
+ return;
+}
diff -puN net/Makefile~task-curr_ip net/Makefile
--- linux-2.6.11/net/Makefile~task-curr_ip 2005-03-10 14:56:13.981846568
+0100
+++ linux-2.6.11-lorenzo/net/Makefile 2005-03-10 14:56:14.054835472 +0100
@@ -46,3 +46,7 @@ obj-$(CONFIG_IP_SCTP) += sctp/
ifeq ($(CONFIG_NET),y)
obj-$(CONFIG_SYSCTL) += sysctl_net.o
endif
+
+ifeq ($(CONFIG_NET),y)
+obj-$(CONFIG_PROC_IPADDR) += proc_ipaddr.o
+endif
Cheers,
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
signature.asc
Description: This is a digitally signed message part
[patch 1/1] /proc/$$/ipaddr and per-task networking bits
, __u32 saddr, __u32 daddr,
+ __u16 sport, __u16 dport)
+{
+ if (unlikely(task != deleted_conn task-net_saddr == saddr
+task-net_daddr == daddr task-net_sport == sport
+task-net_dport == dport))
+ return 1;
+ else
+ return 0;
+}
+
+void net_add_to_task_ip_table(struct task_struct *task)
+{
+ unsigned int index;
+
+ if (unlikely(net_conn_table == NULL))
+ return;
+
+ if (!thread_group_leader(task))
+ task = task-group_leader;
+
+ index = conn_hash(task-net_saddr, task-net_daddr,
+ task-net_sport, task-net_dport,
+ net_conn_table_size);
+
+ spin_lock(net_conn_table_lock);
+
+ while (net_conn_table[index] net_conn_table[index] != deleted_conn) {
+ index = (index + 1) % net_conn_table_size;
+ }
+
+ net_conn_table[index] = task;
+
+ spin_unlock(net_conn_table_lock);
+
+ return;
+}
+
+void net_del_task_from_ip_table_nolock(struct task_struct *task)
+{
+ unsigned int index;
+
+ if (unlikely(net_conn_table == NULL))
+ return;
+
+ if (!thread_group_leader(task))
+ task = task-group_leader;
+
+ index = conn_hash(task-net_saddr, task-net_daddr,
+ task-net_sport, task-net_dport,
+ net_conn_table_size);
+
+ while (net_conn_table[index] !conn_match(net_conn_table[index],
+ task-net_saddr, task-net_daddr, task-net_sport,
+ task-net_dport)) {
+ index = (index + 1) % net_conn_table_size;
+ }
+
+ if (net_conn_table[index]) {
+ if (net_conn_table[(index + 1) % net_conn_table_size])
+ net_conn_table[index] = deleted_conn;
+ else
+ net_conn_table[index] = NULL;
+ }
+
+ return;
+}
+
+struct task_struct * net_lookup_task_ip_table(__u32 saddr, __u32 daddr,
+__u16 sport, __u16 dport)
+{
+ unsigned int index;
+
+ if (unlikely(net_conn_table == NULL))
+ return NULL;
+
+ index = conn_hash(saddr, daddr, sport, dport, net_conn_table_size);
+
+ while (net_conn_table[index] !conn_match(net_conn_table[index],
+ saddr, daddr, sport, dport)) {
+ index = (index + 1) % net_conn_table_size;
+ }
+
+ return net_conn_table[index];
+}
+#endif
+
+void net_del_task_from_ip_table(struct task_struct *task)
+{
+#ifdef CONFIG_PROC_IPADDR
+ spin_lock(net_conn_table_lock);
+ if (!thread_group_leader(task))
+ net_del_task_from_ip_table_nolock(task-group_leader);
+ else
+ net_del_task_from_ip_table_nolock(task);
+ spin_unlock(net_conn_table_lock);
+#endif
+ return;
+}
+
+void
+proc_attach_curr_ip(const struct sock *sk)
+{
+#ifdef CONFIG_PROC_IPADDR
+ struct task_struct *p;
+ struct task_struct *set;
+ const struct inet_sock *inet = inet_sk(sk);
+
+ if (unlikely(sk-sk_protocol != IPPROTO_TCP))
+ return;
+
+ set = current;
+ if (!thread_group_leader(set))
+ set = set-group_leader;
+
+ spin_lock(net_conn_table_lock);
+ p = net_lookup_task_ip_table(inet-daddr, inet-rcv_saddr,
+ inet-dport, inet-sport);
+ if (unlikely(p != NULL)) {
+ set-curr_ip = p-curr_ip;
+ set-used_accept = 1;
+ net_del_task_from_ip_table_nolock(p);
+ spin_unlock(net_conn_table_lock);
+ return;
+ }
+ spin_unlock(net_conn_table_lock);
+
+ set-curr_ip = inet-daddr;
+ set-used_accept = 1;
+#endif
+ return;
+}
diff -puN net/Makefile~task-curr_ip net/Makefile
--- linux-2.6.11/net/Makefile~task-curr_ip 2005-03-10 14:56:13.981846568
+0100
+++ linux-2.6.11-lorenzo/net/Makefile 2005-03-10 14:56:14.054835472 +0100
@@ -46,3 +46,7 @@ obj-$(CONFIG_IP_SCTP) += sctp/
ifeq ($(CONFIG_NET),y)
obj-$(CONFIG_SYSCTL) += sysctl_net.o
endif
+
+ifeq ($(CONFIG_NET),y)
+obj-$(CONFIG_PROC_IPADDR) += proc_ipaddr.o
+endif
Cheers,
--
Lorenzo Hernández García-Hierro [EMAIL PROTECTED]
[1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org]
signature.asc
Description: This is a digitally signed message part
[patch 1/1] SELinux AVC audit log ipaddr field support (for task_struct-curr_ip)
Provides support for a new field ipaddr within the SELinux
AVC audit log, relying in task_struct-curr_ip (ipv4 only)
provided by the task-curr_ip or grSecurity patch to be applied
before.It was first implemented by Joshua Brindle (a.k.a Method)
from the Hardened Gentoo project.
An example of the audit messages with ipaddr field:
audit(1110432234.161:0): avc: denied { search } for pid=19057
exe=/usr/bin/wget name=portage dev=hda3 ino=1024647 ipaddr=192.168.1.30
scontext=root:sysadm_r:portage_fetch_t tcontext=system_u:object_r:portage_tmp_t
tclass=dir
It's also available at
http://pearls.tuxedo-es.org/patches/selinux-avc_audit-log-curr_ip.patch
Signed-off-by: Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED]
---
linux-2.6.11-lorenzo/security/selinux/avc.c |6 ++
1 files changed, 6 insertions(+)
diff -puN security/selinux/avc.c~selinux-avc_audit-log-curr_ip
security/selinux/avc.c
--- linux-2.6.11/security/selinux/avc.c~selinux-avc_audit-log-curr_ip
2005-03-10 15:52:12.810227040 +0100
+++ linux-2.6.11-lorenzo/security/selinux/avc.c 2005-03-10 15:52:12.817225976
+0100
@@ -205,6 +205,12 @@ void avc_dump_query(struct audit_buffer
char *scontext;
u32 scontext_len;
+/* CONFIG_GRKERNSEC_PROC_IPADDR if grSecurity is present */
+#ifdef CONFIG_PROC_IPADDR
+ if (current-curr_ip)
+ audit_log_format(ab, ipaddr=%u.%u.%u.%u ,
NIPQUAD(current-curr_ip));
+#endif /* CONFIG_PROC_IPADDR */
+
rc = security_sid_to_context(ssid, scontext, scontext_len);
if (rc)
audit_log_format(ab, ssid=%d, ssid);
_
Cheers,
--
Lorenzo Hernández García-Hierro [EMAIL PROTECTED]
[1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org]
signature.asc
Description: This is a digitally signed message part
Re: [patch 1/1] /proc/$$/ipaddr and per-task networking bits
El jue, 10-03-2005 a las 15:26 +0100, Arjan van de Ven escribió: a few questions 1) Why is this a config option; if it's useful it should just be always on really Just to be removed if it applies for mainline. 2) Can you explain briefly what this is useful for? For keeping track on the originating ip address of the task/process (the ipv4 address of the user that started the task/process). It adds an ipaddr entry if available for each /proc/pid entry, among the API changes. Example: [EMAIL PROTECTED]:/usr/src# cat /proc/5907/ipaddr 192.128.102.93 3) How does this work for existing stuff if, say, your dhcp lease changes and your machine no longer owns a certain IP, what will happen to the tasks? 4) if a machine has multiple IPs.. which one is chosen ? The patch has nothing to do with this, as it's objective is different. See http://lkml.org/lkml/2005/3/10/108 and http://pearls.tuxedo-es.org/patches/selinux-avc_audit-log-curr_ip.patch if you want useful and real examples on how it works and helps. Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
Re: [patch 1/1] /proc/$$/ipaddr and per-task networking bits
El jue, 10-03-2005 a las 16:38 +0100, Arjan van de Ven escribió: but tasks don't have an IP address. Hosts do. Hosts can have multiple IP addresses. Both ipv4 and ipv6. Users don't have IP addresses either (they do have user IDs so that link is clear). I think I'm missing something big here. What does it *mean* for a task to have an IP address. Once that is clear maybe I can start to understand the rest, but until the meaning of task has an IP address is better explained/more clear I think I'm stuck. (and no the output in a log isn't a meaning, it's only a result) I think I've explained it well, more concretely, it tries to fill the ipaddr member of the task_struct structure with the IP address associated to the user running @current task/process,if available. Then, it will be attached within the proc fs in an entry called ipaddr, under the proper pid directory. The whole thing is almost self-explaining by just looking at the code. Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
Re: Thoughts on the "No Linux Security Modules framework" old claims
El mié, 23-02-2005 a las 14:07 -0800, Crispin Cowan escribió: > If that is what you meant, then we had no issue. > > It looked like you were referring to Immunix because, in the quoted > text, one paragraph only discussed Immunix (by name) and then the > subsequent paragraph just said "them" and then talked about patents. > There was no mention of SCC. > > So even if you meant SCC, the casual reader only saw "Immunix" followed > by "patents", and would infer the obvious. Yes, my fault. I hope this will let readers out of any possible confusion, again, sorry for any inconveniences, wasn't my intention to create confusion around Immunix. At least from my side, I don't have fights nor bad relationships with anybody from Immunix, but also I just know a very few people from there. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Thoughts on the "No Linux Security Modules framework" old claims
El mié, 23-02-2005 a las 13:37 -0800, Crispin Cowan escribió: > Lorenzo Hernández García-Hierro wrote: > You are confused. It is Secure Computing Corporation that holds patents > that threaten SELinux > http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf > > Immunix has never threatened any open source project with patent > infringement. You got it wrong, I was talking about SCC, not Immunix, relating the TE patent, anyways, it's my fault to don't refer to SCC instead of "the enterprise" which could lead to confusion.I apologize for that. > Please get your facts straight before accusing someone of a serious act > like that. I'm sure I do, haven't accused someone, AFAIK. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Thoughts on the No Linux Security Modules framework old claims
El mié, 23-02-2005 a las 13:37 -0800, Crispin Cowan escribió: Lorenzo Hernández García-Hierro wrote: You are confused. It is Secure Computing Corporation that holds patents that threaten SELinux http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf Immunix has never threatened any open source project with patent infringement. You got it wrong, I was talking about SCC, not Immunix, relating the TE patent, anyways, it's my fault to don't refer to SCC instead of the enterprise which could lead to confusion.I apologize for that. Please get your facts straight before accusing someone of a serious act like that. I'm sure I do, haven't accused someone, AFAIK. Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Thoughts on the No Linux Security Modules framework old claims
El mié, 23-02-2005 a las 14:07 -0800, Crispin Cowan escribió: If that is what you meant, then we had no issue. It looked like you were referring to Immunix because, in the quoted text, one paragraph only discussed Immunix (by name) and then the subsequent paragraph just said them and then talked about patents. There was no mention of SCC. So even if you meant SCC, the casual reader only saw Immunix followed by patents, and would infer the obvious. Yes, my fault. I hope this will let readers out of any possible confusion, again, sorry for any inconveniences, wasn't my intention to create confusion around Immunix. At least from my side, I don't have fights nor bad relationships with anybody from Immunix, but also I just know a very few people from there. Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: JFFS2 Extended attributes support & SELinux in handhelds
El mar, 22-02-2005 a las 12:21 -0600, Josh Boyer escribió: > You should send this to the JFFS2 development list. The xattr support > is probably a JFFS3 candidate. > > The mtd tree is the most current. Any development would probably get > the most benefit from being done there. Especially since JFFS3 doesn't > exist anywhere else :). As we have talked in #mtd, I've moved everything to JFFS3 code and re-worked the pretty basic stuff that was already done, as a really dirty night-hack. I hadn't time to fix the remaining errors (no, it's not a working patch), nor the remaining "stolen" ReiserFS code that needs to be modified in order to make JFFS3 happy with it (priv. directory handling in xattr initialization, etc). I'm going to have limited time for it, I have exams these two weeks and also finish some other work in progress. I've uploaded a patch that applies to 2.6.11-rc4 tree, with latest mtd tree included. http://pearls.tuxedo-es.org/patches/mtd-jffs3-xattr-20050222-2.6.11-rc4.patch (998Kb) I would appreciate any collaboration and help with it. Cheers, thanks in advance and enjoy (not working) it. :) -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: idr_remove
El sáb, 19-02-2005 a las 23:32 +1100, Russell Coker escribió:
> http://marc.theaimsgroup.com/?l=linux-kernel=109838483518162=2
>
> I am getting messages "idr_remove called for id=0 which is not allocated"
> when
> SE Linux denies search access to /dev/pts.
>
> The attached file has some klogd output showing the situation, triggered in
> this case by installing a new kernel package on a SE Debian system. The
> above URL references Jim Houston's message with the patch to add this
> warning.
The problem seems to be in a call back from idr_remove() to
sub_remove()@/lib/idr.c:284 which leads to calling idr_remove_warning(),
doing the weird stack dump, when some logics don't work as expected.
Jan 17 13:45:43 lyta kernel: [dump_stack+23/32] dump_stack+0x17/0x20
Jan 17 13:45:43 lyta kernel: [sub_remove+233/240] sub_remove+0xe9/0xf0
Jan 17 13:45:43 lyta kernel: [idr_remove+35/144] idr_remove+0x23/0x90
The spurious function called by sub_remove() (leads to the
dump_stack+0x17/0x20):
+static void idr_remove_warning(int id)
+{
+ printk("idr_remove called for id=%d which is not allocated.\n", id);
+ dump_stack();
+}
+
The changes that lead to such warning and stack dump
@sub_remove
+ n = id & IDR_MASK;
+ if (likely(p != NULL && test_bit(n, >bitmap))){
(...etc...)
idr_remove() is called, among other places, within the Device Mapper
(DM) code that I suppose you are using, right?
I don't have time to make further checking, but seems to be somewhat
type of devices handling and IDR minor numbers allocation tracking
black magic, someone could have a further a look at it?
Cheers,
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
JFFS2 Extended attributes support & SELinux in handhelds
Hi, I've been working in implementing extended attributes support in the JFFS2 filesystem. During the (short) time I worked on it, I just decided to try to bring back the thread on SELinux in hand-held and embedded devices and see if there's someone interested in contributing to it and collaborating to make something out of it. The current work is just a draft, I've started with the standard Vanilla kernel sources plus mtd JFFS2 sources, used to patch the vanilla ones for latest code (I'm confused on which one has the most updated tree or if there are special differences between mtd's trees and vanilla's), and implemented the skeleton using the reiserfs xattr code base. Then Russell Coker commented to me that I should use the handhelds.org kernel, so, I have the doubt on which one use, even if porting the changes made to JFFS2 code base to vanilla sources wouldn't be difficult, at least I suppose. I've opened a few wiki pages for discussion and documenting until it gets further developed: http://wiki.tuxedo-es.org/tuxedo/JFFS2xattr http://wiki.tuxedo-es.org/tuxedo/SELinuxEmbedded In addition, having someone experienced with xattr API could be great, as development documentation seems inexistent, among James Morris' merged xattr consolidation code. Thanks in advance, Cheers. -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
JFFS2 Extended attributes support SELinux in handhelds
Hi, I've been working in implementing extended attributes support in the JFFS2 filesystem. During the (short) time I worked on it, I just decided to try to bring back the thread on SELinux in hand-held and embedded devices and see if there's someone interested in contributing to it and collaborating to make something out of it. The current work is just a draft, I've started with the standard Vanilla kernel sources plus mtd JFFS2 sources, used to patch the vanilla ones for latest code (I'm confused on which one has the most updated tree or if there are special differences between mtd's trees and vanilla's), and implemented the skeleton using the reiserfs xattr code base. Then Russell Coker commented to me that I should use the handhelds.org kernel, so, I have the doubt on which one use, even if porting the changes made to JFFS2 code base to vanilla sources wouldn't be difficult, at least I suppose. I've opened a few wiki pages for discussion and documenting until it gets further developed: http://wiki.tuxedo-es.org/tuxedo/JFFS2xattr http://wiki.tuxedo-es.org/tuxedo/SELinuxEmbedded In addition, having someone experienced with xattr API could be great, as development documentation seems inexistent, among James Morris' merged xattr consolidation code. Thanks in advance, Cheers. -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: idr_remove
El sáb, 19-02-2005 a las 23:32 +1100, Russell Coker escribió:
http://marc.theaimsgroup.com/?l=linux-kernelm=109838483518162w=2
I am getting messages idr_remove called for id=0 which is not allocated
when
SE Linux denies search access to /dev/pts.
The attached file has some klogd output showing the situation, triggered in
this case by installing a new kernel package on a SE Debian system. The
above URL references Jim Houston's message with the patch to add this
warning.
The problem seems to be in a call back from idr_remove() to
sub_remove()@/lib/idr.c:284 which leads to calling idr_remove_warning(),
doing the weird stack dump, when some logics don't work as expected.
Jan 17 13:45:43 lyta kernel: [dump_stack+23/32] dump_stack+0x17/0x20
Jan 17 13:45:43 lyta kernel: [sub_remove+233/240] sub_remove+0xe9/0xf0
Jan 17 13:45:43 lyta kernel: [idr_remove+35/144] idr_remove+0x23/0x90
The spurious function called by sub_remove() (leads to the
dump_stack+0x17/0x20):
+static void idr_remove_warning(int id)
+{
+ printk(idr_remove called for id=%d which is not allocated.\n, id);
+ dump_stack();
+}
+
The changes that lead to such warning and stack dump
@sub_remove
+ n = id IDR_MASK;
+ if (likely(p != NULL test_bit(n, p-bitmap))){
(...etc...)
idr_remove() is called, among other places, within the Device Mapper
(DM) code that I suppose you are using, right?
I don't have time to make further checking, but seems to be somewhat
type of devices handling and IDR minor numbers allocation tracking
black magic, someone could have a further a look at it?
Cheers,
--
Lorenzo Hernández García-Hierro [EMAIL PROTECTED]
[1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org]
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: JFFS2 Extended attributes support SELinux in handhelds
El mar, 22-02-2005 a las 12:21 -0600, Josh Boyer escribió: You should send this to the JFFS2 development list. The xattr support is probably a JFFS3 candidate. The mtd tree is the most current. Any development would probably get the most benefit from being done there. Especially since JFFS3 doesn't exist anywhere else :). As we have talked in #mtd, I've moved everything to JFFS3 code and re-worked the pretty basic stuff that was already done, as a really dirty night-hack. I hadn't time to fix the remaining errors (no, it's not a working patch), nor the remaining stolen ReiserFS code that needs to be modified in order to make JFFS3 happy with it (priv. directory handling in xattr initialization, etc). I'm going to have limited time for it, I have exams these two weeks and also finish some other work in progress. I've uploaded a patch that applies to 2.6.11-rc4 tree, with latest mtd tree included. http://pearls.tuxedo-es.org/patches/mtd-jffs3-xattr-20050222-2.6.11-rc4.patch (998Kb) I would appreciate any collaboration and help with it. Cheers, thanks in advance and enjoy (not working) it. :) -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [rsbac] Thoughts on the "No Linux Security Modules framework" old claims
od bunch of all of them, just supposed you were talking on Immunix. > When this happened, it seemed clear, that after selling the patents > anything could happen. Think of SCO and how they hindered Linux, and > then rethink what problems might appear with clearly accepted patents > all over the business and in various distributions. > > Well, I am sure most people here agree that software patents are bad > for free software, so let's not dig into this. Sure ;) > Companies are there to make money, not to provide public benefits. > Sad, but true. I can't disagree with this one, but sometimes licenses make companies doing things they even don't like, which are of our own benefit. > I appreciate you continued struggle against us thick headed developers > to get a better common solution. Just trying to help and make noise around, wondering if something comes up :) > Still, some problems are deeper than > they appear, and you will often have politics or even massive company > interests involved. Yes, sadly. Anyways, it's only a matter of politics, but a really difficult one. Cheers and many thanks for your comments, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [rsbac] Thoughts on the No Linux Security Modules framework old claims
disagree with this one, but sometimes licenses make companies doing things they even don't like, which are of our own benefit. I appreciate you continued struggle against us thick headed developers to get a better common solution. Just trying to help and make noise around, wondering if something comes up :) Still, some problems are deeper than they appear, and you will often have politics or even massive company interests involved. Yes, sadly. Anyways, it's only a matter of politics, but a really difficult one. Cheers and many thanks for your comments, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Thoughts on the "No Linux Security Modules framework" old claims
El mar, 15-02-2005 a las 23:21 -0500, [EMAIL PROTECTED] escribió: > On Tue, 15 Feb 2005 23:38:09 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= > =?ISO-8859-1?Q?Garc=EDa-Hierro?= said: > > > Yes, and that's noticed from the "official" documentation. > > But, who says that we can't place auditing facilities inside the > > existing hooks? or even file system linking related tweaks? > > Many auditing policies require an audit event to be generated if the operation > is rejected by *either* the DAC (as implemented by the file permissions > and possibly ACLs) *or* the MAC (as implemented by the LSM exit). However, > in most (all?) cases, the DAC check is made *first*, and the LSM exit isn't > even called if the DAC check fails. As a result, if you try to open() a file > and get -EPERM due to the file permissions, the LSM exit isn't called and > you can't cut an audit record there. Yes, there are many cases that apply to such scenario and context, this may be worth to work on, but think it's main shortcoming is that it cuts performance and adds further overlapping to the DAC checks, that should be the first ones being called (as most times they do) and then apply the LSM basis, so, post-processing will be only required if the DAC checks get in override or passed, without adding too-much overhead to the current behavior. So, I just agree partially, but yes, maybe modifying the DAC checks themselves and add what-ever-else helper function to handle by-default auditing in certain operations could be interesting. I think it could be worthy to have a roadmap in a wiki or even talk about a one, trying to write it, so, we all could know what needs to be improved and done, getting a higher percentage of mainline-accepted approaches. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Thoughts on the No Linux Security Modules framework old claims
El mar, 15-02-2005 a las 23:21 -0500, [EMAIL PROTECTED] escribió: On Tue, 15 Feb 2005 23:38:09 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?= said: Yes, and that's noticed from the official documentation. But, who says that we can't place auditing facilities inside the existing hooks? or even file system linking related tweaks? Many auditing policies require an audit event to be generated if the operation is rejected by *either* the DAC (as implemented by the file permissions and possibly ACLs) *or* the MAC (as implemented by the LSM exit). However, in most (all?) cases, the DAC check is made *first*, and the LSM exit isn't even called if the DAC check fails. As a result, if you try to open() a file and get -EPERM due to the file permissions, the LSM exit isn't called and you can't cut an audit record there. Yes, there are many cases that apply to such scenario and context, this may be worth to work on, but think it's main shortcoming is that it cuts performance and adds further overlapping to the DAC checks, that should be the first ones being called (as most times they do) and then apply the LSM basis, so, post-processing will be only required if the DAC checks get in override or passed, without adding too-much overhead to the current behavior. So, I just agree partially, but yes, maybe modifying the DAC checks themselves and add what-ever-else helper function to handle by-default auditing in certain operations could be interesting. I think it could be worthy to have a roadmap in a wiki or even talk about a one, trying to write it, so, we all could know what needs to be improved and done, getting a higher percentage of mainline-accepted approaches. Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Thoughts on the "No Linux Security Modules framework" old claims
said around.We all do mistakes, is matter of good intention and effort to don't make them again. As a little disclaimer, just to say that I'm pretty new here so, maybe I'm not the best one recall on this, but at least I'm making use of my rights to comment on it. Amen or what-ever-else. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Thoughts on the No Linux Security Modules framework old claims
new here so, maybe I'm not the best one recall on this, but at least I'm making use of my rights to comment on it. Amen or what-ever-else. Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] New sys_chmod() hook for the LSM framework
El mar, 08-02-2005 a las 16:15 -0800, Chris Wright escribió: > * Lorenzo Hernández García-Hierro ([EMAIL PROTECTED]) wrote: > > As commented yesterday, I was going to release a few more hooks for some > > *critical* syscalls, this one adds a hook to sys_chmod(), and makes us > > able to apply checks and logics before releasing the operation to > > sys_chmod(). > > This is exactly the kind of hook we've tried to avoid. This is really > asking for permission to alter inode attribute data. This type of > hook is incomplete because there are other ways to alter this data, > and this access is already controlled by the inode_setattr hook (as > Tony mentioned). So this is a no go. Right, the patch is no longer available as notify_change grabs the inode_setattr hook returned data. Did you checked the other one on sys_chroot()? (I've updated it a day or so ago). Cheers, thanks for commenting on it. -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] New sys_chmod() hook for the LSM framework
El mar, 08-02-2005 a las 16:15 -0800, Chris Wright escribió: * Lorenzo Hernández García-Hierro ([EMAIL PROTECTED]) wrote: As commented yesterday, I was going to release a few more hooks for some *critical* syscalls, this one adds a hook to sys_chmod(), and makes us able to apply checks and logics before releasing the operation to sys_chmod(). This is exactly the kind of hook we've tried to avoid. This is really asking for permission to alter inode attribute data. This type of hook is incomplete because there are other ways to alter this data, and this access is already controlled by the inode_setattr hook (as Tony mentioned). So this is a no go. Right, the patch is no longer available as notify_change grabs the inode_setattr hook returned data. Did you checked the other one on sys_chroot()? (I've updated it a day or so ago). Cheers, thanks for commenting on it. -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
[PATCH] New sys_chmod() hook for the LSM framework
Hi,
As commented yesterday, I was going to release a few more hooks for some
*critical* syscalls, this one adds a hook to sys_chmod(), and makes us
able to apply checks and logics before releasing the operation to
sys_chmod().
The main goal is to provide a simple way to handle chmod() calls and
apply security restrictions & checks to them, and also add add auditing
capabilities (ie.: log chmod() calls in chroot()'ed environments, etc).
Patch attached and available at:
http://pearls.tuxedo-es.org/patches/sys_chmod_lsm-hook-2.6.11-rc3.patch
I would like to see this merged, Chris should decide :)
An user of this will be, as commented in my past emails, vSecurity 0.2
release, and any other LSM module that wants to have control over
chmod()'ing.
I will make available another hook for sys_fchmod() ASAP.
Cheers and thanks in advance,
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
diff -Nur linux-2.6.11-rc3/fs/open.c linux-2.6.11-rc3.chm/fs/open.c
--- linux-2.6.11-rc3/fs/open.c 2005-02-06 21:40:40.0 +0100
+++ linux-2.6.11-rc3.chm/fs/open.c 2005-02-08 16:10:09.901293560 +0100
@@ -650,6 +650,11 @@
down(>i_sem);
if (mode == (mode_t) -1)
mode = inode->i_mode;
+
+ error = security_chmod(, inode, mode);
+ if (error)
+ goto dput_and_out;
+
newattrs.ia_mode = (mode & S_IALLUGO) | (inode->i_mode & ~S_IALLUGO);
newattrs.ia_valid = ATTR_MODE | ATTR_CTIME;
error = notify_change(nd.dentry, );
diff -Nur linux-2.6.11-rc3/include/linux/security.h linux-2.6.11-rc3.chm/include/linux/security.h
--- linux-2.6.11-rc3/include/linux/security.h 2005-02-06 21:40:27.0 +0100
+++ linux-2.6.11-rc3.chm/include/linux/security.h 2005-02-08 16:10:37.670072064 +0100
@@ -1008,6 +1008,12 @@
* @ts contains new time
* @tz contains new timezone
* Return 0 if permission is granted.
+ * @chmod:
+ * Check permission before changing file modes by sys_chmod().
+ * @nd contains the nameidata struct.
+ * @inode contains the inode struct.
+ * @mode contains the mode value.
+ * Return 0 if permission is granted.
* @vm_enough_memory:
* Check permissions for allocating a new virtual mapping.
* @pages contains the number of pages.
@@ -1044,6 +1050,7 @@
int (*quota_on) (struct dentry * dentry);
int (*syslog) (int type);
int (*settime) (struct timespec *ts, struct timezone *tz);
+ int (*chmod) (struct nameidata *nd, struct inode *inode, mode_t mode);
int (*vm_enough_memory) (long pages);
int (*bprm_alloc_security) (struct linux_binprm * bprm);
@@ -1304,6 +1311,10 @@
return security_ops->settime(ts, tz);
}
+static inline int security_chmod(struct nameidata *nd, struct inode *inode, mode_t mode)
+{
+ return security_ops->chmod(nd, inode, mode);
+}
static inline int security_vm_enough_memory(long pages)
{
@@ -1986,6 +1997,11 @@
return cap_settime(ts, tz);
}
+static inline int security_chmod(struct nameidata *nd, struct inode *inode, mode_t mode)
+{
+ return 0;
+}
+
static inline int security_vm_enough_memory(long pages)
{
return cap_vm_enough_memory(pages);
diff -Nur linux-2.6.11-rc3/security/dummy.c linux-2.6.11-rc3.chm/security/dummy.c
--- linux-2.6.11-rc3/security/dummy.c 2005-02-06 21:40:57.0 +0100
+++ linux-2.6.11-rc3.chm/security/dummy.c 2005-02-08 15:58:26.0 +0100
@@ -108,6 +108,11 @@
return 0;
}
+static int dummy_chmod(struct nameidata *nd, struct inode *inode, mode_t mode)
+{
+ return 0;
+}
+
static int dummy_vm_enough_memory(long pages)
{
int cap_sys_admin = 0;
@@ -858,6 +863,7 @@
set_to_dummy_if_null(ops, sysctl);
set_to_dummy_if_null(ops, syslog);
set_to_dummy_if_null(ops, settime);
+ set_to_dummy_if_null(ops, chmod);
set_to_dummy_if_null(ops, vm_enough_memory);
set_to_dummy_if_null(ops, bprm_alloc_security);
set_to_dummy_if_null(ops, bprm_free_security);
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] sys_chroot() hook for additional chroot() jails enforcing
El lun, 07-02-2005 a las 14:34 -0800, Chris Wright escribió:
> * Lorenzo Hernández García-Hierro ([EMAIL PROTECTED]) wrote:
> > Attached you can find a patch which adds a new hook for the sys_chroot()
> > syscall, and makes us able to add additional enforcing and security
> > checks by using the Linux Security Modules framework (ie. chdir
> > enforcing, etc).
>
> If you want to make a change like this, collapse the
> capable(CAP_SYS_CHROOT) check behind this hook, no point having two
> outcalls from same call site.
Right, did it.
New patch attached and also available at:
http://pearls.tuxedo-es.org/patches/sys_chroot_lsm-hook-2.6.11-rc3.patch
> What logic do you expect to put behind
> the chroot() hook?
For example a chdir() handling function as grsec does, and also any
other check that comes up to mind.
Cheers and again thanks for the comments,
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
diff -Nur linux-2.6.11-rc3/fs/open.c linux-2.6.11-rc3.chroot-lsm/fs/open.c
--- linux-2.6.11-rc3/fs/open.c 2005-02-06 21:40:40.0 +0100
+++ linux-2.6.11-rc3.chroot-lsm/fs/open.c 2005-02-08 15:29:40.544611912 +0100
@@ -578,9 +578,9 @@
error = permission(nd.dentry->d_inode,MAY_EXEC,);
if (error)
goto dput_and_out;
-
- error = -EPERM;
- if (!capable(CAP_SYS_CHROOT))
+
+ error = security_chroot();
+ if (error)
goto dput_and_out;
set_fs_root(current->fs, nd.mnt, nd.dentry);
diff -Nur linux-2.6.11-rc3/include/linux/security.h linux-2.6.11-rc3.chroot-lsm/include/linux/security.h
--- linux-2.6.11-rc3/include/linux/security.h 2005-02-06 21:40:27.0 +0100
+++ linux-2.6.11-rc3.chroot-lsm/include/linux/security.h 2005-02-08 15:30:54.434378960 +0100
@@ -1008,6 +1008,10 @@
* @ts contains new time
* @tz contains new timezone
* Return 0 if permission is granted.
+ * @chroot:
+ * Check permission to change the current root by sys_chroot() syscall.
+ * @nd contains the nameidata struct passed by sys_chroot()
+ * Return 0 if permission is granted.
* @vm_enough_memory:
* Check permissions for allocating a new virtual mapping.
* @pages contains the number of pages.
@@ -1040,6 +1044,7 @@
int (*acct) (struct file * file);
int (*sysctl) (struct ctl_table * table, int op);
int (*capable) (struct task_struct * tsk, int cap);
+ int (*chroot) (struct nameidata * nd);
int (*quotactl) (int cmds, int type, int id, struct super_block * sb);
int (*quota_on) (struct dentry * dentry);
int (*syslog) (int type);
@@ -1304,6 +1309,10 @@
return security_ops->settime(ts, tz);
}
+static inline int security_chroot(struct nameidata *nd)
+{
+ return security_ops->chroot(nd);
+}
static inline int security_vm_enough_memory(long pages)
{
@@ -1986,6 +1995,14 @@
return cap_settime(ts, tz);
}
+static inline int security_chroot(struct nameidata *nd)
+{
+ if (!capable(CAP_SYS_CHROOT))
+ return -EPERM;
+
+ return 0;
+}
+
static inline int security_vm_enough_memory(long pages)
{
return cap_vm_enough_memory(pages);
diff -Nur linux-2.6.11-rc3/security/dummy.c linux-2.6.11-rc3.chroot-lsm/security/dummy.c
--- linux-2.6.11-rc3/security/dummy.c 2005-02-06 21:40:57.0 +0100
+++ linux-2.6.11-rc3.chroot-lsm/security/dummy.c 2005-02-08 15:29:55.034409128 +0100
@@ -101,6 +101,14 @@
return 0;
}
+static int dummy_chroot(struct nameidata *nd)
+{
+ if (!capable(CAP_SYS_CHROOT))
+ return -EPERM;
+
+ return 0;
+}
+
static int dummy_settime(struct timespec *ts, struct timezone *tz)
{
if (!capable(CAP_SYS_TIME))
@@ -858,6 +866,7 @@
set_to_dummy_if_null(ops, sysctl);
set_to_dummy_if_null(ops, syslog);
set_to_dummy_if_null(ops, settime);
+ set_to_dummy_if_null(ops, chroot);
set_to_dummy_if_null(ops, vm_enough_memory);
set_to_dummy_if_null(ops, bprm_alloc_security);
set_to_dummy_if_null(ops, bprm_free_security);
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] sys_chroot() hook for additional chroot() jails enforcing
El lun, 07-02-2005 a las 14:34 -0800, Chris Wright escribió:
* Lorenzo Hernández García-Hierro ([EMAIL PROTECTED]) wrote:
Attached you can find a patch which adds a new hook for the sys_chroot()
syscall, and makes us able to add additional enforcing and security
checks by using the Linux Security Modules framework (ie. chdir
enforcing, etc).
If you want to make a change like this, collapse the
capable(CAP_SYS_CHROOT) check behind this hook, no point having two
outcalls from same call site.
Right, did it.
New patch attached and also available at:
http://pearls.tuxedo-es.org/patches/sys_chroot_lsm-hook-2.6.11-rc3.patch
What logic do you expect to put behind
the chroot() hook?
For example a chdir() handling function as grsec does, and also any
other check that comes up to mind.
Cheers and again thanks for the comments,
--
Lorenzo Hernández García-Hierro [EMAIL PROTECTED]
[1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org]
diff -Nur linux-2.6.11-rc3/fs/open.c linux-2.6.11-rc3.chroot-lsm/fs/open.c
--- linux-2.6.11-rc3/fs/open.c 2005-02-06 21:40:40.0 +0100
+++ linux-2.6.11-rc3.chroot-lsm/fs/open.c 2005-02-08 15:29:40.544611912 +0100
@@ -578,9 +578,9 @@
error = permission(nd.dentry-d_inode,MAY_EXEC,nd);
if (error)
goto dput_and_out;
-
- error = -EPERM;
- if (!capable(CAP_SYS_CHROOT))
+
+ error = security_chroot(nd);
+ if (error)
goto dput_and_out;
set_fs_root(current-fs, nd.mnt, nd.dentry);
diff -Nur linux-2.6.11-rc3/include/linux/security.h linux-2.6.11-rc3.chroot-lsm/include/linux/security.h
--- linux-2.6.11-rc3/include/linux/security.h 2005-02-06 21:40:27.0 +0100
+++ linux-2.6.11-rc3.chroot-lsm/include/linux/security.h 2005-02-08 15:30:54.434378960 +0100
@@ -1008,6 +1008,10 @@
* @ts contains new time
* @tz contains new timezone
* Return 0 if permission is granted.
+ * @chroot:
+ * Check permission to change the current root by sys_chroot() syscall.
+ * @nd contains the nameidata struct passed by sys_chroot()
+ * Return 0 if permission is granted.
* @vm_enough_memory:
* Check permissions for allocating a new virtual mapping.
* @pages contains the number of pages.
@@ -1040,6 +1044,7 @@
int (*acct) (struct file * file);
int (*sysctl) (struct ctl_table * table, int op);
int (*capable) (struct task_struct * tsk, int cap);
+ int (*chroot) (struct nameidata * nd);
int (*quotactl) (int cmds, int type, int id, struct super_block * sb);
int (*quota_on) (struct dentry * dentry);
int (*syslog) (int type);
@@ -1304,6 +1309,10 @@
return security_ops-settime(ts, tz);
}
+static inline int security_chroot(struct nameidata *nd)
+{
+ return security_ops-chroot(nd);
+}
static inline int security_vm_enough_memory(long pages)
{
@@ -1986,6 +1995,14 @@
return cap_settime(ts, tz);
}
+static inline int security_chroot(struct nameidata *nd)
+{
+ if (!capable(CAP_SYS_CHROOT))
+ return -EPERM;
+
+ return 0;
+}
+
static inline int security_vm_enough_memory(long pages)
{
return cap_vm_enough_memory(pages);
diff -Nur linux-2.6.11-rc3/security/dummy.c linux-2.6.11-rc3.chroot-lsm/security/dummy.c
--- linux-2.6.11-rc3/security/dummy.c 2005-02-06 21:40:57.0 +0100
+++ linux-2.6.11-rc3.chroot-lsm/security/dummy.c 2005-02-08 15:29:55.034409128 +0100
@@ -101,6 +101,14 @@
return 0;
}
+static int dummy_chroot(struct nameidata *nd)
+{
+ if (!capable(CAP_SYS_CHROOT))
+ return -EPERM;
+
+ return 0;
+}
+
static int dummy_settime(struct timespec *ts, struct timezone *tz)
{
if (!capable(CAP_SYS_TIME))
@@ -858,6 +866,7 @@
set_to_dummy_if_null(ops, sysctl);
set_to_dummy_if_null(ops, syslog);
set_to_dummy_if_null(ops, settime);
+ set_to_dummy_if_null(ops, chroot);
set_to_dummy_if_null(ops, vm_enough_memory);
set_to_dummy_if_null(ops, bprm_alloc_security);
set_to_dummy_if_null(ops, bprm_free_security);
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
[PATCH] New sys_chmod() hook for the LSM framework
Hi,
As commented yesterday, I was going to release a few more hooks for some
*critical* syscalls, this one adds a hook to sys_chmod(), and makes us
able to apply checks and logics before releasing the operation to
sys_chmod().
The main goal is to provide a simple way to handle chmod() calls and
apply security restrictions checks to them, and also add add auditing
capabilities (ie.: log chmod() calls in chroot()'ed environments, etc).
Patch attached and available at:
http://pearls.tuxedo-es.org/patches/sys_chmod_lsm-hook-2.6.11-rc3.patch
I would like to see this merged, Chris should decide :)
An user of this will be, as commented in my past emails, vSecurity 0.2
release, and any other LSM module that wants to have control over
chmod()'ing.
I will make available another hook for sys_fchmod() ASAP.
Cheers and thanks in advance,
--
Lorenzo Hernández García-Hierro [EMAIL PROTECTED]
[1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org]
diff -Nur linux-2.6.11-rc3/fs/open.c linux-2.6.11-rc3.chm/fs/open.c
--- linux-2.6.11-rc3/fs/open.c 2005-02-06 21:40:40.0 +0100
+++ linux-2.6.11-rc3.chm/fs/open.c 2005-02-08 16:10:09.901293560 +0100
@@ -650,6 +650,11 @@
down(inode-i_sem);
if (mode == (mode_t) -1)
mode = inode-i_mode;
+
+ error = security_chmod(nd, inode, mode);
+ if (error)
+ goto dput_and_out;
+
newattrs.ia_mode = (mode S_IALLUGO) | (inode-i_mode ~S_IALLUGO);
newattrs.ia_valid = ATTR_MODE | ATTR_CTIME;
error = notify_change(nd.dentry, newattrs);
diff -Nur linux-2.6.11-rc3/include/linux/security.h linux-2.6.11-rc3.chm/include/linux/security.h
--- linux-2.6.11-rc3/include/linux/security.h 2005-02-06 21:40:27.0 +0100
+++ linux-2.6.11-rc3.chm/include/linux/security.h 2005-02-08 16:10:37.670072064 +0100
@@ -1008,6 +1008,12 @@
* @ts contains new time
* @tz contains new timezone
* Return 0 if permission is granted.
+ * @chmod:
+ * Check permission before changing file modes by sys_chmod().
+ * @nd contains the nameidata struct.
+ * @inode contains the inode struct.
+ * @mode contains the mode value.
+ * Return 0 if permission is granted.
* @vm_enough_memory:
* Check permissions for allocating a new virtual mapping.
* @pages contains the number of pages.
@@ -1044,6 +1050,7 @@
int (*quota_on) (struct dentry * dentry);
int (*syslog) (int type);
int (*settime) (struct timespec *ts, struct timezone *tz);
+ int (*chmod) (struct nameidata *nd, struct inode *inode, mode_t mode);
int (*vm_enough_memory) (long pages);
int (*bprm_alloc_security) (struct linux_binprm * bprm);
@@ -1304,6 +1311,10 @@
return security_ops-settime(ts, tz);
}
+static inline int security_chmod(struct nameidata *nd, struct inode *inode, mode_t mode)
+{
+ return security_ops-chmod(nd, inode, mode);
+}
static inline int security_vm_enough_memory(long pages)
{
@@ -1986,6 +1997,11 @@
return cap_settime(ts, tz);
}
+static inline int security_chmod(struct nameidata *nd, struct inode *inode, mode_t mode)
+{
+ return 0;
+}
+
static inline int security_vm_enough_memory(long pages)
{
return cap_vm_enough_memory(pages);
diff -Nur linux-2.6.11-rc3/security/dummy.c linux-2.6.11-rc3.chm/security/dummy.c
--- linux-2.6.11-rc3/security/dummy.c 2005-02-06 21:40:57.0 +0100
+++ linux-2.6.11-rc3.chm/security/dummy.c 2005-02-08 15:58:26.0 +0100
@@ -108,6 +108,11 @@
return 0;
}
+static int dummy_chmod(struct nameidata *nd, struct inode *inode, mode_t mode)
+{
+ return 0;
+}
+
static int dummy_vm_enough_memory(long pages)
{
int cap_sys_admin = 0;
@@ -858,6 +863,7 @@
set_to_dummy_if_null(ops, sysctl);
set_to_dummy_if_null(ops, syslog);
set_to_dummy_if_null(ops, settime);
+ set_to_dummy_if_null(ops, chmod);
set_to_dummy_if_null(ops, vm_enough_memory);
set_to_dummy_if_null(ops, bprm_alloc_security);
set_to_dummy_if_null(ops, bprm_free_security);
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] sys_chroot() hook for additional chroot() jails enforcing
El lun, 07-02-2005 a las 16:50 -0600, Serge E. Hallyn escribió: > Hi, > > If I understood you correct earlier, the only policy you needed to > enforce was to prevent double-chrooting. If that is the case, why is it > not sufficient to keep a "process-has-used-chroot" flag in > current->security which is set on the first call to > capable(CAP_SYS_CHROOT) and inherited by forked children, after which > calls to capable(CAP_SYS_CHROOT) are refused? > > Of course if you need to do more, then a hook might be necessary. Yeah, checking that process is chrooted using the current macro and denying if capable() gets it trying to access CAP_SYS_CHROOT it's the way that vSecurity currently does it. But the hook will have to handle some chdir enforcing that can't be done with current hooks, I will explain it further tomorrow. It's too late here ;) Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
[PATCH] sys_chroot() hook for additional chroot() jails enforcing
Hi,
Attached you can find a patch which adds a new hook for the sys_chroot()
syscall, and makes us able to add additional enforcing and security
checks by using the Linux Security Modules framework (ie. chdir
enforcing, etc).
Current user of the hook is the forthcoming 0.2 revision of vSecurity.
With it, and used within an LSM module, we can achieve the goal of
enforcing and apply some hardening to the sys_chroot() syscall.
Even if chroot jails are broken by design, in terms of security, with a
few changes to their base and some syscalls that it relies with, we can
achieve the goal of preventing some of the already known attacks against
them.
I will make available some patches for other syscalls as well
(sys_fchmod(), sys_chmod(), ...), that will add a few more hooks to the
LSM framework, in the hope that they will be useful.
The patch can be retrieved too from:
http://pearls.tuxedo-es.org/patches/sys_chroot_lsm-hook-2.6.11-rc3.patch
Thanks in advance, and, again, I will appreciate any suggestions on
which hooks are good candidates to be added.
Feel free to edit tuxedo-es.org wiki at http://wiki.tuxedo-es.org/LSM
and put suggestions & comments there.
Cheers,
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
diff -Nur linux-2.6.11-rc3/fs/open.c linux-2.6.11-rc3.chroot-lsm/fs/open.c
--- linux-2.6.11-rc3/fs/open.c 2005-02-06 21:40:40.0 +0100
+++ linux-2.6.11-rc3.chroot-lsm/fs/open.c 2005-02-07 21:42:45.0 +0100
@@ -582,6 +582,10 @@
error = -EPERM;
if (!capable(CAP_SYS_CHROOT))
goto dput_and_out;
+
+ error = security_chroot();
+ if (error)
+ goto dput_and_out;
set_fs_root(current->fs, nd.mnt, nd.dentry);
set_fs_altroot();
diff -Nur linux-2.6.11-rc3/include/linux/security.h linux-2.6.11-rc3.chroot-lsm/include/linux/security.h
--- linux-2.6.11-rc3/include/linux/security.h 2005-02-06 21:40:27.0 +0100
+++ linux-2.6.11-rc3.chroot-lsm/include/linux/security.h 2005-02-07 21:10:05.0 +0100
@@ -1008,6 +1008,10 @@
* @ts contains new time
* @tz contains new timezone
* Return 0 if permission is granted.
+ * @chroot:
+ * Check permission to change the current root by sys_chroot() syscall.
+ * @nd contains the nameidata struct passed by sys_chroot()
+ * Return 0 if permission is granted.
* @vm_enough_memory:
* Check permissions for allocating a new virtual mapping.
* @pages contains the number of pages.
@@ -1040,6 +1044,7 @@
int (*acct) (struct file * file);
int (*sysctl) (struct ctl_table * table, int op);
int (*capable) (struct task_struct * tsk, int cap);
+ int (*chroot) (struct nameidata * nd);
int (*quotactl) (int cmds, int type, int id, struct super_block * sb);
int (*quota_on) (struct dentry * dentry);
int (*syslog) (int type);
@@ -1304,6 +1309,10 @@
return security_ops->settime(ts, tz);
}
+static inline int security_chroot(struct nameidata *nd)
+{
+ return security_ops->chroot(nd);
+}
static inline int security_vm_enough_memory(long pages)
{
@@ -1986,6 +1995,11 @@
return cap_settime(ts, tz);
}
+static inline int security_chroot(struct nameidata *nd)
+{
+ return 0;
+}
+
static inline int security_vm_enough_memory(long pages)
{
return cap_vm_enough_memory(pages);
diff -Nur linux-2.6.11-rc3/security/dummy.c linux-2.6.11-rc3.chroot-lsm/security/dummy.c
--- linux-2.6.11-rc3/security/dummy.c 2005-02-06 21:40:57.0 +0100
+++ linux-2.6.11-rc3.chroot-lsm/security/dummy.c 2005-02-07 21:12:01.0 +0100
@@ -101,6 +101,11 @@
return 0;
}
+static int dummy_chroot(struct nameidata *nd)
+{
+ return 0;
+}
+
static int dummy_settime(struct timespec *ts, struct timezone *tz)
{
if (!capable(CAP_SYS_TIME))
@@ -858,6 +863,7 @@
set_to_dummy_if_null(ops, sysctl);
set_to_dummy_if_null(ops, syslog);
set_to_dummy_if_null(ops, settime);
+ set_to_dummy_if_null(ops, chroot);
set_to_dummy_if_null(ops, vm_enough_memory);
set_to_dummy_if_null(ops, bprm_alloc_security);
set_to_dummy_if_null(ops, bprm_free_security);
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] Filesystem linking protections
El lun, 07-02-2005 a las 16:45 -0500, [EMAIL PROTECTED] escribió: > On Mon, 07 Feb 2005 20:34:33 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= > =?ISO-8859-1?Q?Garc=EDa-Hierro?= said: > > > But It's better to give users a "secure-by-default" status, at least on > > those parts that don't affect negatively the stability or the > > performance itself. > > It's still policy, and should be put someplace where users can manage it. > You're changing the behavior from what POSIX specifies, and that's in general > a no-no for mainline kernel code. A sysctl can be a good option, creating a CTL_SECURITY and then registering stuff under it, but this requires to have the kernel hackers agree with implementing a new security suite and such. In short, re-inventing the wheel. > Like an LSM, which happens to be there so users can impose policy without > making any code changes to the kernel. Implementing a policy that results in > non-POSIXy behavior in an LSM is perfectly OK.. ;) It's currently made in vSecurity :) > > The LSM hook call is before the check, so, LSM framework still has the > > control over it, until it releases the operation giving control back to > > the standard function. > > Right.. Which means LSM can stop that particular attack even faster than > your patch.. ;) At least I don't interfere with LSM, so, if no LSM hook adds it's own security checks, then it gets used. > > If users must rely on LSM or other external solutions for applying basic > > security checks (as the framework itself only provides the way to apply > > them, the checks need to be implemented in a module), then we are making > > them unable to be protected using the "default" configuration. > > You're making the very rash assumption that a hard-coded one-size-fits all > "default" that behaves differently than POSIX is suitable for all sites, > including sites that run software that gets broken by this change, and > things like embedded systems where it's not a concern at all, and sites that > already implement some *other* system to ensure that it's not an issue (for > instance, by using an SELinux policy...) Good point, then the solution is to make it config-dependent, and that's a thing that kernel hackers seem to dislike. Lemme know what's the final thought on this, so, I could work out it and give what you want, without time loss and we all can feel happy with it :) Cheers and thanks for the comments, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] Filesystem linking protections
El lun, 07-02-2005 a las 11:12 -0800, Chris Wright escribió: > * Lorenzo Hernández García-Hierro ([EMAIL PROTECTED]) wrote: > > This patch adds two checks to do_follow_link() and sys_link(), for > > prevent users to follow (untrusted) symlinks owned by other users in > > world-writable +t directories (i.e. /tmp), unless the owner of the > > symlink is the owner of the directory, users will also not be able to > > hardlink to files they do not own. > > > > The direct advantage of this pretty simple patch is that /tmp races will > > be prevented. > > The disadvantage is that it can break things and places policy in the > kernel. It's just like DAC then, because it never applies any policy than a simple check relying on kernel's DAC, and standard capabilities & permissions.DAC-related checks are placed all over the place, but maybe the place is lacking of some ones that may be important. About what things it can break, I haven't noticed any issue on it (at least regarding grSecurity or OpenWall), but of course I would appreciate a lot any information on them, so, I could report to the developers that are currently using this in their own solutions. Thanks in advance, Cheers. -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] Filesystem linking protections
El lun, 07-02-2005 a las 14:14 -0500, [EMAIL PROTECTED] escribió: > On Mon, 07 Feb 2005 19:57:06 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= > =?ISO-8859-1?Q?Garc=EDa-Hierro?= said: > > > This patch adds two checks to do_follow_link() and sys_link(), for > > prevent users to follow (untrusted) symlinks owned by other users in > > world-writable +t directories (i.e. /tmp), unless the owner of the > > symlink is the owner of the directory, users will also not be able to > > hardlink to files they do not own. > > This should be done using the LSM framework. That's what it's *THERE* for. > I've previously posted an LSM that does these checks (and a few others), it > should be in the archives. vSecurity also implements this and many other "ported" features from OpenWall and grSecurity. But It's better to give users a "secure-by-default" status, at least on those parts that don't affect negatively the stability or the performance itself. The LSM hook call is before the check, so, LSM framework still has the control over it, until it releases the operation giving control back to the standard function. If users must rely on LSM or other external solutions for applying basic security checks (as the framework itself only provides the way to apply them, the checks need to be implemented in a module), then we are making them unable to be protected using the "default" configuration. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
[PATCH] Filesystem linking protections
Hi,
This patch adds two checks to do_follow_link() and sys_link(), for
prevent users to follow (untrusted) symlinks owned by other users in
world-writable +t directories (i.e. /tmp), unless the owner of the
symlink is the owner of the directory, users will also not be able to
hardlink to files they do not own.
The direct advantage of this pretty simple patch is that /tmp races will
be prevented.
Results reported by the Collision Regression Test Suite with patch
applied:
(...)
Symlink restrictions : Not vulnerable
Hardlinking restrictions : Not vulnerable
(...)
Results with patch *not applied*:
(...)
Symlink restrictions : Vulnerable
Hardlinking restrictions : Vulnerable
(...)
This patch is based on grSecurity linking protections, but first
implemented by the OpenWall patch.
I propose it's merging, as the overhead is *minimal* (if there's any
overhead), because the modified functions get called only once when
following a symlink or creating a hardlink.
The patch can be also downloaded from:
http://pearls.tuxedo-es.org/patches/linking-protections-2.6.11-rc3.patch
Cheers,
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
diff -Nur linux-2.6.11-rc3/fs/namei.c linux-2.6.11-rc3.slink/fs/namei.c
--- linux-2.6.11-rc3/fs/namei.c 2005-02-06 21:40:41.0 +0100
+++ linux-2.6.11-rc3.slink/fs/namei.c 2005-02-07 19:15:22.690689272 +0100
@@ -519,6 +519,19 @@
err = security_inode_follow_link(dentry, nd);
if (err)
goto loop;
+
+ /* Prevent users to follow symlinks owned by other users in
+ * world-writable +t directories, unless the owner of the
+ * symlink is the owner of the directory.
+ */
+ if (S_ISLNK(dentry->d_inode->i_mode) &&
+ (dentry->d_parent->d_inode->i_mode & S_ISVTX)
+ && (dentry->d_parent->d_inode->i_uid != dentry->d_inode->i_uid) &&
+ (dentry->d_parent->d_inode->i_mode & S_IWOTH) && (current->fsuid != dentry->d_inode->i_uid)) {
+ err = -EACCES;
+ goto loop;
+ }
+
current->link_count++;
current->total_link_count++;
nd->depth++;
@@ -1985,7 +1998,22 @@
new_dentry = lookup_create(, 0);
error = PTR_ERR(new_dentry);
if (!IS_ERR(new_dentry)) {
- error = vfs_link(old_nd.dentry, nd.dentry->d_inode, new_dentry);
+ error = 0;
+
+ /* Check that the user who is trying to make the hardlink owns
+ * the target file being linked (DAC->@old_nd.dentry->d_inode) */
+ if (current->fsuid != old_nd.dentry->d_inode->i_uid &&
+ (!S_ISREG(old_nd.dentry->d_inode->i_mode) || (old_nd.dentry->d_inode->i_mode & S_ISUID) ||
+ ((old_nd.dentry->d_inode->i_mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) ||
+ (generic_permission(old_nd.dentry->d_inode, MAY_READ | MAY_WRITE, NULL))) &&
+ !capable(CAP_FOWNER) && current->uid) {
+ error = -EPERM;
+ }
+
+ /* If @error is empty, then we apply the *normal* behavior */
+ if (!error)
+ error = vfs_link(old_nd.dentry, nd.dentry->d_inode, new_dentry);
+
dput(new_dentry);
}
up(>d_inode->i_sem);
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
[PATCH] Filesystem linking protections
Hi,
This patch adds two checks to do_follow_link() and sys_link(), for
prevent users to follow (untrusted) symlinks owned by other users in
world-writable +t directories (i.e. /tmp), unless the owner of the
symlink is the owner of the directory, users will also not be able to
hardlink to files they do not own.
The direct advantage of this pretty simple patch is that /tmp races will
be prevented.
Results reported by the Collision Regression Test Suite with patch
applied:
(...)
Symlink restrictions : Not vulnerable
Hardlinking restrictions : Not vulnerable
(...)
Results with patch *not applied*:
(...)
Symlink restrictions : Vulnerable
Hardlinking restrictions : Vulnerable
(...)
This patch is based on grSecurity linking protections, but first
implemented by the OpenWall patch.
I propose it's merging, as the overhead is *minimal* (if there's any
overhead), because the modified functions get called only once when
following a symlink or creating a hardlink.
The patch can be also downloaded from:
http://pearls.tuxedo-es.org/patches/linking-protections-2.6.11-rc3.patch
Cheers,
--
Lorenzo Hernández García-Hierro [EMAIL PROTECTED]
[1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org]
diff -Nur linux-2.6.11-rc3/fs/namei.c linux-2.6.11-rc3.slink/fs/namei.c
--- linux-2.6.11-rc3/fs/namei.c 2005-02-06 21:40:41.0 +0100
+++ linux-2.6.11-rc3.slink/fs/namei.c 2005-02-07 19:15:22.690689272 +0100
@@ -519,6 +519,19 @@
err = security_inode_follow_link(dentry, nd);
if (err)
goto loop;
+
+ /* Prevent users to follow symlinks owned by other users in
+ * world-writable +t directories, unless the owner of the
+ * symlink is the owner of the directory.
+ */
+ if (S_ISLNK(dentry-d_inode-i_mode)
+ (dentry-d_parent-d_inode-i_mode S_ISVTX)
+ (dentry-d_parent-d_inode-i_uid != dentry-d_inode-i_uid)
+ (dentry-d_parent-d_inode-i_mode S_IWOTH) (current-fsuid != dentry-d_inode-i_uid)) {
+ err = -EACCES;
+ goto loop;
+ }
+
current-link_count++;
current-total_link_count++;
nd-depth++;
@@ -1985,7 +1998,22 @@
new_dentry = lookup_create(nd, 0);
error = PTR_ERR(new_dentry);
if (!IS_ERR(new_dentry)) {
- error = vfs_link(old_nd.dentry, nd.dentry-d_inode, new_dentry);
+ error = 0;
+
+ /* Check that the user who is trying to make the hardlink owns
+ * the target file being linked (DAC-@old_nd.dentry-d_inode) */
+ if (current-fsuid != old_nd.dentry-d_inode-i_uid
+ (!S_ISREG(old_nd.dentry-d_inode-i_mode) || (old_nd.dentry-d_inode-i_mode S_ISUID) ||
+ ((old_nd.dentry-d_inode-i_mode (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) ||
+ (generic_permission(old_nd.dentry-d_inode, MAY_READ | MAY_WRITE, NULL)))
+ !capable(CAP_FOWNER) current-uid) {
+ error = -EPERM;
+ }
+
+ /* If @error is empty, then we apply the *normal* behavior */
+ if (!error)
+ error = vfs_link(old_nd.dentry, nd.dentry-d_inode, new_dentry);
+
dput(new_dentry);
}
up(nd.dentry-d_inode-i_sem);
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] Filesystem linking protections
El lun, 07-02-2005 a las 14:14 -0500, [EMAIL PROTECTED] escribió: On Mon, 07 Feb 2005 19:57:06 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?= said: This patch adds two checks to do_follow_link() and sys_link(), for prevent users to follow (untrusted) symlinks owned by other users in world-writable +t directories (i.e. /tmp), unless the owner of the symlink is the owner of the directory, users will also not be able to hardlink to files they do not own. This should be done using the LSM framework. That's what it's *THERE* for. I've previously posted an LSM that does these checks (and a few others), it should be in the archives. vSecurity also implements this and many other ported features from OpenWall and grSecurity. But It's better to give users a secure-by-default status, at least on those parts that don't affect negatively the stability or the performance itself. The LSM hook call is before the check, so, LSM framework still has the control over it, until it releases the operation giving control back to the standard function. If users must rely on LSM or other external solutions for applying basic security checks (as the framework itself only provides the way to apply them, the checks need to be implemented in a module), then we are making them unable to be protected using the default configuration. Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] Filesystem linking protections
El lun, 07-02-2005 a las 11:12 -0800, Chris Wright escribió: * Lorenzo Hernández García-Hierro ([EMAIL PROTECTED]) wrote: This patch adds two checks to do_follow_link() and sys_link(), for prevent users to follow (untrusted) symlinks owned by other users in world-writable +t directories (i.e. /tmp), unless the owner of the symlink is the owner of the directory, users will also not be able to hardlink to files they do not own. The direct advantage of this pretty simple patch is that /tmp races will be prevented. The disadvantage is that it can break things and places policy in the kernel. It's just like DAC then, because it never applies any policy than a simple check relying on kernel's DAC, and standard capabilities permissions.DAC-related checks are placed all over the place, but maybe the place is lacking of some ones that may be important. About what things it can break, I haven't noticed any issue on it (at least regarding grSecurity or OpenWall), but of course I would appreciate a lot any information on them, so, I could report to the developers that are currently using this in their own solutions. Thanks in advance, Cheers. -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] Filesystem linking protections
El lun, 07-02-2005 a las 16:45 -0500, [EMAIL PROTECTED] escribió: On Mon, 07 Feb 2005 20:34:33 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?= said: But It's better to give users a secure-by-default status, at least on those parts that don't affect negatively the stability or the performance itself. It's still policy, and should be put someplace where users can manage it. You're changing the behavior from what POSIX specifies, and that's in general a no-no for mainline kernel code. A sysctl can be a good option, creating a CTL_SECURITY and then registering stuff under it, but this requires to have the kernel hackers agree with implementing a new security suite and such. In short, re-inventing the wheel. Like an LSM, which happens to be there so users can impose policy without making any code changes to the kernel. Implementing a policy that results in non-POSIXy behavior in an LSM is perfectly OK.. ;) It's currently made in vSecurity :) The LSM hook call is before the check, so, LSM framework still has the control over it, until it releases the operation giving control back to the standard function. Right.. Which means LSM can stop that particular attack even faster than your patch.. ;) At least I don't interfere with LSM, so, if no LSM hook adds it's own security checks, then it gets used. If users must rely on LSM or other external solutions for applying basic security checks (as the framework itself only provides the way to apply them, the checks need to be implemented in a module), then we are making them unable to be protected using the default configuration. You're making the very rash assumption that a hard-coded one-size-fits all default that behaves differently than POSIX is suitable for all sites, including sites that run software that gets broken by this change, and things like embedded systems where it's not a concern at all, and sites that already implement some *other* system to ensure that it's not an issue (for instance, by using an SELinux policy...) Good point, then the solution is to make it config-dependent, and that's a thing that kernel hackers seem to dislike. Lemme know what's the final thought on this, so, I could work out it and give what you want, without time loss and we all can feel happy with it :) Cheers and thanks for the comments, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
[PATCH] sys_chroot() hook for additional chroot() jails enforcing
Hi,
Attached you can find a patch which adds a new hook for the sys_chroot()
syscall, and makes us able to add additional enforcing and security
checks by using the Linux Security Modules framework (ie. chdir
enforcing, etc).
Current user of the hook is the forthcoming 0.2 revision of vSecurity.
With it, and used within an LSM module, we can achieve the goal of
enforcing and apply some hardening to the sys_chroot() syscall.
Even if chroot jails are broken by design, in terms of security, with a
few changes to their base and some syscalls that it relies with, we can
achieve the goal of preventing some of the already known attacks against
them.
I will make available some patches for other syscalls as well
(sys_fchmod(), sys_chmod(), ...), that will add a few more hooks to the
LSM framework, in the hope that they will be useful.
The patch can be retrieved too from:
http://pearls.tuxedo-es.org/patches/sys_chroot_lsm-hook-2.6.11-rc3.patch
Thanks in advance, and, again, I will appreciate any suggestions on
which hooks are good candidates to be added.
Feel free to edit tuxedo-es.org wiki at http://wiki.tuxedo-es.org/LSM
and put suggestions comments there.
Cheers,
--
Lorenzo Hernández García-Hierro [EMAIL PROTECTED]
[1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org]
diff -Nur linux-2.6.11-rc3/fs/open.c linux-2.6.11-rc3.chroot-lsm/fs/open.c
--- linux-2.6.11-rc3/fs/open.c 2005-02-06 21:40:40.0 +0100
+++ linux-2.6.11-rc3.chroot-lsm/fs/open.c 2005-02-07 21:42:45.0 +0100
@@ -582,6 +582,10 @@
error = -EPERM;
if (!capable(CAP_SYS_CHROOT))
goto dput_and_out;
+
+ error = security_chroot(nd);
+ if (error)
+ goto dput_and_out;
set_fs_root(current-fs, nd.mnt, nd.dentry);
set_fs_altroot();
diff -Nur linux-2.6.11-rc3/include/linux/security.h linux-2.6.11-rc3.chroot-lsm/include/linux/security.h
--- linux-2.6.11-rc3/include/linux/security.h 2005-02-06 21:40:27.0 +0100
+++ linux-2.6.11-rc3.chroot-lsm/include/linux/security.h 2005-02-07 21:10:05.0 +0100
@@ -1008,6 +1008,10 @@
* @ts contains new time
* @tz contains new timezone
* Return 0 if permission is granted.
+ * @chroot:
+ * Check permission to change the current root by sys_chroot() syscall.
+ * @nd contains the nameidata struct passed by sys_chroot()
+ * Return 0 if permission is granted.
* @vm_enough_memory:
* Check permissions for allocating a new virtual mapping.
* @pages contains the number of pages.
@@ -1040,6 +1044,7 @@
int (*acct) (struct file * file);
int (*sysctl) (struct ctl_table * table, int op);
int (*capable) (struct task_struct * tsk, int cap);
+ int (*chroot) (struct nameidata * nd);
int (*quotactl) (int cmds, int type, int id, struct super_block * sb);
int (*quota_on) (struct dentry * dentry);
int (*syslog) (int type);
@@ -1304,6 +1309,10 @@
return security_ops-settime(ts, tz);
}
+static inline int security_chroot(struct nameidata *nd)
+{
+ return security_ops-chroot(nd);
+}
static inline int security_vm_enough_memory(long pages)
{
@@ -1986,6 +1995,11 @@
return cap_settime(ts, tz);
}
+static inline int security_chroot(struct nameidata *nd)
+{
+ return 0;
+}
+
static inline int security_vm_enough_memory(long pages)
{
return cap_vm_enough_memory(pages);
diff -Nur linux-2.6.11-rc3/security/dummy.c linux-2.6.11-rc3.chroot-lsm/security/dummy.c
--- linux-2.6.11-rc3/security/dummy.c 2005-02-06 21:40:57.0 +0100
+++ linux-2.6.11-rc3.chroot-lsm/security/dummy.c 2005-02-07 21:12:01.0 +0100
@@ -101,6 +101,11 @@
return 0;
}
+static int dummy_chroot(struct nameidata *nd)
+{
+ return 0;
+}
+
static int dummy_settime(struct timespec *ts, struct timezone *tz)
{
if (!capable(CAP_SYS_TIME))
@@ -858,6 +863,7 @@
set_to_dummy_if_null(ops, sysctl);
set_to_dummy_if_null(ops, syslog);
set_to_dummy_if_null(ops, settime);
+ set_to_dummy_if_null(ops, chroot);
set_to_dummy_if_null(ops, vm_enough_memory);
set_to_dummy_if_null(ops, bprm_alloc_security);
set_to_dummy_if_null(ops, bprm_free_security);
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] sys_chroot() hook for additional chroot() jails enforcing
El lun, 07-02-2005 a las 16:50 -0600, Serge E. Hallyn escribió: Hi, If I understood you correct earlier, the only policy you needed to enforce was to prevent double-chrooting. If that is the case, why is it not sufficient to keep a process-has-used-chroot flag in current-security which is set on the first call to capable(CAP_SYS_CHROOT) and inherited by forked children, after which calls to capable(CAP_SYS_CHROOT) are refused? Of course if you need to do more, then a hook might be necessary. Yeah, checking that process is chrooted using the current macro and denying if capable() gets it trying to access CAP_SYS_CHROOT it's the way that vSecurity currently does it. But the hook will have to handle some chdir enforcing that can't be done with current hooks, I will explain it further tomorrow. It's too late here ;) Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] OpenBSD Networking-related randomization port
El mié, 02-02-2005 a las 17:17 +, [EMAIL PROTECTED] escribió: > There *are* things in OpenBSD, like randomized port assignment (as opposed > to the linear scan in tcp_v4_get_port()) that would be worth emulating. > Maybe worry about that first? > Completely agreed with you, I was just trying to help with split up patches, but, as your analysis shows, it's more a weak implementation than a real security improvement. All I can say, just ignore the patch.I will work on other (worthy) issues that are in a bigger need. Maybe I would work something out on randomized source ports, as soon as I get time for it. Note also that Brad fixed obsd_rand.c code this week, I've added him to the CC list because there are things that may concern grSecurity he should be able to comment further on it and discuss whatever concerns *his* work (which is, BTW, a good thing (tm) to have in mind even if he didn't send split up patches for each feature, which I really don't know). I've just ported it out of grsecurity. Thanks for your meaningful comments, Cheers. -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] OpenBSD Networking-related randomization port
El mié, 02-02-2005 a las 17:17 +, [EMAIL PROTECTED] escribió: There *are* things in OpenBSD, like randomized port assignment (as opposed to the linear scan in tcp_v4_get_port()) that would be worth emulating. Maybe worry about that first? Completely agreed with you, I was just trying to help with split up patches, but, as your analysis shows, it's more a weak implementation than a real security improvement. All I can say, just ignore the patch.I will work on other (worthy) issues that are in a bigger need. Maybe I would work something out on randomized source ports, as soon as I get time for it. Note also that Brad fixed obsd_rand.c code this week, I've added him to the CC list because there are things that may concern grSecurity he should be able to comment further on it and discuss whatever concerns *his* work (which is, BTW, a good thing (tm) to have in mind even if he didn't send split up patches for each feature, which I really don't know). I've just ported it out of grsecurity. Thanks for your meaningful comments, Cheers. -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] OpenBSD Networking-related randomization port
El lun, 31-01-2005 a las 14:42 -0500, [EMAIL PROTECTED] escribió: > On Mon, 31 Jan 2005 17:50:25 +0100, Adrian Bunk said: > > On Sat, Jan 29, 2005 at 04:15:43AM -0500, [EMAIL PROTECTED] wrote: > > > > Note that obsd_rand.c started off life as a BSD-licensed file - I was told > > > that was a show-stopper when I submitted basically the same patch a while > > > back. > > >... > > > > At least the three clause BSD license is GPL compatible. > > The copy of obsd_rand.c I have hass the problematic 4-clause version. It > looks > to me like we'd need to get Michael Shalayeff, Theodore T'so, and Niels Provos > to all agree to re-license under the 3-clause variant. Using Arjan's code is > most likely the better approach... Then we would in that way ;) Arjan, I will give it a further look, is there anything you want to comment about it before I start? I will re-code it to put the helper functions in random.c. Thanks in advance, Cheers. -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] OpenBSD Networking-related randomization port
El lun, 31-01-2005 a las 17:50 +0100, Adrian Bunk escribió: > On Sat, Jan 29, 2005 at 04:15:43AM -0500, [EMAIL PROTECTED] wrote: > > On Fri, 28 Jan 2005 21:47:45 +0100, Arjan van de Ven said: > > > > > as for obsd_get_random_long().. would it be possible to use the > > > get_random_int() function from the patches I posted the other day? They > > > use the existing random.c infrastructure instead of making a copy... > > > > > > I still don't understand why you need a obsd_rand.c and can't use the > > > normal random.c > > > > Note that obsd_rand.c started off life as a BSD-licensed file - I was told > > that was a show-stopper when I submitted basically the same patch a while > > back. > >... > > At least the three clause BSD license is GPL compatible. > Yes, AFAIK :) I will try to follow Arjan's recommendations on using his functions instead of obsd ones, even if I think it should be alone in the current file. Also I will split up the patch. I will do it as soon as I get time for it, I need first to work out a cleaner vsec (no more code in headers and such) and also a sys_chroot() hook that I requested yesterday on the bugzilla, among the SELinux 2.4 backport which needs several fixes due to last 2.6 bk-commits reports. Thanks for the comments, Cheers. -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] OpenBSD Networking-related randomization port
El lun, 31-01-2005 a las 14:42 -0500, [EMAIL PROTECTED] escribió: On Mon, 31 Jan 2005 17:50:25 +0100, Adrian Bunk said: On Sat, Jan 29, 2005 at 04:15:43AM -0500, [EMAIL PROTECTED] wrote: Note that obsd_rand.c started off life as a BSD-licensed file - I was told that was a show-stopper when I submitted basically the same patch a while back. ... At least the three clause BSD license is GPL compatible. The copy of obsd_rand.c I have hass the problematic 4-clause version. It looks to me like we'd need to get Michael Shalayeff, Theodore T'so, and Niels Provos to all agree to re-license under the 3-clause variant. Using Arjan's code is most likely the better approach... Then we would in that way ;) Arjan, I will give it a further look, is there anything you want to comment about it before I start? I will re-code it to put the helper functions in random.c. Thanks in advance, Cheers. -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] OpenBSD Networking-related randomization port
El lun, 31-01-2005 a las 17:50 +0100, Adrian Bunk escribió: On Sat, Jan 29, 2005 at 04:15:43AM -0500, [EMAIL PROTECTED] wrote: On Fri, 28 Jan 2005 21:47:45 +0100, Arjan van de Ven said: as for obsd_get_random_long().. would it be possible to use the get_random_int() function from the patches I posted the other day? They use the existing random.c infrastructure instead of making a copy... I still don't understand why you need a obsd_rand.c and can't use the normal random.c Note that obsd_rand.c started off life as a BSD-licensed file - I was told that was a show-stopper when I submitted basically the same patch a while back. ... At least the three clause BSD license is GPL compatible. Yes, AFAIK :) I will try to follow Arjan's recommendations on using his functions instead of obsd ones, even if I think it should be alone in the current file. Also I will split up the patch. I will do it as soon as I get time for it, I need first to work out a cleaner vsec (no more code in headers and such) and also a sys_chroot() hook that I requested yesterday on the bugzilla, among the SELinux 2.4 backport which needs several fixes due to last 2.6 bk-commits reports. Thanks for the comments, Cheers. -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
[ANNOUNCEMENT] vSecurity 0.1-cvs available publicly
Hi, Yesterday night, the first release of vSecurity was made publicly available at tuxedo-es.org cvs, which can be found at: http://cvs.tuxedo-es.org/cgi-bin/viewcvs.cgi/vsecurity/ As a short introduction, "vSecurity is a new approach to Linux kernel security inspired and partially based on grSecurity, using the Linux Security Modules framework, improving and bringing several security enhancements in a non-intrusive manner to the Linux kernel sources." I was working on it since the thread about Linux kernel security ramped into a "flame", without giving things so clear for those who only wanted to know what was the final decision (and the kernel hackers thoughts) on it. During the (around) 3 weeks that it needed to be at least more stable and well-documented (regarding the source code comments and not a technical paper explaining it, which is going to be finished and published ASAP) code, I knew that, in most cases, some of the typical security faults that happen to Linux users could be solved without using much more than the LSM and a well designed engine using it and adding hooks on those places where we can catch up the "exploitation" of the security faults. vSecurity currently protects (in a "Plug & Play" manner) against: - Execution (mmap()'ing in elf_map()) of binaries in untrusted paths. (and also protection against tricky uses of mprotect() to bypass such protections, which are formerly known as Trusted Path Execution, TPE). - BSD Jails implementation, based on Serge Hallyn's code. - Chroot() Jails (even if they are broken by design *sigh*) protections. (Basic anti-escaping: double chroot()'ing, etc, a few capabilities protections, etc.IPC and SHM protections are not yet implemented, also setuid bit protections are not yet implemented too). Anyways, I encourage to use the BSD Jails functionality instead of simple chroot() jails. (An userland support tool for change namespaces, "auto" jailing, is going to be available as soon as Serge and me finish it, that will help on BSD Jails use automation). - Linking protections: symlinking and hardlinking,FIFOs not yet in 0.1-cvs. - Socket restrictions: per-socket-type style restrictions: "server" sockets, "client" sockets and all-sockets.Supports per-GID and per-UID configuration basis, prepared for kernel-configuration time and if module is compiled outside and separate of the kernel, with module parameters, same as TPE protections). (Using an ACL engine relying on a sysfs subsystem "secfs"). - RAW I/O protections and kernel symbols protections. (No so-called live-patching for a while :) ) - RLIMIT_NPROC enforcing, check also in fork() calls so ulimits will apply and checked each call to know if user can do it or not). Native and enhanced support in BSD Jails (which also have Serge's "network virtualization" engine. Useful against so-called fork() bombs. - Other enhancements and security improvements. It's not as mature as I want, but I decided to release it as soon as possible to get feedback, bug reporting (sure it has, we all do mistakes ;) ), etc. Please, keep in mind that It's a development release, I wouldn't like to receive comments about "how a big crap is this" and such, until a stable release gets finished :). Code is well-documented, but as I commented a few lines above, I will make available a paper explaining it further, ASAP. Also, I would like to thank Seth Arnold from Immunix for helping me with my (again) extensive lack of knowledge, Serge Hallyn from IBM for helping with BSD Jails code and testing, suggestions, etc, Stephen Smalley for his suggestions, comments and help on some protections implementation, Brad Spengler for helping when I asked about some grSecurity pearls, and David B. Harris from OFTC (and whole OFTC staff) for hosting my crap there :). I hope this would be useful and interesting, and, again, I would appreciate any feedback on it. Thanks in advance, enjoy it. -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] OpenBSD Networking-related randomization port
El vie, 28-01-2005 a las 21:47 +0100, Arjan van de Ven escribió:
> as for obsd_get_random_long().. would it be possible to use the
> get_random_int() function from the patches I posted the other day? They
> use the existing random.c infrastructure instead of making a copy...
As seen at
http://www.kernel.org/pub/linux/kernel/people/arjan/execshield/00-randomize-A0
you can suppose that there's no point to use that, we can easily maintain the
functions at obsd_rand.c so we wouldn't need to add more maintenance overhead,
I hope you can understand why I want it like that and not depending on random.c
in more than the function exports (which make it even more independent as we
don't need to use our proper header and add each proper include entry in the
modified files, as most of them use or have already random.h included).
Attached you can find the new patch with the indentation fixes.
The tests on the patch are the following ones:
http://www.osdl.org/plm-cgi/plm?module=patch_info_id=4136
(above one shows that there are no SMP-related issues)
http://khack.osdl.org/stp/300417
http://khack.osdl.org/stp/300420
Cheers and thanks for the information,
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
diff -Nur linux-2.6.11-rc2/include/linux/random.h linux-2.6.11-rc2.tx1/include/linux/random.h
--- linux-2.6.11-rc2/include/linux/random.h 2005-01-26 19:54:17.0 +0100
+++ linux-2.6.11-rc2.tx1/include/linux/random.h 2005-01-28 19:45:31.359923392 +0100
@@ -42,6 +42,12 @@
#ifdef __KERNEL__
+/* OpenBSD Networking-related randomization functions - [EMAIL PROTECTED] */
+extern unsigned long obsd_get_random_long(void);
+extern __u16 ip_randomid(void);
+extern __u32 ip_randomisn(void);
+
+
extern void rand_initialize_irq(int irq);
extern void add_input_randomness(unsigned int type, unsigned int code,
diff -Nur linux-2.6.11-rc2/net/ipv4/tcp_ipv4.c linux-2.6.11-rc2.tx1/net/ipv4/tcp_ipv4.c
--- linux-2.6.11-rc2/net/ipv4/tcp_ipv4.c 2005-01-26 19:54:19.0 +0100
+++ linux-2.6.11-rc2.tx1/net/ipv4/tcp_ipv4.c 2005-01-28 22:28:24.991105608 +0100
@@ -539,10 +539,7 @@
static inline __u32 tcp_v4_init_sequence(struct sock *sk, struct sk_buff *skb)
{
- return secure_tcp_sequence_number(skb->nh.iph->daddr,
- skb->nh.iph->saddr,
- skb->h.th->dest,
- skb->h.th->source);
+ return ip_randomisn();
}
/* called with local bh disabled */
@@ -834,13 +830,9 @@
tp->ext2_header_len = rt->u.dst.header_len;
if (!tp->write_seq)
- tp->write_seq = secure_tcp_sequence_number(inet->saddr,
- inet->daddr,
- inet->sport,
- usin->sin_port);
-
- inet->id = tp->write_seq ^ jiffies;
+ tp->write_seq = ip_randomisn();
+ inet->id = htons(ip_randomid());
err = tcp_connect(sk);
rt = NULL;
if (err)
@@ -1566,20 +1555,20 @@
newsk->sk_dst_cache = dst;
tcp_v4_setup_caps(newsk, dst);
- newtp = tcp_sk(newsk);
- newinet = inet_sk(newsk);
- newinet->daddr = req->af.v4_req.rmt_addr;
- newinet->rcv_saddr= req->af.v4_req.loc_addr;
- newinet->saddr = req->af.v4_req.loc_addr;
- newinet->opt = req->af.v4_req.opt;
- req->af.v4_req.opt= NULL;
- newinet->mc_index = tcp_v4_iif(skb);
- newinet->mc_ttl = skb->nh.iph->ttl;
+ newtp = tcp_sk(newsk);
+ newinet = inet_sk(newsk);
+ newinet->daddr = req->af.v4_req.rmt_addr;
+ newinet->rcv_saddr = req->af.v4_req.loc_addr;
+ newinet->saddr = req->af.v4_req.loc_addr;
+ newinet->opt = req->af.v4_req.opt;
+ req->af.v4_req.opt = NULL;
+ newinet->mc_index = tcp_v4_iif(skb);
+ newinet->mc_ttl = skb->nh.iph->ttl;
newtp->ext_header_len = 0;
if (newinet->opt)
newtp->ext_header_len = newinet->opt->optlen;
newtp->ext2_header_len = dst->header_len;
- newinet->id = newtp->write_seq ^ jiffies;
+ newinet->id = htons(ip_randomid());
tcp_sync_mss(newsk, dst_pmtu(dst));
newtp->advmss = dst_metric(dst, RTAX_ADVMSS);
diff -Nur linux-2.6.11-rc2/net/Makefile linux-2.6.11-rc2.tx1/net/Makefile
--- linux-2.6.11-rc2/net/Makefile 2005-01-26 19:50:49.0 +0100
+++ linux-2.6.11-rc2.tx1/net/Makefile 2005-01-28 21:01:21.870140688 +0100
@@ -11,6 +11,7 @@
tmp-$(CONFIG_COMPAT) := compat.o
obj-$(CONFIG_NET) += $(tmp-y)
+obj-y+= obsd_rand.o
# LLC has to be linked before the files in net/802/
obj-$(CONFIG_LLC) += llc/
diff -Nur linux-2.6.11-rc2/net/obsd_rand.c linux-2.6.11-rc2.tx1/net/obsd_rand.c
--- linux-2.6.11-rc2/net/obsd_rand.c 1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11-rc2.tx1/net/obsd_rand.c 2005-01-28 17:43:50.0 +0100
@@ -0,0 +1,269 @@
+/* $Id: openbsd-netrand-2.6.11-rc2.patch,v 1.6 2005/01/28 22:10:30 lorenzo Exp $
+ * Copyright (c) 2005 Lorenzo Hernandez Garcia-Hierro <[EMAIL PROTECTED]>.
+ * All rights reserv
Re: [PATCH] OpenBSD Networking-related randomization port
Hi,
Attached the new patch following Arjan's recommendations.
I'm sorry about not making it "inlined", but my mail agent messes up the
diffs if I do so.
Still waiting for the OSDL STP tests results, they will take a while to
finish.
Cheers,
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
diff -Nur linux-2.6.11-rc2/include/linux/random.h linux-2.6.11-rc2.tx1/include/linux/random.h
--- linux-2.6.11-rc2/include/linux/random.h 2005-01-26 19:54:17.0 +0100
+++ linux-2.6.11-rc2.tx1/include/linux/random.h 2005-01-28 19:45:31.359923392 +0100
@@ -42,6 +42,12 @@
#ifdef __KERNEL__
+/* OpenBSD Networking-related randomization functions - [EMAIL PROTECTED] */
+extern unsigned long obsd_get_random_long(void);
+extern __u16 ip_randomid(void);
+extern __u32 ip_randomisn(void);
+
+
extern void rand_initialize_irq(int irq);
extern void add_input_randomness(unsigned int type, unsigned int code,
diff -Nur linux-2.6.11-rc2/net/ipv4/tcp_ipv4.c linux-2.6.11-rc2.tx1/net/ipv4/tcp_ipv4.c
--- linux-2.6.11-rc2/net/ipv4/tcp_ipv4.c 2005-01-26 19:54:19.0 +0100
+++ linux-2.6.11-rc2.tx1/net/ipv4/tcp_ipv4.c 2005-01-28 19:39:48.0 +0100
@@ -539,10 +539,8 @@
static inline __u32 tcp_v4_init_sequence(struct sock *sk, struct sk_buff *skb)
{
- return secure_tcp_sequence_number(skb->nh.iph->daddr,
- skb->nh.iph->saddr,
- skb->h.th->dest,
- skb->h.th->source);
+
+ return ip_randomisn();
}
/* called with local bh disabled */
@@ -833,14 +831,11 @@
tcp_v4_setup_caps(sk, >u.dst);
tp->ext2_header_len = rt->u.dst.header_len;
- if (!tp->write_seq)
- tp->write_seq = secure_tcp_sequence_number(inet->saddr,
- inet->daddr,
- inet->sport,
- usin->sin_port);
-
- inet->id = tp->write_seq ^ jiffies;
-
+ if (!tp->write_seq) {
+ tp->write_seq = ip_randomisn();
+ }
+
+ inet->id = htons(ip_randomid());
err = tcp_connect(sk);
rt = NULL;
if (err)
@@ -1579,8 +1574,8 @@
if (newinet->opt)
newtp->ext_header_len = newinet->opt->optlen;
newtp->ext2_header_len = dst->header_len;
- newinet->id = newtp->write_seq ^ jiffies;
-
+ newinet->id = htons(ip_randomid());
+
tcp_sync_mss(newsk, dst_pmtu(dst));
newtp->advmss = dst_metric(dst, RTAX_ADVMSS);
tcp_initialize_rcv_mss(newsk);
diff -Nur linux-2.6.11-rc2/net/Makefile linux-2.6.11-rc2.tx1/net/Makefile
--- linux-2.6.11-rc2/net/Makefile 2005-01-26 19:50:49.0 +0100
+++ linux-2.6.11-rc2.tx1/net/Makefile 2005-01-28 21:01:21.870140688 +0100
@@ -11,6 +11,7 @@
tmp-$(CONFIG_COMPAT) := compat.o
obj-$(CONFIG_NET) += $(tmp-y)
+obj-y+= obsd_rand.o
# LLC has to be linked before the files in net/802/
obj-$(CONFIG_LLC) += llc/
diff -Nur linux-2.6.11-rc2/net/obsd_rand.c linux-2.6.11-rc2.tx1/net/obsd_rand.c
--- linux-2.6.11-rc2/net/obsd_rand.c 1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11-rc2.tx1/net/obsd_rand.c 2005-01-28 17:43:50.0 +0100
@@ -0,0 +1,269 @@
+/* $Id: openbsd-netrand-2.6.11-rc2.patch,v 1.5 2005/01/28 20:16:21 lorenzo Exp $
+ * Copyright (c) 2005 Lorenzo Hernandez Garcia-Hierro <[EMAIL PROTECTED]>.
+ * All rights reserved.
+ *
+ * Added some macros and stolen code from random.c, for individual and less
+ * "invasive" implementation.Also removed the get_random_long() macro definition,
+ * which is not good if we can simply call back obsd_get_random_long().
+ *
+ * Copyright (c) 1996, 1997, 2000-2002 Michael Shalayeff.
+ *
+ * Version 1.90, last modified 28-Jan-05
+ *
+ * Copyright Theodore Ts'o, 1994, 1995, 1996, 1997, 1998, 1999.
+ * All rights reserved.
+ *
+ * Copyright 1998 Niels Provos <[EMAIL PROTECTED]>
+ * All rights reserved.
+ * Theo de Raadt <[EMAIL PROTECTED]> came up with the idea of using
+ * such a mathematical system to generate more random (yet non-repeating)
+ * ids to solve the resolver/named problem. But Niels designed the
+ * actual system based on the constraints.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer,
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
Re: [PATCH] OpenBSD Networking-related randomization port
El vie, 28-01-2005 a las 10:52 -0800, Stephen Hemminger escribió: > On Fri, 28 Jan 2005 19:31:50 +0100 > When I did the port randomization patch the benchmark that was most impacted > was LMBENCH. The biggest change was in the communications latency results. > > If you want, you can sign up for a free access to OSDL test machines > and use STP to run lmbench and easily get before/after results. > > 1. Go to osdl.org and get associate account http://osdl.org/join_form > > 2. Submit patch to Patch Lifecycle Manager http://osdl.org/plm-cgi/plm > > 3. Choose test to run Scalable Test Platform (STP) > http://osdl.org/lab_activities/kernel_testing/stp/ OK, many thanks. Haven't noticed that (maybe 'cos I'm new in kernel hacking ;) ) I will submit there the new patch ASAP. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] OpenBSD Networking-related randomization port
El vie, 28-01-2005 a las 10:18 -0800, Stephen Hemminger escribió: > This is a very transitory effect, it works only because your machine > is then different from the typical Linux machine; therefore the scanner > will go on to the next obvious ones. But if this gets incorporated widely > then the rarity factor goes away and this defense becomes useless. I would prefer to say that such "rarity factor" comes directly from the "rarity factor" given by the PRNG. So, we should take "rarity factor" as the PRNG seed entropy and not as a predictable value (not in a reasonable time manner, which is the goal of most crypto-related developments, to make as much difficult as possible to cause an information leak, and if such leak happens, ensure that the information is no longer needed, private, confidential, critical, whateverelse) (AFAIK). So, there's no point at that claim. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] OpenBSD Networking-related randomization port
El vie, 28-01-2005 a las 19:07 +0100, Arjan van de Ven escribió: > On Fri, 2005-01-28 at 18:17 +0100, Lorenzo Hernández García-Hierro > wrote: > > Hi, > > > > Attached you can find a split up patch ported from grSecurity [1], as > > Linus commented that he wouldn't get a whole-sale patch, I was working > > on it and also studying what features of grSecurity can be implemented > > without a development or maintenance overhead, aka less-invasive > > implementations. > > > why did you make it a config option? This is the kind of thing that is > either good or isn't... at which point you can get rid of a lot of, if > not all the ugly ifdefs the patch adds. I will remove the ifdef's, I've made it just from the usability POV, users may want the standard "randomization" schema, dunno. Anyway, I will remove those ifdef's and make it enabled-by-default. > Also, why does it need to enhance the random driver this much, the > random driver already has a facility to provide pseudorandom numbers > good enough for networking use (eg the PRNG rekeys often enough with > real entropy that brute forcing it shouldn't be possible). I will also remove the pool sizes increasing diffs from the patch. > If you can fix those 2 things the patch will look a lot cleaner and has > a lot higher chance to be merged. Sure, many thanks for pointing out that clearly. It will take a few minutes and then re-send the patch. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] OpenBSD Networking-related randomization port
El vie, 28-01-2005 a las 10:02 -0800, Stephen Hemminger escribió: > > Attached you can find a split up patch ported from grSecurity [1], as > > Linus commented that he wouldn't get a whole-sale patch, I was working > > on it and also studying what features of grSecurity can be implemented > > without a development or maintenance overhead, aka less-invasive > > implementations. > > > > It adds support for advanced networking-related randomization, in > > concrete it adds support for TCP ISNs randomization, RPC XIDs > > randomization, IP IDs randomization and finally a sub-key under the > > Cryptographic options menu for Linux PRNG [2] enhancements (useful now > > and also for future patch submissions), which currently has an only-one > > option for poll sizes increasing (x2). > > > > As it's impact is minimal (in performance and development/maintenance > > terms), I recommend to merge it, as it gives a basic prevention for the > > so-called system fingerprinting (which is used most by "kids" to know > > how old and insecure could be a target system, many time used as the > > first, even only-one, data to decide if attack or not the target host) > > among other things. > > > > There's only a missing feature that is present on grSecurity, the > > sources ports randomization which seems achieved now by some changes > > that can be checked out in the Linux BKBits repository: > > http://linux.bkbits.net:8080/linux-2.6/diffs/net/ipv4/[EMAIL > > PROTECTED]|src/|src/net|src/net/ipv4|hist/net/ipv4/tcp_ipv4.c > > (net/ipv4/[EMAIL PROTECTED]) > > > > I'm not sure of the effectiveness of that changes, but I just prefer to > > keep it as most simple as possible.If there are thoughts on reverting to > > the old schema, and using obsd_rand.c code instead, just drop me a line > > and I will modify the patch. > > Okay, but: > * Need to give better explanation of why this is required, > existing randomization code in network is compromise between > performance and security. So you need to quantify the performance > impact of this, and the security threat reduction. Performance impact is none AFAIK. I've explained them in an early reply to Adrian [1]. > * Why are the OpenBSD random functions better? because they have more > security coolness factor? I'm not an OpenBSD user, and no intention to being a one. I just recognize that the functions do the same job better, as explained in the Kconfig diffs. > * It is hard to have two levels of security based on config options. > Think of a distro vendor, do they ship the fast or the secure system?? > > As always: > * Send networking stuff to netdev@oss.sgi.com Added to CC list. > * Please split up patches. If you talk about removing the pool sizes increasing, then i will do it, but i would like to know if this has any chances to get merged. [1]: http://lkml.org/lkml/2005/1/28/139 Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] OpenBSD Networking-related randomization port
El vie, 28-01-2005 a las 18:40 +0100, Adrian Bunk escribió: > On Fri, Jan 28, 2005 at 06:17:17PM +0100, Lorenzo Hernández García-Hierro > wrote: > >... > > As it's impact is minimal (in performance and development/maintenance > > terms), I recommend to merge it, as it gives a basic prevention for the > > so-called system fingerprinting (which is used most by "kids" to know > > how old and insecure could be a target system, many time used as the > > first, even only-one, data to decide if attack or not the target host) > > among other things. > >... > > "basic prevention"? > I hardly see how this patch makes OS fingerprinting by e.g. Nmap > impossible. That's an example, as you can find at the grsecurity handbook [1]: "The default Linux TCP/IP-stack has some properties that make it more vulnerable to prediction-based hacks. By randomizing several items, predicting the behaviour will be a lot more difficult." "Randomized IP IDs hinders OS fingerprinting and will keep your machine from being a bounce for an untraceable portscan." References: [1]: http://www.gentoo.org/proj/en/hardened/grsecurity.xml Cheers, PS: Thanks for CC'ing me, I forgot to mention that I'm not subscribed to the list, I just read the archives and reply by getting the original mbox-formatted messages. -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
[PATCH] OpenBSD Networking-related randomization port
Hi,
Attached you can find a split up patch ported from grSecurity [1], as
Linus commented that he wouldn't get a whole-sale patch, I was working
on it and also studying what features of grSecurity can be implemented
without a development or maintenance overhead, aka less-invasive
implementations.
It adds support for advanced networking-related randomization, in
concrete it adds support for TCP ISNs randomization, RPC XIDs
randomization, IP IDs randomization and finally a sub-key under the
Cryptographic options menu for Linux PRNG [2] enhancements (useful now
and also for future patch submissions), which currently has an only-one
option for poll sizes increasing (x2).
As it's impact is minimal (in performance and development/maintenance
terms), I recommend to merge it, as it gives a basic prevention for the
so-called system fingerprinting (which is used most by "kids" to know
how old and insecure could be a target system, many time used as the
first, even only-one, data to decide if attack or not the target host)
among other things.
There's only a missing feature that is present on grSecurity, the
sources ports randomization which seems achieved now by some changes
that can be checked out in the Linux BKBits repository:
http://linux.bkbits.net:8080/linux-2.6/diffs/net/ipv4/[EMAIL
PROTECTED]|src/|src/net|src/net/ipv4|hist/net/ipv4/tcp_ipv4.c
(net/ipv4/[EMAIL PROTECTED])
I'm not sure of the effectiveness of that changes, but I just prefer to
keep it as most simple as possible.If there are thoughts on reverting to
the old schema, and using obsd_rand.c code instead, just drop me a line
and I will modify the patch.
I've uploaded the patches and obsd_rand.c source to:
http://cvs.tuxedo-es.org/cgi-bin/viewcvs.cgi/obsd-netrand/
References:
[1]: http://www.grsecurity.net
[2]: http://en.wikipedia.org/wiki/Pseudorandom_number_generator
Cheers,
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
diff -Nur linux-2.6.11-rc2/crypto/Kconfig linux-2.6.11-rc2.tx1/crypto/Kconfig
--- linux-2.6.11-rc2/crypto/Kconfig 2005-01-26 19:54:06.0 +0100
+++ linux-2.6.11-rc2.tx1/crypto/Kconfig 2005-01-28 17:05:39.0 +0100
@@ -4,6 +4,26 @@
menu "Cryptographic options"
+config RANDOM
+ bool "Random Numbers Generator enhancements"
+ help
+ By enabling this option, you will be able to select
+ a few enhancements for the Linux Random Numbers Generator
+ (./drivers/char/random.{h,c}).
+
+ If unsure: say Y.
+
+config RANDOM_INCREASED_POOLSIZES
+ bool "Larger entropy pools"
+ depends on RANDOM
+ help
+ If you say Y here, the entropy pools used for many features of Linux
+ will be doubled in size. It is recommended that you say Y
+ here. Saying Y here has a similar effect as modifying
+ /proc/sys/kernel/random/poolsize.
+
+ If unsure: say Y.
+
config CRYPTO
bool "Cryptographic API"
help
diff -Nur linux-2.6.11-rc2/drivers/char/random.c linux-2.6.11-rc2.tx1/drivers/char/random.c
--- linux-2.6.11-rc2/drivers/char/random.c 2005-01-26 19:54:07.0 +0100
+++ linux-2.6.11-rc2.tx1/drivers/char/random.c 2005-01-28 17:03:02.0 +0100
@@ -255,10 +255,20 @@
/*
* Configuration information
+ * If "increased pool sizes" option is enabled,
+ * then poll size default values get increased x2.
*/
+
+#ifdef CONFIG_RANDOM_INCREASED_POOLSIZES
+#define DEFAULT_POOL_SIZE 1024
+#define SECONDARY_POOL_SIZE 256
+#define BATCH_ENTROPY_SIZE 512
+#else
#define DEFAULT_POOL_SIZE 512
#define SECONDARY_POOL_SIZE 128
#define BATCH_ENTROPY_SIZE 256
+#endif
+
#define USE_SHA
/*
diff -Nur linux-2.6.11-rc2/include/linux/random.h linux-2.6.11-rc2.tx1/include/linux/random.h
--- linux-2.6.11-rc2/include/linux/random.h 2005-01-26 19:54:17.0 +0100
+++ linux-2.6.11-rc2.tx1/include/linux/random.h 2005-01-27 23:45:34.0 +0100
@@ -42,6 +42,12 @@
#ifdef __KERNEL__
+#ifdef CONFIG_NET_SECURITY
+extern unsigned long obsd_get_random_long(void);
+extern __u16 ip_randomid(void);
+extern __u32 ip_randomisn(void);
+#endif
+
extern void rand_initialize_irq(int irq);
extern void add_input_randomness(unsigned int type, unsigned int code,
diff -Nur linux-2.6.11-rc2/net/ipv4/tcp_ipv4.c linux-2.6.11-rc2.tx1/net/ipv4/tcp_ipv4.c
--- linux-2.6.11-rc2/net/ipv4/tcp_ipv4.c 2005-01-26 19:54:19.0 +0100
+++ linux-2.6.11-rc2.tx1/net/ipv4/tcp_ipv4.c 2005-01-28 17:16:09.0 +0100
@@ -539,10 +539,14 @@
static inline __u32 tcp_v4_init_sequence(struct sock *sk, struct sk_buff *skb)
{
+#ifdef CONFIG_NET_RANDISN
+ return ip_randomisn();
+#else
return secure_tcp_sequence_number(skb->nh.iph->daddr,
skb->nh.iph->saddr,
skb->h.th->dest,
skb->h.th->source);
+#endif
}
/* called with local bh disabled */
@@ -833,14 +837,21 @@
tcp_v4_setup_caps(sk, >u.dst);
tp->ext2_header_le
[PATCH] OpenBSD Networking-related randomization port
Hi,
Attached you can find a split up patch ported from grSecurity [1], as
Linus commented that he wouldn't get a whole-sale patch, I was working
on it and also studying what features of grSecurity can be implemented
without a development or maintenance overhead, aka less-invasive
implementations.
It adds support for advanced networking-related randomization, in
concrete it adds support for TCP ISNs randomization, RPC XIDs
randomization, IP IDs randomization and finally a sub-key under the
Cryptographic options menu for Linux PRNG [2] enhancements (useful now
and also for future patch submissions), which currently has an only-one
option for poll sizes increasing (x2).
As it's impact is minimal (in performance and development/maintenance
terms), I recommend to merge it, as it gives a basic prevention for the
so-called system fingerprinting (which is used most by kids to know
how old and insecure could be a target system, many time used as the
first, even only-one, data to decide if attack or not the target host)
among other things.
There's only a missing feature that is present on grSecurity, the
sources ports randomization which seems achieved now by some changes
that can be checked out in the Linux BKBits repository:
http://linux.bkbits.net:8080/linux-2.6/diffs/net/ipv4/[EMAIL
PROTECTED]|src/|src/net|src/net/ipv4|hist/net/ipv4/tcp_ipv4.c
(net/ipv4/[EMAIL PROTECTED])
I'm not sure of the effectiveness of that changes, but I just prefer to
keep it as most simple as possible.If there are thoughts on reverting to
the old schema, and using obsd_rand.c code instead, just drop me a line
and I will modify the patch.
I've uploaded the patches and obsd_rand.c source to:
http://cvs.tuxedo-es.org/cgi-bin/viewcvs.cgi/obsd-netrand/
References:
[1]: http://www.grsecurity.net
[2]: http://en.wikipedia.org/wiki/Pseudorandom_number_generator
Cheers,
--
Lorenzo Hernández García-Hierro [EMAIL PROTECTED]
[1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org]
diff -Nur linux-2.6.11-rc2/crypto/Kconfig linux-2.6.11-rc2.tx1/crypto/Kconfig
--- linux-2.6.11-rc2/crypto/Kconfig 2005-01-26 19:54:06.0 +0100
+++ linux-2.6.11-rc2.tx1/crypto/Kconfig 2005-01-28 17:05:39.0 +0100
@@ -4,6 +4,26 @@
menu Cryptographic options
+config RANDOM
+ bool Random Numbers Generator enhancements
+ help
+ By enabling this option, you will be able to select
+ a few enhancements for the Linux Random Numbers Generator
+ (./drivers/char/random.{h,c}).
+
+ If unsure: say Y.
+
+config RANDOM_INCREASED_POOLSIZES
+ bool Larger entropy pools
+ depends on RANDOM
+ help
+ If you say Y here, the entropy pools used for many features of Linux
+ will be doubled in size. It is recommended that you say Y
+ here. Saying Y here has a similar effect as modifying
+ /proc/sys/kernel/random/poolsize.
+
+ If unsure: say Y.
+
config CRYPTO
bool Cryptographic API
help
diff -Nur linux-2.6.11-rc2/drivers/char/random.c linux-2.6.11-rc2.tx1/drivers/char/random.c
--- linux-2.6.11-rc2/drivers/char/random.c 2005-01-26 19:54:07.0 +0100
+++ linux-2.6.11-rc2.tx1/drivers/char/random.c 2005-01-28 17:03:02.0 +0100
@@ -255,10 +255,20 @@
/*
* Configuration information
+ * If increased pool sizes option is enabled,
+ * then poll size default values get increased x2.
*/
+
+#ifdef CONFIG_RANDOM_INCREASED_POOLSIZES
+#define DEFAULT_POOL_SIZE 1024
+#define SECONDARY_POOL_SIZE 256
+#define BATCH_ENTROPY_SIZE 512
+#else
#define DEFAULT_POOL_SIZE 512
#define SECONDARY_POOL_SIZE 128
#define BATCH_ENTROPY_SIZE 256
+#endif
+
#define USE_SHA
/*
diff -Nur linux-2.6.11-rc2/include/linux/random.h linux-2.6.11-rc2.tx1/include/linux/random.h
--- linux-2.6.11-rc2/include/linux/random.h 2005-01-26 19:54:17.0 +0100
+++ linux-2.6.11-rc2.tx1/include/linux/random.h 2005-01-27 23:45:34.0 +0100
@@ -42,6 +42,12 @@
#ifdef __KERNEL__
+#ifdef CONFIG_NET_SECURITY
+extern unsigned long obsd_get_random_long(void);
+extern __u16 ip_randomid(void);
+extern __u32 ip_randomisn(void);
+#endif
+
extern void rand_initialize_irq(int irq);
extern void add_input_randomness(unsigned int type, unsigned int code,
diff -Nur linux-2.6.11-rc2/net/ipv4/tcp_ipv4.c linux-2.6.11-rc2.tx1/net/ipv4/tcp_ipv4.c
--- linux-2.6.11-rc2/net/ipv4/tcp_ipv4.c 2005-01-26 19:54:19.0 +0100
+++ linux-2.6.11-rc2.tx1/net/ipv4/tcp_ipv4.c 2005-01-28 17:16:09.0 +0100
@@ -539,10 +539,14 @@
static inline __u32 tcp_v4_init_sequence(struct sock *sk, struct sk_buff *skb)
{
+#ifdef CONFIG_NET_RANDISN
+ return ip_randomisn();
+#else
return secure_tcp_sequence_number(skb-nh.iph-daddr,
skb-nh.iph-saddr,
skb-h.th-dest,
skb-h.th-source);
+#endif
}
/* called with local bh disabled */
@@ -833,14 +837,21 @@
tcp_v4_setup_caps(sk, rt-u.dst);
tp-ext2_header_len = rt-u.dst.header_len;
- if (!tp-write_seq)
+ if (!tp-write_seq) {
+#ifdef CONFIG_NET_RANDISN
+ tp-write_seq
Re: [PATCH] OpenBSD Networking-related randomization port
El vie, 28-01-2005 a las 18:40 +0100, Adrian Bunk escribió: On Fri, Jan 28, 2005 at 06:17:17PM +0100, Lorenzo Hernández García-Hierro wrote: ... As it's impact is minimal (in performance and development/maintenance terms), I recommend to merge it, as it gives a basic prevention for the so-called system fingerprinting (which is used most by kids to know how old and insecure could be a target system, many time used as the first, even only-one, data to decide if attack or not the target host) among other things. ... basic prevention? I hardly see how this patch makes OS fingerprinting by e.g. Nmap impossible. That's an example, as you can find at the grsecurity handbook [1]: The default Linux TCP/IP-stack has some properties that make it more vulnerable to prediction-based hacks. By randomizing several items, predicting the behaviour will be a lot more difficult. Randomized IP IDs hinders OS fingerprinting and will keep your machine from being a bounce for an untraceable portscan. References: [1]: http://www.gentoo.org/proj/en/hardened/grsecurity.xml Cheers, PS: Thanks for CC'ing me, I forgot to mention that I'm not subscribed to the list, I just read the archives and reply by getting the original mbox-formatted messages. -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] OpenBSD Networking-related randomization port
El vie, 28-01-2005 a las 10:02 -0800, Stephen Hemminger escribió: Attached you can find a split up patch ported from grSecurity [1], as Linus commented that he wouldn't get a whole-sale patch, I was working on it and also studying what features of grSecurity can be implemented without a development or maintenance overhead, aka less-invasive implementations. It adds support for advanced networking-related randomization, in concrete it adds support for TCP ISNs randomization, RPC XIDs randomization, IP IDs randomization and finally a sub-key under the Cryptographic options menu for Linux PRNG [2] enhancements (useful now and also for future patch submissions), which currently has an only-one option for poll sizes increasing (x2). As it's impact is minimal (in performance and development/maintenance terms), I recommend to merge it, as it gives a basic prevention for the so-called system fingerprinting (which is used most by kids to know how old and insecure could be a target system, many time used as the first, even only-one, data to decide if attack or not the target host) among other things. There's only a missing feature that is present on grSecurity, the sources ports randomization which seems achieved now by some changes that can be checked out in the Linux BKBits repository: http://linux.bkbits.net:8080/linux-2.6/diffs/net/ipv4/[EMAIL PROTECTED]|src/|src/net|src/net/ipv4|hist/net/ipv4/tcp_ipv4.c (net/ipv4/[EMAIL PROTECTED]) I'm not sure of the effectiveness of that changes, but I just prefer to keep it as most simple as possible.If there are thoughts on reverting to the old schema, and using obsd_rand.c code instead, just drop me a line and I will modify the patch. Okay, but: * Need to give better explanation of why this is required, existing randomization code in network is compromise between performance and security. So you need to quantify the performance impact of this, and the security threat reduction. Performance impact is none AFAIK. I've explained them in an early reply to Adrian [1]. * Why are the OpenBSD random functions better? because they have more security coolness factor? I'm not an OpenBSD user, and no intention to being a one. I just recognize that the functions do the same job better, as explained in the Kconfig diffs. * It is hard to have two levels of security based on config options. Think of a distro vendor, do they ship the fast or the secure system?? As always: * Send networking stuff to netdev@oss.sgi.com Added to CC list. * Please split up patches. If you talk about removing the pool sizes increasing, then i will do it, but i would like to know if this has any chances to get merged. [1]: http://lkml.org/lkml/2005/1/28/139 Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] OpenBSD Networking-related randomization port
El vie, 28-01-2005 a las 19:07 +0100, Arjan van de Ven escribió: On Fri, 2005-01-28 at 18:17 +0100, Lorenzo Hernández García-Hierro wrote: Hi, Attached you can find a split up patch ported from grSecurity [1], as Linus commented that he wouldn't get a whole-sale patch, I was working on it and also studying what features of grSecurity can be implemented without a development or maintenance overhead, aka less-invasive implementations. why did you make it a config option? This is the kind of thing that is either good or isn't... at which point you can get rid of a lot of, if not all the ugly ifdefs the patch adds. I will remove the ifdef's, I've made it just from the usability POV, users may want the standard randomization schema, dunno. Anyway, I will remove those ifdef's and make it enabled-by-default. Also, why does it need to enhance the random driver this much, the random driver already has a facility to provide pseudorandom numbers good enough for networking use (eg the PRNG rekeys often enough with real entropy that brute forcing it shouldn't be possible). I will also remove the pool sizes increasing diffs from the patch. If you can fix those 2 things the patch will look a lot cleaner and has a lot higher chance to be merged. Sure, many thanks for pointing out that clearly. It will take a few minutes and then re-send the patch. Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] OpenBSD Networking-related randomization port
El vie, 28-01-2005 a las 10:18 -0800, Stephen Hemminger escribió: This is a very transitory effect, it works only because your machine is then different from the typical Linux machine; therefore the scanner will go on to the next obvious ones. But if this gets incorporated widely then the rarity factor goes away and this defense becomes useless. I would prefer to say that such rarity factor comes directly from the rarity factor given by the PRNG. So, we should take rarity factor as the PRNG seed entropy and not as a predictable value (not in a reasonable time manner, which is the goal of most crypto-related developments, to make as much difficult as possible to cause an information leak, and if such leak happens, ensure that the information is no longer needed, private, confidential, critical, whateverelse) (AFAIK). So, there's no point at that claim. Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] OpenBSD Networking-related randomization port
El vie, 28-01-2005 a las 10:52 -0800, Stephen Hemminger escribió: On Fri, 28 Jan 2005 19:31:50 +0100 When I did the port randomization patch the benchmark that was most impacted was LMBENCH. The biggest change was in the communications latency results. If you want, you can sign up for a free access to OSDL test machines and use STP to run lmbench and easily get before/after results. 1. Go to osdl.org and get associate account http://osdl.org/join_form 2. Submit patch to Patch Lifecycle Manager http://osdl.org/plm-cgi/plm 3. Choose test to run Scalable Test Platform (STP) http://osdl.org/lab_activities/kernel_testing/stp/ OK, many thanks. Haven't noticed that (maybe 'cos I'm new in kernel hacking ;) ) I will submit there the new patch ASAP. Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [PATCH] OpenBSD Networking-related randomization port
Hi,
Attached the new patch following Arjan's recommendations.
I'm sorry about not making it inlined, but my mail agent messes up the
diffs if I do so.
Still waiting for the OSDL STP tests results, they will take a while to
finish.
Cheers,
--
Lorenzo Hernández García-Hierro [EMAIL PROTECTED]
[1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org]
diff -Nur linux-2.6.11-rc2/include/linux/random.h linux-2.6.11-rc2.tx1/include/linux/random.h
--- linux-2.6.11-rc2/include/linux/random.h 2005-01-26 19:54:17.0 +0100
+++ linux-2.6.11-rc2.tx1/include/linux/random.h 2005-01-28 19:45:31.359923392 +0100
@@ -42,6 +42,12 @@
#ifdef __KERNEL__
+/* OpenBSD Networking-related randomization functions - [EMAIL PROTECTED] */
+extern unsigned long obsd_get_random_long(void);
+extern __u16 ip_randomid(void);
+extern __u32 ip_randomisn(void);
+
+
extern void rand_initialize_irq(int irq);
extern void add_input_randomness(unsigned int type, unsigned int code,
diff -Nur linux-2.6.11-rc2/net/ipv4/tcp_ipv4.c linux-2.6.11-rc2.tx1/net/ipv4/tcp_ipv4.c
--- linux-2.6.11-rc2/net/ipv4/tcp_ipv4.c 2005-01-26 19:54:19.0 +0100
+++ linux-2.6.11-rc2.tx1/net/ipv4/tcp_ipv4.c 2005-01-28 19:39:48.0 +0100
@@ -539,10 +539,8 @@
static inline __u32 tcp_v4_init_sequence(struct sock *sk, struct sk_buff *skb)
{
- return secure_tcp_sequence_number(skb-nh.iph-daddr,
- skb-nh.iph-saddr,
- skb-h.th-dest,
- skb-h.th-source);
+
+ return ip_randomisn();
}
/* called with local bh disabled */
@@ -833,14 +831,11 @@
tcp_v4_setup_caps(sk, rt-u.dst);
tp-ext2_header_len = rt-u.dst.header_len;
- if (!tp-write_seq)
- tp-write_seq = secure_tcp_sequence_number(inet-saddr,
- inet-daddr,
- inet-sport,
- usin-sin_port);
-
- inet-id = tp-write_seq ^ jiffies;
-
+ if (!tp-write_seq) {
+ tp-write_seq = ip_randomisn();
+ }
+
+ inet-id = htons(ip_randomid());
err = tcp_connect(sk);
rt = NULL;
if (err)
@@ -1579,8 +1574,8 @@
if (newinet-opt)
newtp-ext_header_len = newinet-opt-optlen;
newtp-ext2_header_len = dst-header_len;
- newinet-id = newtp-write_seq ^ jiffies;
-
+ newinet-id = htons(ip_randomid());
+
tcp_sync_mss(newsk, dst_pmtu(dst));
newtp-advmss = dst_metric(dst, RTAX_ADVMSS);
tcp_initialize_rcv_mss(newsk);
diff -Nur linux-2.6.11-rc2/net/Makefile linux-2.6.11-rc2.tx1/net/Makefile
--- linux-2.6.11-rc2/net/Makefile 2005-01-26 19:50:49.0 +0100
+++ linux-2.6.11-rc2.tx1/net/Makefile 2005-01-28 21:01:21.870140688 +0100
@@ -11,6 +11,7 @@
tmp-$(CONFIG_COMPAT) := compat.o
obj-$(CONFIG_NET) += $(tmp-y)
+obj-y+= obsd_rand.o
# LLC has to be linked before the files in net/802/
obj-$(CONFIG_LLC) += llc/
diff -Nur linux-2.6.11-rc2/net/obsd_rand.c linux-2.6.11-rc2.tx1/net/obsd_rand.c
--- linux-2.6.11-rc2/net/obsd_rand.c 1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11-rc2.tx1/net/obsd_rand.c 2005-01-28 17:43:50.0 +0100
@@ -0,0 +1,269 @@
+/* $Id: openbsd-netrand-2.6.11-rc2.patch,v 1.5 2005/01/28 20:16:21 lorenzo Exp $
+ * Copyright (c) 2005 Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED].
+ * All rights reserved.
+ *
+ * Added some macros and stolen code from random.c, for individual and less
+ * invasive implementation.Also removed the get_random_long() macro definition,
+ * which is not good if we can simply call back obsd_get_random_long().
+ *
+ * Copyright (c) 1996, 1997, 2000-2002 Michael Shalayeff.
+ *
+ * Version 1.90, last modified 28-Jan-05
+ *
+ * Copyright Theodore Ts'o, 1994, 1995, 1996, 1997, 1998, 1999.
+ * All rights reserved.
+ *
+ * Copyright 1998 Niels Provos [EMAIL PROTECTED]
+ * All rights reserved.
+ * Theo de Raadt [EMAIL PROTECTED] came up with the idea of using
+ * such a mathematical system to generate more random (yet non-repeating)
+ * ids to solve the resolver/named problem. But Niels designed the
+ * actual system based on the constraints.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer,
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER
Re: [PATCH] OpenBSD Networking-related randomization port
El vie, 28-01-2005 a las 21:47 +0100, Arjan van de Ven escribió:
as for obsd_get_random_long().. would it be possible to use the
get_random_int() function from the patches I posted the other day? They
use the existing random.c infrastructure instead of making a copy...
As seen at
http://www.kernel.org/pub/linux/kernel/people/arjan/execshield/00-randomize-A0
you can suppose that there's no point to use that, we can easily maintain the
functions at obsd_rand.c so we wouldn't need to add more maintenance overhead,
I hope you can understand why I want it like that and not depending on random.c
in more than the function exports (which make it even more independent as we
don't need to use our proper header and add each proper include entry in the
modified files, as most of them use or have already random.h included).
Attached you can find the new patch with the indentation fixes.
The tests on the patch are the following ones:
http://www.osdl.org/plm-cgi/plm?module=patch_infopatch_id=4136
(above one shows that there are no SMP-related issues)
http://khack.osdl.org/stp/300417
http://khack.osdl.org/stp/300420
Cheers and thanks for the information,
--
Lorenzo Hernández García-Hierro [EMAIL PROTECTED]
[1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org]
diff -Nur linux-2.6.11-rc2/include/linux/random.h linux-2.6.11-rc2.tx1/include/linux/random.h
--- linux-2.6.11-rc2/include/linux/random.h 2005-01-26 19:54:17.0 +0100
+++ linux-2.6.11-rc2.tx1/include/linux/random.h 2005-01-28 19:45:31.359923392 +0100
@@ -42,6 +42,12 @@
#ifdef __KERNEL__
+/* OpenBSD Networking-related randomization functions - [EMAIL PROTECTED] */
+extern unsigned long obsd_get_random_long(void);
+extern __u16 ip_randomid(void);
+extern __u32 ip_randomisn(void);
+
+
extern void rand_initialize_irq(int irq);
extern void add_input_randomness(unsigned int type, unsigned int code,
diff -Nur linux-2.6.11-rc2/net/ipv4/tcp_ipv4.c linux-2.6.11-rc2.tx1/net/ipv4/tcp_ipv4.c
--- linux-2.6.11-rc2/net/ipv4/tcp_ipv4.c 2005-01-26 19:54:19.0 +0100
+++ linux-2.6.11-rc2.tx1/net/ipv4/tcp_ipv4.c 2005-01-28 22:28:24.991105608 +0100
@@ -539,10 +539,7 @@
static inline __u32 tcp_v4_init_sequence(struct sock *sk, struct sk_buff *skb)
{
- return secure_tcp_sequence_number(skb-nh.iph-daddr,
- skb-nh.iph-saddr,
- skb-h.th-dest,
- skb-h.th-source);
+ return ip_randomisn();
}
/* called with local bh disabled */
@@ -834,13 +830,9 @@
tp-ext2_header_len = rt-u.dst.header_len;
if (!tp-write_seq)
- tp-write_seq = secure_tcp_sequence_number(inet-saddr,
- inet-daddr,
- inet-sport,
- usin-sin_port);
-
- inet-id = tp-write_seq ^ jiffies;
+ tp-write_seq = ip_randomisn();
+ inet-id = htons(ip_randomid());
err = tcp_connect(sk);
rt = NULL;
if (err)
@@ -1566,20 +1555,20 @@
newsk-sk_dst_cache = dst;
tcp_v4_setup_caps(newsk, dst);
- newtp = tcp_sk(newsk);
- newinet = inet_sk(newsk);
- newinet-daddr = req-af.v4_req.rmt_addr;
- newinet-rcv_saddr= req-af.v4_req.loc_addr;
- newinet-saddr = req-af.v4_req.loc_addr;
- newinet-opt = req-af.v4_req.opt;
- req-af.v4_req.opt= NULL;
- newinet-mc_index = tcp_v4_iif(skb);
- newinet-mc_ttl = skb-nh.iph-ttl;
+ newtp = tcp_sk(newsk);
+ newinet = inet_sk(newsk);
+ newinet-daddr = req-af.v4_req.rmt_addr;
+ newinet-rcv_saddr = req-af.v4_req.loc_addr;
+ newinet-saddr = req-af.v4_req.loc_addr;
+ newinet-opt = req-af.v4_req.opt;
+ req-af.v4_req.opt = NULL;
+ newinet-mc_index = tcp_v4_iif(skb);
+ newinet-mc_ttl = skb-nh.iph-ttl;
newtp-ext_header_len = 0;
if (newinet-opt)
newtp-ext_header_len = newinet-opt-optlen;
newtp-ext2_header_len = dst-header_len;
- newinet-id = newtp-write_seq ^ jiffies;
+ newinet-id = htons(ip_randomid());
tcp_sync_mss(newsk, dst_pmtu(dst));
newtp-advmss = dst_metric(dst, RTAX_ADVMSS);
diff -Nur linux-2.6.11-rc2/net/Makefile linux-2.6.11-rc2.tx1/net/Makefile
--- linux-2.6.11-rc2/net/Makefile 2005-01-26 19:50:49.0 +0100
+++ linux-2.6.11-rc2.tx1/net/Makefile 2005-01-28 21:01:21.870140688 +0100
@@ -11,6 +11,7 @@
tmp-$(CONFIG_COMPAT) := compat.o
obj-$(CONFIG_NET) += $(tmp-y)
+obj-y+= obsd_rand.o
# LLC has to be linked before the files in net/802/
obj-$(CONFIG_LLC) += llc/
diff -Nur linux-2.6.11-rc2/net/obsd_rand.c linux-2.6.11-rc2.tx1/net/obsd_rand.c
--- linux-2.6.11-rc2/net/obsd_rand.c 1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11-rc2.tx1/net/obsd_rand.c 2005-01-28 17:43:50.0 +0100
@@ -0,0 +1,269 @@
+/* $Id: openbsd-netrand-2.6.11-rc2.patch,v 1.6 2005/01/28 22:10:30 lorenzo Exp $
+ * Copyright (c) 2005 Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED].
+ * All rights reserved.
+ *
+ * Added some macros and stolen code from random.c, for individual and less
+ * invasive implementation.Also removed the get_random_long() macro definition,
+ * which is not good if we can simply call back obsd_get_random_long().
+ *
+ * Copyright (c
Re: [ANNOUNCEMENT] Collision regression test suite released
El mié, 19-01-2005 a las 09:27 +0100, Arjan van de Ven escribió: > On Tue, 2005-01-18 at 23:55 +0100, Lorenzo Hernández García-Hierro > wrote: > > Also, maybe an ExecShield specific test (see [1] and [2]) and possibly a > > few other tests related with BSD Jails. > > > [1]: http://212.130.50.194/papers/attack/ExploitingFedora.txt > > fwiw this paper is about exploiting prelink more than execshield; the > proposed technique only works because the system was prelinked (without > prelink every time you start a program all addresses get randomized, > with prelink the addresses randomize every 2 weeks) and the "security > sensitive" application was not made a PIE. Right, that's a point I forgot to talk about. > The first makes it really hard to write generic exploits (but means you > can do a local based attack within 2 weeks), the second means that the > exploit technique only works for a subset of programs; in Fedora most > (if not all) network daemons and a bunch of other things are PIE, and > there even is an entire gentoo distribution which is entirely PIE. Yes, the address space layout randomization (ASLR) as PaX calls it, makes really difficult to get done the so-called ret2libc attacks, but anyway it could be interesting to write some tests trying to achieve it, most for fun than an useful thing, as (unexpected) results might be as randomized as the address space can be ;D PIE is, hopefully, also being introduced in Debian-based systems by the Hardened Debian project. Gentoo has the Hardened Gentoo official sub project, which is doing (and has did) a great work around this stuff, among the deployment of other security technologies. Cheers and thanks for the comments, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] [2048g/9AE91A22] Hardened Debian head developer & project manager signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
