Re: Grsec/PaX and Exec-shield
On Tue, Nov 04, 2003 at 12:39:46PM +0100, Peter Busser said On Tue, 04 Nov 2003, Peter Busser wrote: In fact, anyone can do it Russell, I'm pretty sure even you can do it: Why not volunteer to make the .deb, get a sponsor and get it uploaded then? Good idea! Already did that in fact. So who do I send this new kernel-source .deb to? Put it up somewhere and then ask on the debian-mentors (@lists.debian.org) list for a sponsor. I sure hope you mean ...this new kernel-patch .deb..., though, since adding an entirely new kernel source package for a patch that takes less time to apply the patch to the Debian kernel than the time that is wasted on this discussion seems silly. -- Rob Weir [EMAIL PROTECTED] | [EMAIL PROTECTED] | Do I look like I want a CC? Words of the day: Yukon JFK mindwar signature.asc Description: Digital signature
Re: Grsec/PaX and Exec-shield
Hi! I volunteered to make a package for exec-shield because it meets the Debian criteria, I have time to do it, and it interests me. PaX would take much more time so I can't do it. You cannot do it or you don't want to do it? In fact, anyone can do it Russell, I'm pretty sure even you can do it: apt-get install kernel-source-2.4.22 cd /usr/src tar xvfj kernel-source-2.4.22 cd kernel-source-2.4.22 wget http://pageexec.virtualave.net/pax-linux-2.4.22-200310051430.patch patch -p1 pax-linux-2.4.22-200310051430.patch And now you can make menuconfig etc. Now, that wasn't too difficult, right? I worry about the security of my own machines, and that of people I know. Exec-shield offers some benefits and is something I can use now. PaX will not work with the Debian kernel and no-one has volunteered to make it work. Unless someone (maybe you) volunteers to get PaX working with the Debian kernel then it won't be an option for most people. So you tried to apply PaX to the Debian kernel and failed? Can you explain what exactly you did, which kernel version you used, which PaX patch and how you applied it? I really don't understand why an experienced kernel patcher like you can have problems with a nobrainer patch. I do it all the time for Adamantix kernels (which are based on the Debian kernel source packages) and it goes in without a hitch everytime. I wish other patches were as easy to apply. And it works. The Adamantix kernel is used on mission critical production systems. I have installed the PaX kernel on a Debian Sarge system and it worked. Any Adamantix user will tell you that PaX works. I honestly do not know what you are talking about. And if I didn't know any better, I would think you were a newbie. You can even disable some of the PaX features to lower the level of security to the exec-shield level. Another thing is that exec-shield is (AFAIK) only availabe on the i386 platform. I always thought that Debian was a multiplatform distribution. PaX is supported on Alpha, PowerPC, HPPA, Sparc, etc. (I think that AMD64 is also supported). There is simply no technical reason to chose exec-shield. However, there may of course be other reasons. Such as political reasons. Anyways, I included a patch for kernel-source-2.4.22 here. It took me 10 minutes to create it (yeah, slow computers suck). I'm sure Herbert Xu knows how to apply it. For those who don't: apt-get source kernel-source-2.4.22 cd kernel-source-2.4.22-2.4.22 bzcat kernel-source-2.4.22+pax.diff.bz2 | patch -p1 Now that can't be too hard, can it? Groetjes, Peter Busser -- The Adamantix Project Taking high-security Linux out of the labs, and into the real world http://www.adamantix.org/ kernel-source-2.4.22+pax.diff.bz2 Description: Binary data
Re: Grsec/PaX and Exec-shield
[NB: When reponsding using the web archives, please get the References and In-Reply-To: correctly. You may also consider setting MFT:] On Tue, 04 Nov 2003, Peter Busser wrote: PaX would take much more time so I can't do it. You cannot do it or you don't want to do it? Russell has made it adequately clear that he doesn't have the time or the desire to deal with PaX at this time. As a volunteer, that's always his prerogative. [As a side note, if you are trying to enlist volunteers, I strongly suggest not berating other developers while doing it.[1]] In fact, anyone can do it Russell, I'm pretty sure even you can do it: Why not volunteer to make the .deb, get a sponsor and get it uploaded then? Surely you have more control over where you spend your time than how Russell spends his own? Don Armstrong 1: See the mplayer saga for a relevant example. -- Filing a bug is probably not going to get it fixed any faster. -- Anthony Towns http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Grsec/PaX and Exec-shield
Thomas Viehmann wrote: So, please don't start insulting and accusing people for doing good work and proposing to do even more of it. If there are technical reasons that cause you to prefer that exec-shield does not become part of Debian's standard kernel, just put them on the table, but save us your conspiracy theories. I have seen noone accusing Russel from doing good work. The problem here is not the good work, it is the things he says that can easilly be proven wrong. For those who don't know, Adamantix is a Debian based distribution aiming to create a highly secure Linux system. Most packages used in Adamantix are Debian packages, including the kernel packages. Almost all packages have been recompiled to make maximum use of the features PaX provides. Most programs run fine. Only a handful of programs have problems. PaX has been a standard part of the kernel in Adamantix for almost a year now. And it is used on mission critical production systems with SLAs. So what are the facts: - PaX works, even on Debian kernels. Adamantix proves it. - It provides more security than you get by installing the latest updates: http://groups.google.com/groups?selm=20030525190037%2470c6%40gated-at.bofh.it (Also proof that it works with Debian) - It takes less time to apply the patch to the Debian kernel than the time that is wasted on this discussion. - The functionality can be tuned to specific needs by changing the kernel configuration. That means, you can lower the security at a level comparable to exec-shield if you want to. - I have installed an Adamantix kernel on a Sarge system and the command line stuff worked (didn't test it thoroughly). If packages follow the current Debian policy, they should be mostly okay, even if the most restrictive settings are used (like in the Adamantix kernel packages). - You don't need to recompile if you don't want to. It only adds more security if you do. - PaX is available on different platforms and not only on i386. That is, Alpha, PowerPC, HPPA and others. - The design and implementation of PaX have been documented and are open to public scrutiny: http://pageexec.virtualave.net/docs/index.html This includes a description of limitations and design choices made, so you can find out what trade-offs have been made (or haven't been made). - PaX is independent from gr-security. And can be downloaded and applied to the kernel without having to download gr-security. - It is POSIX compliant. Programs that break are those who try to go beyond the limits of POSIX. Most of them can be fixed. And those that cannot be fixed (like the Java JDK, which is available as binary only) can be made to run without much hassle. The package maintainer can take care of this, it is as complicated as stripping binaries. We're talking about a handful of programs here anyway. - It is possible to have a fully functional distribution running on PaX. The OpenBSD project proves that, it has features similar to PaX in the kernel, and you can still run all the goodies. - Running paxtest shows the differences between PaX and exec-shield. Everyone is invited to run paxtest to see for yourself. So far I have heard a lot of talk and a number of opinions on why PaX is bad. But no proof. I can reasonably proof any of the above. But I have seen no such proof from those who propose exec-shield so far, only opinions and cheap talk. Opinions are like assholes, everyone has one. It is proof that counts. Groetjes, Peter Busser -- The Adamantix Project Taking high-security Linux out of the labs, and into the real world http://www.adamantix.org/
Re: Grsec/PaX and Exec-shield
On Tue, 4 Nov 2003, Peter Busser wrote: - Running paxtest shows the differences between PaX and exec-shield. Everyone is invited to run paxtest to see for yourself. the reply below mostly a re-sent of a mail i sent to you privately - but you repeat this argument again without any apparent answer to my counter-arguments. Summary: i can see no significant differences between the paxtest output - all the differences seem to be bogus, see the details below. Here's the output of paxtest-0.9.4 under an exec-shield-G4 kernel: Executable anonymous mapping : Killed Executable bss : Killed Executable data : Killed Executable heap : Killed Executable stack : Killed the above ones are important, exec-shield catches these exploit categories. Executable anonymous mapping (mprotect) : Vulnerable Executable bss (mprotect): Vulnerable Executable data (mprotect) : Vulnerable Executable heap (mprotect) : Vulnerable Executable shared library bss (mprotect) : Vulnerable Executable shared library data (mprotect): Vulnerable Executable stack (mprotect) : Vulnerable i do believe the above checks are bogus, please explain to me why this case is important to handle. the test checks whether it's possible to execute an area after mprotect(PROT_EXEC) has been called over it. The answer: of course it's executable, the application asked the kernel for this! Any exploit that can call mprotect() has free reign anyway. The ability to execute a library call or a system-call is End Of Story. Why is it such a big issue to inhibit mprotect() calls? Especially since not honoring mprotect() calls breaks existing apps and specifications. if you can call mprotect() then you can very well call munmap() and mmap(MAP_FIXED,PROT_EXEC) as well, which is equivalent to the mprotect() call. From whatever angle i look at this test, it's bogus. in any case, the above restriction is trivial to add to the kernel but still i didnt want to add it because it's simply pointless. Anonymous mapping randomisation test : 8 bits (guessed) Heap randomisation test (ET_EXEC): 14 bits (guessed) Heap randomisation test (ET_DYN) : 13 bits (guessed) Main executable randomisation (ET_EXEC) : No randomisation Main executable randomisation (ET_DYN) : 12 bits (guessed) Shared library randomisation test: 12 bits (guessed) Stack randomisation test (SEGMEXEC) : 17 bits (guessed) Stack randomisation test (PAGEEXEC) : 17 bits (guessed) these are acceptable levels or randomization against remote attacks, except the ET_EXEC one, but ET_DYN is used for PIE binaries so this is not an issue. Return to function (strcpy) : Vulnerable Return to function (strcpy, RANDEXEC): Vulnerable Return to function (memcpy) : Vulnerable Return to function (memcpy, RANDEXEC): Vulnerable (these can only be caught via compiler changes, clearly not a target for PaX or exec-shield.) Executable shared library bss: Killed Executable shared library data : Killed these are caught by exec-shield too, and are quite important categories to catch. Writable text segments : Vulnerable again, i think this is a bogus restriction too. Why deny writable text segments? Control over the application at such a level is Game Over in virtually every case. summary: exec-shield catches all the non-bogus categories and tries to raise the bar of exploitation, without breaking binary compatibility arbitrarily. Ingo
Re: Grsec/PaX and Exec-shield
Hi! [NB: When reponsding using the web archives, please get the References and In-Reply-To: correctly. You may also consider setting MFT:] I can't post from the lists.debian.org site. On Tue, 04 Nov 2003, Peter Busser wrote: PaX would take much more time so I can't do it. You cannot do it or you don't want to do it? Russell has made it adequately clear that he doesn't have the time or the desire to deal with PaX at this time. As a volunteer, that's always his prerogative. [As a side note, if you are trying to enlist volunteers, I strongly suggest not berating other developers while doing it.[1]] Agreed, Russell is free to do what he wants. However, other Debian developers benefit from having accurate information, to base their opinions on. And so far I have seen statements on PaX that have been anything but accurate. I'm not in fact trying enlist volunteers. I try to offend as many Debian people as possible, so that they choose exec-shield. This to ensure that Adamantix will has an edge in security over Debian in the future. And it seems to be working very well so far. Besides that, I can imagine that gr-security does not work on the current Debian kernels. But really, PaX and gr-security are two completely different things. PaX is related to gr-security in the same way the Linux kernel is related to Debian. It is just a part of it, but the PaX project is independent of gr-security. In fact, anyone can do it Russell, I'm pretty sure even you can do it: Why not volunteer to make the .deb, get a sponsor and get it uploaded then? Good idea! Already did that in fact. So who do I send this new kernel-source .deb to? Groetjes, Peter Busser -- The Adamantix Project Taking high-security Linux out of the labs, and into the real world http://www.adamantix.org/
Re: Grsec/PaX and Exec-shield
Hi! the reply below mostly a re-sent of a mail i sent to you privately - but you repeat this argument again without any apparent answer to my counter-arguments. I already suggested you to reread the PaX documentation, there are the answers to your questions. There is no need to copy/paste it here. Summary: i can see no significant differences between the paxtest output - all the differences seem to be bogus, see the details below. Fact is: There is a difference in paxtest output between PaX and exec-shield. And it is not a difference in exec-shield's advantage. Another fact: If you don't like this difference, you can change the PaX kernel configuration to lower the level of security to the same level as exec-shield. You didn't touch the other facts in the list, because you know you don't have any proof to easily dismiss them. You would be my hero if you succeeded in improving on PaX. But in all honesty, exec-shield does not do that I'm afraid. In fact, there is simply no technical reason whatsoever for exec-shield to exist at all. None. Groetjes, Peter Busser -- The Adamantix Project Taking high-security Linux out of the labs, and into the real world http://www.adamantix.org/
Re: Grsec/PaX and Exec-shield
On Tue, Nov 04, 2003 at 12:39:46PM +0100, Peter Busser wrote: Why not volunteer to make the .deb, get a sponsor and get it uploaded then? Good idea! Already did that in fact. So who do I send this new kernel-source .deb to? You can use the mentors service to exchange your packages with your sponsor. All informations how to (d)upload your packages to the Mentors Server are explained on the homepage[0]. After uploading it to the Server you can seek for an sponsor using debian-mentors@lists.debian.org, this one (debian-devel), or the phpBB forum which is also aviable at the mentors homepage. [0] http://mentors.debian.net bye, - michael
Re: Grsec/PaX and Exec-shield
* Peter Busser ([EMAIL PROTECTED]) [031104 13:55]: You didn't touch the other facts in the list, because you know you don't have any proof to easily dismiss them. You would be my hero if you succeeded in improving on PaX. But in all honesty, exec-shield does not do that I'm afraid. In fact, there is simply no technical reason whatsoever for exec-shield to exist at all. None. you seem to suffer from an accute case of hybris. i feel you are in the position to bring proof, if you disagree with ingo. He seems to have thought about the issue a minute or two and dislpayed some skill in the area allready.
Re: Grsec/PaX and Exec-shield
On Tue, 4 Nov 2003, Peter Busser wrote: the reply below is mostly a re-send of a mail i sent to you privately but you repeat this argument again without any apparent answer to my counter-arguments. I already suggested you to reread the PaX documentation, there are the answers to your questions. There is no need to copy/paste it here. yes, i've read them, and they do not answer my questions. The PaX documentation says: Non-executable pages and mprotect() restrictions are effective in preventing the introduction of new executable code into an attacked task's address space. There remain only two venues for this kind of attack: [ write files ] [ map existing library ] this is plainly not true. Firstly, PaX doesnt solve the write a file and mmap() it problem, so what's your point? Secondly, you can eg. write a shell-script into non-executable memory and system() it. Etc., etc. The ability to mprotect() a page already requires good control over the binary, at which point you can do basically whatever the application can do normally. Arguing for this mprotect() restriction is like arguing that i am only a little bit pregnant. The attacker controls the application and there are many ways to use that control to do Bad Stuff. The mprotect() restriction is an after-the-fact restriction that reduces system utility in a way that by its own documentation is an admittedly non-complete protection. In fact it adds little if any protection. Exec-shield does not include such arbitrary policy decisions. The attacker has broken in, he controls the app, it's just a matter of time until he owns everything the app owns (or more) - mprotect() restrictions or not. besides, the mprotect() change: Restrict mprotect() CONFIG_PAX_MPROTECT Enabling this option will prevent programs from - changing the executable status of memory pages that were not originally created as executable, - making read-only executable pages writable again, - creating executable pages from anonymous memory. breaks a fair number of legitimate applications, breaking binary compatibility, which is an additional no-no too. and this is easy. Breaking binaries and increasing security by making the system less useful. Summary: i can see no significant differences between the paxtest output - all the differences seem to be bogus, see the details below. Fact is: There is a difference in paxtest output between PaX and exec-shield. And it is not a difference in exec-shield's advantage. this what i'm disputing, because those tests i criticised are arbitrary (see above). The other tests are OK and paxtest is a useful utility, no doubt about that! by your argument you could add this to paxtest: printf(PaX is inherently better\n); there's no way exec-shield could get around this difference in output ;-) Another fact: If you don't like this difference, you can change the PaX kernel configuration to lower the level of security to the same level as exec-shield. my point is that CONFIG_PAX_MPROTECT is not acceptable in a generic Linux kernel, and that there's no 'reduction in security' by not using it. If you can give me specific examples of exploit techniques that this disables in a way that cannot be worked around then my point is incorrect. Ingo
Re: Grsec/PaX and Exec-shield
Peter Busser [EMAIL PROTECTED] writes: On Tue, 04 Nov 2003, Peter Busser wrote: In fact, anyone can do it Russell, I'm pretty sure even you can do it: Why not volunteer to make the .deb, get a sponsor and get it uploaded then? Good idea! Already did that in fact. So who do I send this new kernel-source .deb to? I sincerely hope that you did not create a prepatched kernel-source package. OTOH, this would explain a lot about your mails on d-d. -- CYa, Mario | Debian Developer URL:http://debian.org/ | Get my public key via finger [EMAIL PROTECTED] | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
Re: Grsec/PaX and Exec-shield
Peter Busser wrote: Summary: i can see no significant differences between the paxtest output - all the differences seem to be bogus, see the details below. Fact is: There is a difference in paxtest output between PaX and exec-shield. And it is not a difference in exec-shield's advantage. Peter, no one contested that there is a difference. Ingo contested the meaningfulnes of that difference. Now, it's your turn trying to explain *why* the difference is meaningful; not just that it exists. HTH, HAND.
Re: Grsec/PaX and Exec-shield
Peter Busser [EMAIL PROTECTED] writes: I volunteered to make a package for exec-shield because it meets the Debian criteria, I have time to do it, and it interests me. PaX would take much more time so I can't do it. You cannot do it or you don't want to do it? In fact, anyone can do it Russell, I'm pretty sure even you can do it: apt-get install kernel-source-2.4.22 cd /usr/src tar xvfj kernel-source-2.4.22 cd kernel-source-2.4.22 wget http://pageexec.virtualave.net/pax-linux-2.4.22-200310051430.patch patch -p1 pax-linux-2.4.22-200310051430.patch And now you can make menuconfig etc. Now, that wasn't too difficult, right? If this is your idea of maintaining a package, I am glad that you are not a Debian developer. I hope you take better care in putting together Adamantix, otherwise I pity the poor souls who use it and believe it is Trusted... Lukas P.S.: Why does everyone attack Russell these days? Seems to me like the field of Linux security is populated by lots of trolls.
Re: Grsec/PaX and Exec-shield
On Tue, 4 Nov 2003 19:53, Peter Busser wrote: I volunteered to make a package for exec-shield because it meets the Debian criteria, I have time to do it, and it interests me. PaX would take much more time so I can't do it. You cannot do it or you don't want to do it? In fact, anyone can do it Russell, I'm pretty sure even you can do it: Actually I have not tried patching in PaX on it's own. I tried GRSec and found that the conflicts were greater than I could fix in any reasonable amount of time. During the previous discussions on grsec I had got the impression that PaX was the hard part of such a code merge, maybe that impression was incorrect. Also note that I use LSM on all my kernels, so anything that conflicts with LSM is something that I have no ability to test and therefore no interest in maintaining. I'm sure I could get PaX working with LSM, but it would take some work. Anyway I'll look into this matter after I upload an exec-shield package. I'm not in fact trying enlist volunteers. I try to offend as many Debian people as possible, so that they choose exec-shield. This to ensure that Adamantix will has an edge in security over Debian in the future. And it seems to be working very well so far. This seems to conflict with your web site. From http://www.adamantix.org/motivation.html: # That is why I started this project, to create a secure Linux platform and # make it available to everyone. Yes I know OpenBSD exists and I think they do # a great job. However, free software is all about freedom of choice and it is # be good to be able to choose between different highly secure systems. In a # sense my aim is also to create a reference platform, so users can ask Linux # distribution vendors: ``Why don't you provide this?'' In the future I would # very much like to see that this project serves no purpose anymore, because # some or all of its ideas ended up in other (more mainstream) distributions. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Grsec/PaX and Exec-shield
Also note that I use LSM on all my kernels, so anything that conflicts with
LSM is something that I have no ability to test and therefore no interest in
maintaining. I'm sure I could get PaX working with LSM, but it would take
some work. Anyway I'll look into this matter after I upload an exec-shield
package.
I've spared you your precious time and gone ahead and done this for you.
Funny thing is that the latest version of LSM for 2.4 is still at
2.4.20. Trying to patch a clean 2.4.22 kernel with this results in
rejects in 9 files. Here're the contents of the rejects:
***
*** 329,335
};
#define MAY_PTRACE(p) \
- (p==current||(p-p_pptr==current(p-ptrace
PT_PTRACED)p-state==TASK_STOPPED))
static int mem_open(struct inode* inode, struct file* file)
--- 329,335
};
#define MAY_PTRACE(p) \
+ (p==current||(p-p_pptr==current(p-ptrace
PT_PTRACED)p-state==TASK_STOPPEDsecurity_ops-ptrace(current,p)==0))
static int mem_open(struct inode* inode, struct file* file)
***
*** 1418,1423
if (!sb)
goto out;
}
ret = -EINVAL;
switch (cmds) {
--- 1421,1430
if (!sb)
goto out;
}
+
+ ret = security_ops-quotactl (cmds, type, id, sb);
+ if (ret)
+ goto out;
ret = -EINVAL;
switch (cmds) {
***
*** 75,86
static kmem_cache_t * inode_cachep;
- #define alloc_inode() \
-((struct inode *) kmem_cache_alloc(inode_cachep, SLAB_KERNEL))
static void destroy_inode(struct inode *inode)
{
if (inode_has_buffers(inode))
BUG();
kmem_cache_free(inode_cachep, (inode));
}
--- 76,101
static kmem_cache_t * inode_cachep;
+ static inline struct inode *alloc_inode(void)
+ {
+ struct inode *inode;
+
+ inode = ((struct inode *) kmem_cache_alloc(inode_cachep,
SLAB_KERNEL));
+ if (!inode)
+ return NULL;
+ inode-i_security = NULL;
+ if (security_ops-inode_alloc_security(inode)) {
+ kmem_cache_free(inode_cachep, (inode));
+ return NULL;
+ }
+ return inode;
+ }
+
static void destroy_inode(struct inode *inode)
{
if (inode_has_buffers(inode))
BUG();
+ security_ops-inode_free_security(inode);
kmem_cache_free(inode_cachep, (inode));
}
***
*** 27,32
#include linux/devfs_fs_kernel.h
#include linux/major.h
#include linux/acct.h
#include asm/uaccess.h
--- 27,33
#include linux/devfs_fs_kernel.h
#include linux/major.h
#include linux/acct.h
+ #include linux/security.h
#include asm/uaccess.h
***
*** 1044,1063
asmlinkage long sys_sethostname(char *name, int len)
{
int errno;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
if (len 0 || len __NEW_UTS_LEN)
return -EINVAL;
down_write(uts_sem);
- errno = -EFAULT;
- if (!copy_from_user(system_utsname.nodename, name, len)) {
- system_utsname.nodename[len] = 0;
- errno = 0;
- }
up_write(uts_sem);
- return errno;
}
asmlinkage long sys_gethostname(char *name, int len)
--- 1043,1067
asmlinkage long sys_sethostname(char *name, int len)
{
+ char nodename[__NEW_UTS_LEN+1];
int errno;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
if (len 0 || len __NEW_UTS_LEN)
return -EINVAL;
+ if (copy_from_user(nodename, name, len))
+ return -EFAULT;
+ nodename[len] = 0;
+
+ errno = security_ops-sethostname(nodename);
+ if (errno)
+ return errno;
+
down_write(uts_sem);
+ memcpy(system_utsname.nodename, nodename, len+1);
up_write(uts_sem);
+ return 0;
}
asmlinkage long sys_gethostname(char *name, int len)
***
*** 1083,1101
*/
asmlinkage long sys_setdomainname(char *name, int len)
{
int errno;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
if (len 0 || len __NEW_UTS_LEN)
return -EINVAL;
down_write(uts_sem);
- errno = -EFAULT;
- if (!copy_from_user(system_utsname.domainname, name, len)) {
- errno = 0;
- system_utsname.domainname[len] = 0;
- }
up_write(uts_sem);
return errno;
}
--- 1087,1109
*/
asmlinkage long sys_setdomainname(char *name, int len)
{
+ char domainname[__NEW_UTS_LEN+1];
int errno;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
if (len 0 || len __NEW_UTS_LEN)
return -EINVAL;
+ if (copy_from_user(domainname, name, len))
+ return -EFAULT;
+ domainname[len] = 0;
+
+ errno = security_ops-setdomainname(domainname);
Re: Grsec/PaX and Exec-shield
On Tue, Nov 04, 2003 at 10:56:23AM -0500, [EMAIL PROTECTED] wrote: Now surely, Russell, a security expert such as yourself is capable of copy+pasting that last reject in the file. Doing this took one minute. I would imagine this was much less time than it took for you to write your ignorant mails complaining about things you don't understand or haven't bothered to try yourself. If you get down and you quarrel everyday, You're saying prayers to the devils, I say. Why not help one another on the way? Make it much easier. It's fun to learn new things! Yes, it is! bye, - michael
Re: Grsec/PaX and Exec-shield
On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote: [...] Are you so certain that Exec-shield stops execution in shared library bss/data? [...] no, it doesnt, this is the main (and pretty much only) substantial difference between exec-shield and PaX. Exec-shield will stop execution in ET_EXEC binary's bss/data but it will not stop code injection into library bss/data. Here is the 'protection matrix' of all the overflowable and shellcodable virtual memory areas: stock exec-shield PaX --- environment/argv/aux noyes yes stack noyes yes anon mmapsnoyes yes malloc() noyes yes binary bss/data noyes yes lib bss/data nono yes [...] So I wonder what happens when someone tries to run tuxracer on a system that doesn't use PT_GNU_STACK? Will Exec-shield then break binary compatibility without the presence of its self-made standard? what do you mean? tuxracer runs just fine here. If you mean exec-shield=2 then it is 'forcing' exec-shield and is only recommended for testing purposes. Running exec-shield=1 on a system with or without PT_GNU_STACK sections will result in a working system. PT_GNU_STACK itself influences nothing. Note that the Fedora kernel defaults to exec-shield=1. PT_GNU_STACK is a way to _automatically_ tag binaries/libraries whether they need the stack to be executable or not. So instead of putting the burden of 'chpax-ing broken applications' on the administrator or distribution maker (and third party developers, and the scientific community, and ...), this method tracks executability requirements automatically. So you'll get a non-executable stack in like 99% of the cases. It would be great if Debian adopted the PT_GNU_STACK changes too, they can push the concept of non-executable stacks into the mainstream. Ingo
Re: Grsec/PaX and Exec-shield
Le mar 04/11/2003 à 16:56, [EMAIL PROTECTED] a écrit : Also, I think both you and Ingo will be interested to see the results of a bugfixed version of paxtest. Are you so certain that Exec-shield stops execution in shared library bss/data? Or did you just say it because that's what a program told you? Do you want to change your answer before it's released? Or can you tell me why Exec-shield will prevent execution in those areas? If you can tell my why, I'll be sure to tell you why it doesn't, and why it's impossible for it to. Give us facts. Are you advertising the latest Windows 2012 server software before it is written, or discussing about computer security? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Re: Grsec/PaX and Exec-shield
On Tue, Nov 04, 2003 at 07:51:52PM +0100, Josselin Mouette wrote: Le mar 04/11/2003 à 16:56, [EMAIL PROTECTED] a écrit : Also, I think both you and Ingo will be interested to see the results of a bugfixed version of paxtest. Are you so certain that Exec-shield stops execution in shared library bss/data? Or did you just say it because that's what a program told you? Do you want to change your answer before it's released? Or can you tell me why Exec-shield will prevent execution in those areas? If you can tell my why, I'll be sure to tell you why it doesn't, and why it's impossible for it to. Give us facts. Are you advertising the latest Windows 2012 server software before it is written, or discussing about computer security? Nah, he just tries to imitate Theo. Unfortunately, he misses some elements - clue, taste and understanding of the difference between arguments and handwaving. Working in that area can make one an asshole; however, being an asshole does not qualify for such work...
Re: Grsec/PaX and Exec-shield
On Tue, Nov 04, 2003 at 06:49:58PM +0100, Ingo Molnar wrote: On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote: [...] Are you so certain that Exec-shield stops execution in shared library bss/data? [...] no, it doesnt, this is the main (and pretty much only) substantial difference between exec-shield and PaX. Well that sounds quite a bit different than what you had to say about these yesterday: these are caught by exec-shield too, and are quite important categories to catch. Clearly both cannot be correct at the same time. Exec-shield will stop execution in ET_EXEC binary's bss/data but it will not stop code injection into library bss/data. Here is the 'protection matrix' of all the overflowable and shellcodable virtual memory areas: That's not quite correct. Exec-shield can stop, but will stop is a completely different matter. I'll let the bugfixed paxtest tell this story, however. If you mean exec-shield=2 then it is 'forcing' exec-shield and is only recommended for testing purposes. For the benefit of the readers that might have missed this subtle attempt at diverting the main point of my argument: exec-shield=2 means enabling exec-shield on all binaries but the ones it is disabled for. This would be a secure-by-default design, and yet it's being recommended for testing purposes only? Note that PaX enables itself on all binaries by default, and that Ingo here does not argue that exec-shield=2 could result in a non-working system. Basically, his following argument, which I cannot refute, is that if exec-shield is DISABLED BY DEFAULT ON ALL BINARIES, then it results in a working system. Now, I remember some complaining about having to chpax java if you run it and PaX breaks it. How is that more work than running exec-shield in =1 mode, and having to explicitly enable it on all binaries you think should have protection, since you don't recommend =2 for production machines? Or, through what mechanism have you devised to notify the user when an application he thought was protected by exec-shield decides to mprotect an anonymous mapping rwx, thus making the main executable's bss and data sections executable? Viewing the process' maps file isn't going to tell you what kind of protection the process currently has. How about if someone mprotects a page of the stack rwx? Whoops, entire address space because executable. I'm also curious, given the rest of your model, how the lack of trampoline emulation is a security feature. From your announcement: To provide as good protection as possible, there's no trampoline workaround in the exec-shield code - ie. exec-limit violations in the trampoline case are never let through. Applications that need to rely on gcc trampolines will have to use the per-binary ELF flag to make the stack executable again. This all sounds very contradictory to your point that there's only one substantial difference between PaX and Exec-shield (funny how it was never mentioned that PaX is a true per-page implementation, while yours is much more coarse grained...that sounds pretty substantial too). Though, I don't know what I'm talking about here. Clearly every Debian developer who was kind enough to make useless non-technical posts to this thread know much more about this subject than I do. So please, listen to your in house security experts instead of me. They're probably better for a good laugh, anyways. -Brad
Re: Grsec/PaX and Exec-shield
On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote: [...] the main point of my argument: exec-shield=2 means enabling exec-shield on all binaries but the ones it is disabled for. This would be a secure-by-default design, and yet it's being recommended for testing purposes only? [...] yes. It's a compatible opt-in for something that cannot be enabled for all binaries, instead of an opt-out. You say it's a bug, i say it's a feature. A really bad analogy: it's like spam, you want to opt-in not opt-out ;) [...] Note that PaX enables itself on all binaries by default, and that Ingo here does not argue that exec-shield=2 could result in a non-working system. Basically, his following argument, which I cannot refute, is that if exec-shield is DISABLED BY DEFAULT ON ALL BINARIES, then it results in a working system. my main argument is that on a PT_GNU_STACK-recompiled system, you'll see that the overwhelming majority of binaries and libraries have a non-exec stack almost straight away. With some extra tweaking and patching it's up to 99.9%. [ or you can manually force on the feature for every binary, if you dont have a PT_GNU_STACK system, via exec-shield=2, and disable exec-shield on a per binary basis, if you want/need to. ] i'm not sure why you are fighting the PT_GNU_STACK concept - it's not connected to exec-shield at all - just take the ELF loader bits from the exec-shield patch and use it in PaX - it will be for the better to get rid of a fair share of chpax use. (Like you changed the library layout in PaX to match that of exec-shield.) if you could get rid of the 1.5 GB VM limitation of PaX and if you could change it to use PT_GNU_STACK to set the process stack's protection bits then i think there's no need for exec-shield - PaX will provide better protection at no cost and no tradeoffs. I did and still do exec-shield to solve a problem. If something else does it better with no tradeoffs then all the better, one less maintainance headache :-) Now, I remember some complaining about having to chpax java if you run it and PaX breaks it. How is that more work than running exec-shield in =1 mode, and having to explicitly enable it on all binaries you think should have protection, since you don't recommend =2 for production machines? you dont have to explicitly enable it on all binaries you think should have protection - the compiler will do this just fine via PT_GNU_STACK. It is a property of the binary, not some policy question, whether an application needs an executable stack or not. where does PaX re-enable stack executability if an application dlopen()s a library that needs an executable stack - because eg. it is using gcc trampolines? Can you enable PaX for Mozilla and guarantee that no plugin will ever need an executable stack? java (or any other non-PT_GNU_STACK third party app) will just default to exec-shield-off. Viewing the process' maps file isn't going to tell you what kind of protection the process currently has. [...] the maps file will precisely tell you what kind of protection the process currently has - take the highest executable address. I've got a script with which you can continuously monitor the protection status of various apps on the system. Offenders are taken care of :-) [...] How about if someone mprotects a page of the stack rwx? Whoops, entire address space because executable. yes. No app currently running on my box does this though. this is one fundamental difference in the approach: instead of breaking apps and then chpax-ing them, exec-shield lets apps tell that they are capable of a non-exec stack. From your announcement: To provide as good protection as possible, there's no trampoline workaround in the exec-shield code - ie. exec-limit violations in the trampoline case are never let through. Applications that need to rely on gcc trampolines will have to use the per-binary ELF flag to make the stack executable again. this is an old announcement, and says other things too that are not the case anymore. E.g. this area got reworked since then and these (rare but existing) apps/libs are detected automatically via the PT_GNU_STACK mechanism. it's very easy to list the app executability requirements and the current protections in a live system, and it's easy to improve them one by one - while still having a 100% working system. [...] (funny how it was never mentioned that PaX is a true per-page implementation, while yours is much more coarse grained...that sounds pretty substantial too). under the exec-shield VM layout the only real relevance this has is on library bss/data executability, for like 99% (or more) of the apps. But yes, page granularity execution bits are a plus and are available on the platforms of the future. It was not acceptable to limit the VM to 1.5GB on x86. It's a tradeoff. really, if you think granularity is a big issue for everything else but library bss/data then feel free to install Fedora and check out the
re: Grsec/PaX and Exec-shield
On Tue 4 November, spender wrote:
I've spared you your precious time and gone ahead and done this for
you.
You might have a better reception if you dropped the attitude.
Anyone reading the thread will quickly form the opinion that maintaining
PaX within Debian would likely require frequent interaction with people
like yourself{1}, Tiago Assumpcao{2} and Peter Busser{3}. On the other
hand, maintaining exec-shield would involve collaborating with people
like Ingo Molnar. From reading your respective posts, I know which I'd prefer...
{1}
http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00076.html
- Arrogant arsehole. Professes not to care if users get rooted, and
would apparently withhold security vulnerabilities he discovers in
competing projects in order to further the ends of the one he himself
prefers.
{2}
http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00090.html
- Paranoid loon who believes the exec-shield ITP is part of some
sinister RedHat conspiracy to take away our freedoms.
{3}
http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00158.html
- Wants to ensure that Adamantix will have an edge in security over
Debian in the future. Claims he would very much like to see that this
project [Adamantix] serves no purpose anymore, because some or all of
its ideas ended up in other (more mainstream) distributions
(http://www.adamantix.org/motivation.html), but started the distro
before even looking into the possibility of working within Debian. Later
opted *not* to become a Debian subproject when approached by the DPL.
Yet still has the audacity to berate others for not doing enough to get
PaX into Debian!
Re: Grsec/PaX and Exec-shield
On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote: [...] Exec-shield can stop, but will stop is a completely different matter. I'll let the bugfixed paxtest tell this story, however. i am 100% sure that by taking the range-property of exec-shield into account you can construct 'bugfixed' mapping scenarios where exec-shield will be 'Vulnerable' for each test you can construct. If you do that you might as well rename 'pax-test' to 'pax-is-best' ;-) my argument is that for common apps here and now running on my system the layout is good enough for exec-shield to be quite close to that of PaX. (It wont be as complete as PaX though, notably the library bss/data areas wont be protected.) Ingo
Re: Grsec/PaX and Exec-shield
yes. It's a compatible opt-in for something that cannot be enabled for all binaries, instead of an opt-out. You say it's a bug, i say it's a feature. A really bad analogy: it's like spam, you want to opt-in not opt-out ;) That is indeed a really bad analogy. Security shouldn't be as unwanted as spam. [...] Note that PaX enables itself on all binaries by default, and that Ingo here does not argue that exec-shield=2 could result in a non-working system. Basically, his following argument, which I cannot refute, is that if exec-shield is DISABLED BY DEFAULT ON ALL BINARIES, then it results in a working system. my main argument is that on a PT_GNU_STACK-recompiled system, you'll see that the overwhelming majority of binaries and libraries have a non-exec stack almost straight away. With some extra tweaking and patching it's up to 99.9%. [ or you can manually force on the feature for every binary, if you dont have a PT_GNU_STACK system, via exec-shield=2, and disable exec-shield on a per binary basis, if you want/need to. ] i'm not sure why you are fighting the PT_GNU_STACK concept - it's not connected to exec-shield at all - just take the ELF loader bits from the exec-shield patch and use it in PaX - it will be for the better to get rid of a fair share of chpax use. (Like you changed the library layout in PaX to match that of exec-shield.) if you could get rid of the 1.5 GB VM limitation of PaX and if you could change it to use PT_GNU_STACK to set the process stack's protection bits then i think there's no need for exec-shield - PaX will provide better protection at no cost and no tradeoffs. I did and still do exec-shield to solve a problem. If something else does it better with no tradeoffs then all the better, one less maintainance headache :-) Now, I remember some complaining about having to chpax java if you run it and PaX breaks it. How is that more work than running exec-shield in =1 mode, and having to explicitly enable it on all binaries you think should have protection, since you don't recommend =2 for production machines? you dont have to explicitly enable it on all binaries you think should have protection - the compiler will do this just fine via PT_GNU_STACK. It is a property of the binary, not some policy question, whether an application needs an executable stack or not. where does PaX re-enable stack executability if an application dlopen()s a library that needs an executable stack - because eg. it is using gcc trampolines? Can you enable PaX for Mozilla and guarantee that no plugin will ever need an executable stack? If a library uses trampolines, PaX doesn't need to enable stack executability because it has trampoline emulation. I enable PaX on mozilla and use several plugins including flash with no problems. java (or any other non-PT_GNU_STACK third party app) will just default to exec-shield-off. Viewing the process' maps file isn't going to tell you what kind of protection the process currently has. [...] Sorry, I should have said what protection the process had a millisecond before you decided to check its maps file It's this kind of quantum security (while you don't observe it, it could be doing what you want or nothing at all) that I wouldn't want as an administrator. If a binary decides to create a mapping with some bad protections, in PaX, the administrator would be notified. In Exec-shield, this kind of behavior will affect the executability of sections of the address space that were previously non-executable and the administrator might never know, even if he had the same script as you checking processes on the system. this is an old announcement, and says other things too that are not the case anymore. E.g. this area got reworked since then and these (rare but existing) apps/libs are detected automatically via the PT_GNU_STACK mechanism. but is it not still true that you don't have trampoline emulation: if an application uses trampolines the solution in exec-shield is to make the entire stack executable? really, if you think granularity is a big issue for everything else but library bss/data then feel free to install Fedora and check out the mappings. It just doesnt happen all that often anymore that an app triggers some really bad protection layout, and if it happens, it's fixable in a nonintrusive way. The important thing is to have protection here and now for 99% of the layouts in a generic distribution. [with the caveat of library bss/data, as you correctly observed.] I'm making a big issue of the granularity because you make a big issue of the 1.5GB limit. While granularity in your case actually is an issue for all exec-shield apps, the fact is I've received no reports of anyone running into address space limits with PaX. So I'll agree that the granularity in cases other than libraries isn't a huge issue, and since you talk about generic distributions, you
Re: Grsec/PaX and Exec-shield
On 03-Nov-03, 11:26 (CST), Tiago Assump??o [EMAIL PROTECTED] wrote: First of all, maybe the most important, we have the freedom problem here. It?s CLEAR, after analyzing his own words, that our friend Russell Coker has a big interest of getting Exec-shield as part of Debian Linux. That becomes even more clear when you see the affirmation, again his own words, he's employed by Red Hat. So what? A lot (well, some) of Debian developers are paid by Red Hat. That hardly makes him Eevilll. I won't say here that Red Hat, Inc. would be manipulating information to force Debian users to use one of their products, because I would be going down, at the same level as Coker. Since I don't know Red Hat's relationship to this issue, I would go for how non-professional Russel Coker has been with his posts. The only non-professional posts I've seen so far are from you and the other Pax guy ([EMAIL PROTECTED]). The kind of crappy insinuation that you attempt above is *completely* non-profressional. Russell Coker, OTOH, has a long history of sane and civil posts. You're absolutely correct, you're nowhere *near* the level of Coker, but down is not the direction you need to go to get there. - Who are -you- (the ONLY individual) to define standards on linux kernel security designs? He's the person doing the work. He's hardly defining standard. If you'd been following along, you'ld now that there is currently a conflict between the standard Debian kernel (patched, like all other distribution kernels), and the grsec patch. Nobody has stepped forward to fix it. Are you doing so now? I will make a kernel-patch package. - Again, I don't understand why you should worry so much about some project you don't even own/manage. Or this is for Red Hat? Because he's interested in seeing that functionality in Debian? Do you have a fscking clue as to what group you're talking to here? We *all* maintain packages of projects that we don't own/manage! This is a lot of information, but google for much more! Users need to build their ideas, and choose what to pick! Don?t let somebody right the rules and sign out without being aware of what's up. Good advice. I won't let either you or Spender bulldoze your way in here with your wild accusations of Red Hat conspiracy. Look, if you you want Pax as part of Debian, then *YOU* create a patch in the appropriate format, and *YOU* maintain it to Debian standards. Or find someone else to do so. But you don't get to jump in here and tell the peole doing the work what to do, especially when all you have to contribute is weirdo conspiracy theories and not-very-sly personal insinuations. Steve, who hasn't see this kind of nuttiness since reading the mplayer mailling lists/flame wars. -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Grsec/PaX and Exec-shield
On Mon, Nov 03, 2003 at 02:26:42PM -0300, Tiago Assumpo wrote: First of all, maybe the most important, we have the freedom problem here. Its CLEAR, after analyzing his own words, that our friend Russell Coker has a big interest of getting Exec-shield as part of Debian Linux. That becomes even more clear when you see the affirmation, again his own words, he's employed by Red Hat. I won't say here that Red Hat, Inc. would be manipulating information to force Debian users to use one of their products, because I would be going down, at the same level as Coker. Since I don't know Red Hat's relationship to this issue, I would go for how non-professional Russel Coker has been with his posts. I think you're making unwarranted assumpos. -- G. Branden Robinson| I suspect Linus wrote that in a Debian GNU/Linux | complicated way only to be able to [EMAIL PROTECTED] | have that comment in there. http://people.debian.org/~branden/ | -- Lars Wirzenius signature.asc Description: Digital signature
Re: Grsec/PaX and Exec-shield
* Tiago Assumpção [EMAIL PROTECTED] [031103 17:48]: I won't say here that Red Hat, Inc. would be manipulating information to force Debian users to use one of their products, because I would be going down, at the same level as Coker. This should be teached in schoolbooks as paralipsis. And the rest of the mail is also full of nice rhetorical figures. Only thing I do not understand is: If you are currently training rhetoric, why do you post to a list of people mostly supposing themselves not to be keen on form but on content? Especially as I personally was not able to find any content between all those words. Greetings, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
