[opensuse-factory] please fix non PIE setuid binaries
Hi, The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages. chromium cifs-utils dbus-1 eject fuse gnokii i4l-base jfbterm kdebase3 libgnomesu majordomo mc mgetty mtr open-vm-tools opie pcmciautils pdns polkit rp-pppoe scotty sudo su-wrapper thttpd uucp virtualbox vte zypper cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jan 23, 2012 at 10:54 AM, Ludwig Nussel <ludwig.nussel@suse.de> wrote:
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
Why? PIC is more easily exploitable than PDC. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jan 23, 2012 at 11:05 AM, Claudio Freire <klaussfreire@gmail.com> wrote:
Why?
PIC is more easily exploitable than PDC.
Unless you do ASLR too. Sorry for double posting. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/01/12 10:54, Ludwig Nussel wrote:
Hi,
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
You may also want to convince kernel people to default to kernel.randomize_va_space = 2 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jan 23, 2012 at 11:09:37AM -0300, Cristian Rodríguez wrote:
On 23/01/12 10:54, Ludwig Nussel wrote:
Hi,
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
You may also want to convince kernel people to default to kernel.randomize_va_space = 2a
We would love to, can we then assign all bugs that fall out from that to you? (hint, some legacy binaries and other wierd programs can't handle it.) greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/01/12 12:26, Greg KH wrote:
(hint, some legacy binaries and other wierd programs can't handle it.)
Yes, I already read that, how old are those binaries though ? btw I do not expect upstream kernel to change the default, but just changing the value for openSUSE kernels using sysctl... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jan 23, 2012 at 12:45:53PM -0300, Cristian Rodríguez wrote:
On 23/01/12 12:26, Greg KH wrote:
(hint, some legacy binaries and other wierd programs can't handle it.)
Yes, I already read that, how old are those binaries though ?
Some are quite old, some are newer just built with older tool chains. And others are brand new, yet do foolish things with the stack and the like.
btw I do not expect upstream kernel to change the default, but just changing the value for openSUSE kernels using sysctl...
And again, breaking people's systems that have been running fine for years? That's a big risk that I don't think you want to take... greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2012-01-23 07:49:19 (-0800), Greg KH <gregkh@suse.de> wrote:
On Mon, Jan 23, 2012 at 12:45:53PM -0300, Cristian Rodríguez wrote:
On 23/01/12 12:26, Greg KH wrote:
(hint, some legacy binaries and other wierd programs can't handle it.)
Yes, I already read that, how old are those binaries though ?
Some are quite old, some are newer just built with older tool chains. And others are brand new, yet do foolish things with the stack and the like.
btw I do not expect upstream kernel to change the default, but just changing the value for openSUSE kernels using sysctl...
And again, breaking people's systems that have been running fine for years? That's a big risk that I don't think you want to take...
In any case, Ludwig, and anyone else involved, please don't take this lightly. It's a change that can potentially affect a lot of users and break their system by nuking some of their favourite applications. This is the kind of change that makes a possibly non negligible amount of people stop using openSUSE, because to them, openSUSE/SUSE has always been about quality and robustness (whether that is the main goal and purpose is another question, it's always a set of different things to everyone). I'm not saying it shouldn't be done, just that it really needs consideration whether it's worth it or not. A (paraphrasing) "ok let's do it, file a bug and done" in a post in an unrelated thread on factory@ is.. um... ;) And if it's done, please not just a well-hidden post on the factory mailing-list, this would need to be broadcasted appropriately and widely, so people actually get a chance of thinking of this possibility when stuff stops working :) cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf
On 23/01/12 13:19, Pascal Bleser wrote:
In any case, Ludwig, and anyone else involved, please don't take this lightly. It's a change that can potentially affect a lot of users and break their system by nuking some of their favourite applications.
Really ? I have been running all my systems with it for around a year and have not found any app that breaks .. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jan 23, 2012 at 01:21:24PM -0300, Cristian Rodríguez wrote:
On 23/01/12 13:19, Pascal Bleser wrote:
In any case, Ludwig, and anyone else involved, please don't take this lightly. It's a change that can potentially affect a lot of users and break their system by nuking some of their favourite applications.
Really ? I have been running all my systems with it for around a year and have not found any app that breaks ..
Do you use WINE, old versions of Java, dos emulators, old versions of Oracle, old old old games built for Linux 1.x with libc? It's the programs that people on the factory list, and those running FACTORY would never see nor dream of using (well, becides WINE). That's the major risk here. greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Greg KH wrote:
On Mon, Jan 23, 2012 at 01:21:24PM -0300, Cristian Rodríguez wrote:
On 23/01/12 13:19, Pascal Bleser wrote:
In any case, Ludwig, and anyone else involved, please don't take this lightly. It's a change that can potentially affect a lot of users and break their system by nuking some of their favourite applications.
Really ? I have been running all my systems with it for around a year and have not found any app that breaks ..
Do you use WINE, old versions of Java, dos emulators, old versions of Oracle, old old old games built for Linux 1.x with libc?
Hmm. Pulseaudio already broke games by blocking /dev/dsp (but then games broke also due to various ABI changes in userspace libs, dropping of stuff like GTK1, dynamic CPU frequency scaling, changes in shell behavior etc etc. Linux gamers need to be surviors). dosbox works just fine, dosemu broke due to vm.mmap_min_addr != 0 already. There is no generic problem with wine (tested with ioq3). cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jan 23, 2012 at 12:49 PM, Greg KH <gregkh@suse.de> wrote:
btw I do not expect upstream kernel to change the default, but just changing the value for openSUSE kernels using sysctl...
And again, breaking people's systems that have been running fine for years? That's a big risk that I don't think you want to take...
In this case, it's worth the try. Address space randomization, though not a panacea for security, is a big roadblock for many security exploits. So you'd have a more secure system as a result. Not a marginal gain. But yes, some software can break. Especially JIT code, which includes java, chrome, maybe firefox. It would have to be tested quite thoroughly. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/01/12 14:47, Claudio Freire wrote:
Especially JIT code, which includes java, chrome, maybe firefox
All of those work just fine, at least the current versions. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jan 23, 2012 at 2:49 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
Especially JIT code, which includes java, chrome, maybe firefox
All of those work just fine, at least the current versions.
All the more reason to try. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 1/23/2012 12:56 PM, Claudio Freire wrote:
On Mon, Jan 23, 2012 at 2:49 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
Especially JIT code, which includes java, chrome, maybe firefox
All of those work just fine, at least the current versions.
All the more reason to try.
So, my routers and switches and ip-kvm's that have closed source not updateable firmwares with embedded webservers that rely on specific, old versions of java on the client, or even specific old versions of IE and ActiveX on the client,: I should just replace all those? Or the current versions of java/chrome/firefox includes emulation modes that accurately mimic IE6 running ActiveX from years ago, or java 1.4 ? Or this change wouldn't actually break wine and old java? Or I should maintain a special laptop or vm image that doesn't update past today and do all future network admin through that? Currently I have to use actual java 1.4 for some cisco switches and actual IE6 in Wine for some ATI ip-kvms. Cisco still exists, but they haven't updated the ios image for those switches in years. ATI still exists but they got out of the remote access hardware business years ago and only updated these devices firmware once shortly after release and never again. There are others. And that's just the java/chrome fraction of the discussion. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jan 23, 2012 at 6:32 PM, Brian K. White <brian@aljex.com> wrote:
So, my routers and switches and ip-kvm's that have closed source not updateable firmwares with embedded webservers that rely on specific, old versions of java on the client, or even specific old versions of IE and ActiveX on the client,:
I should just replace all those?
No, you should just remember to disable randomization after installing the latest openSUSE. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 1/23/2012 4:41 PM, Claudio Freire wrote:
On Mon, Jan 23, 2012 at 6:32 PM, Brian K. White<brian@aljex.com> wrote:
So, my routers and switches and ip-kvm's that have closed source not updateable firmwares with embedded webservers that rely on specific, old versions of java on the client, or even specific old versions of IE and ActiveX on the client,:
I should just replace all those?
No, you should just remember to disable randomization after installing the latest openSUSE.
If it's a run-time adjustment like a kernel command line option or a sysctl setting etc, and as long as doing that wouldn't break something else that will have thereafter started requiring that setting, then it's good enough for me. Thank you for the clarification. I wouldn't _like_ discovering the hard way one day after a routine update that stuff was broken until I managed to find why it broke and how to unbreak it, but at least it is addressable without resorting to building ones own kernel and possibly other related stuff. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jan 23, 2012 at 6:54 PM, Brian K. White <brian@aljex.com> wrote:
I wouldn't _like_ discovering the hard way one day after a routine update that stuff was broken until I managed to find why it broke and how to unbreak it, but at least it is addressable without resorting to building ones own kernel and possibly other related stuff.
Yep, quite clearly, if a release is made with this change (or when the package is pushed to tumbleweed), a very prominent announcement should be made. As a heads-up for those users who care. If misbehaving apps/drivers could be classified as sensitive to this change, and enumerated on the announcement, it would be a plus, but it depends on those using those apps/drivers testing and reporting the issues. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jan 23, 2012 at 4:41 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
On Mon, Jan 23, 2012 at 6:32 PM, Brian K. White <brian@aljex.com> wrote:
So, my routers and switches and ip-kvm's that have closed source not updateable firmwares with embedded webservers that rely on specific, old versions of java on the client, or even specific old versions of IE and ActiveX on the client,:
I should just replace all those?
No, you should just remember to disable randomization after installing the latest openSUSE.
Just so I'm clear: A individual package can be recompiled to work in a randomized environment, or the machine as a whole can be set not to randomize? So openSUSE for non-legacy users would work on getting all the apps to work in a randomized environment, but for users that have apps where that is not possible, then can disable it for their machine. Is that right? Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 23 Jan 2012, Claudio Freire wrote:
And again, breaking people's systems that have been running fine for years? That's a big risk that I don't think you want to take... In this case, it's worth the try.
Cui bono? The average openSUSE user will be very annoyed, up to the point of considering a different distribution of something she cares about breaks. Really, often it's just one thing not working, or even not working well. And even if there is a workaround, and she does not switch, such an experience certainly does not add bonus points. I am generally very much in favor of security. This, however, is not straightforward at all. Let's keep in mind that anyone on this list is _not_ an average openSUSE user! Why not make this a setting in the YaST Security and Hardening Center? Perhaps as part of adding a big "Paranoid / Default / Everything Goes" master switch? Gerald -- Dr. Gerald Pfeifer <gp@suse.com> || SUSE || Director Product Management
On Tue, 2012-01-24 at 00:23 +0100, Gerald Pfeifer wrote:
I am generally very much in favor of security. This, however, is not straightforward at all. Let's keep in mind that anyone on this list is _not_ an average openSUSE user!
I agree. Having watched the social networks more closely in recent weeks I've been very curious to observe a certain number of openSUSE users out there in the wild saying "12.1 doesn't work on my hardware anymore, I'm going back to 11.x" or whatever similar comment. The users/admins who have *more* expertise are the ones who should have the power to enable/disable at bootup, rather than those who don't know/understand what to do.
Why not make this a setting in the YaST Security and Hardening Center?
I like this. I can't WAIT to see what icon this YaST module will use. :-) Bryen
Perhaps as part of adding a big "Paranoid / Default / Everything Goes" master switch?
Gerald
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jan 23, 2012 at 8:23 PM, Gerald Pfeifer <gp@suse.com> wrote:
On Mon, 23 Jan 2012, Claudio Freire wrote:
And again, breaking people's systems that have been running fine for years? That's a big risk that I don't think you want to take... In this case, it's worth the try.
Cui bono? The average openSUSE user will be very annoyed, up to the point of considering a different distribution of something she cares about breaks. Really, often it's just one thing not working, or even not working well. And even if there is a workaround, and she does not switch, such an experience certainly does not add bonus points.
The point is to make everything on the distribution DVD and/or main repo to work. Granted, it's easier said than done. For those not too familiar with randomization and position-independent code, all libraries (.so) already use position-independent code. Many (and I mean the great majority) of application code does not care which kind of code is being generated, and only a few cases exist that would break, which includes applications that generate position-dependent machine code at run-time (older JITs), or other code that does non-standard stuff. Most C code just works, and making it position-independent or not is just a matter of compiler flags. Randomization of program addresses helps make the attacker's work of successfully exploiting an existing vulnerability harder (not impossible). Position-independent code *without* randomization, however, is easier to attack than position-dependent code. That's because position-independent code opens up a whole class of remote code execution exploits that would be hard (not impossible) to accomplish with fixed-address code if the execute-disable bit is used on data pages (which are all pae-enabled kernels). So randomization is a very significant security feature. Some exploits are trivial without randomization, but become impossible or very hard with randomization. And this means, in the presence of vulnerabilities, that is, unpatched systems. So it's a good thing. Very good thing. And it's unlikely to break a lot of stuff, anything bsd-compatible would have to run with randomization for instance.
I am generally very much in favor of security. This, however, is not straightforward at all. Let's keep in mind that anyone on this list is _not_ an average openSUSE user!
Why not make this a setting in the YaST Security and Hardening Center?
This is a very good transitional release option. Ie: for the first release with randomization, make it an opt-in feature (perhaps ask at install time?). That would allow some time for extensive testing and, when the next release makes it the default, would allow users to just turn it on on their existing installation to check that everything works. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/01/12 20:23, Gerald Pfeifer wrote:
On Mon, 23 Jan 2012, Claudio Freire wrote:
And again, breaking people's systems that have been running fine for years? That's a big risk that I don't think you want to take... In this case, it's worth the try.
Cui bono? The average openSUSE user will be very annoyed, up to the point of considering a different distribution of something she cares about breaks. Really, often it's just one thing not working, or even not working well. And even if there is a workaround, and she does not switch, such an experience certainly does not add bonus points.
I am generally very much in favor of security. This, however, is not straightforward at all. Let's keep in mind that anyone on this list is _not_ an average openSUSE user!
"There are a few legacy applications out there (such as some ancient versions of libc.so.5 from 1996) that assume that brk area starts just after the end of the code+bss. These applications break when start of the brk area is randomized. There are however no known non-legacy applications that would be broken this way, so for most systems it is safe to choose full randomization." So, if this is not true, the kernel documentation needs fixing. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2012/1/23 Gerald Pfeifer <gp@suse.com>:
On Mon, 23 Jan 2012, Claudio Freire wrote:
And again, breaking people's systems that have been running fine for years? That's a big risk that I don't think you want to take... In this case, it's worth the try.
Cui bono? The average openSUSE user will be very annoyed, up the point of considering a different distribution of something she cares about breaks. Really, often it's just one thing not working, or even not working well. And even if there is a workaround, and she does not switch, such an experience certainly does not add bonus points.
The normal user is happy with openSUSE because: - openSUSE doesn't lock up as much as Mint; - openSUSE doesn't fail as much with updates as Fedora; - openSUSE doesn't play with his Desktop Computing experience as Ubuntu; - openSUSE isn't a religion (like a few others); - openSUSE actually works out of the box with his hardware and it's stable (including systemd, at least for his needs)... What users blame us is for lack of customization :)
I am generally very much in favor of security. This, however, is not straightforward at all. Let's keep in mind that anyone on this list is _not_ an average openSUSE user!
Why not make this a setting in the YaST Security and Hardening Center?
Perhaps as part of adding a big "Paranoid / Default / Everything Goes" master switch?
openSUSE isn't a religion mate (despite some think it is, but I'm sure Wooden will straighten that up)...
Gerald -- Dr. Gerald Pfeifer <gp@suse.com> || SUSE || Director Product Management
-- Nelson Marques /* http://www.marques.so nmo.marques@gmail.com */ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 1/23/2012 10:45 AM, Cristian Rodríguez wrote:
On 23/01/12 12:26, Greg KH wrote:
(hint, some legacy binaries and other wierd programs can't handle it.)
Yes, I already read that, how old are those binaries though ?
btw I do not expect upstream kernel to change the default, but just changing the value for openSUSE kernels using sysctl...
The older the binaries are, the more important it is not to break them, because new versions can no longer be generated. There is such a thing as closed source _expensive_ commercial software, and closed source free software that is necessary to operate expensive hardware, or not-particularly-expensive-just-particularly-necessary hardware. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jan 23, 2012 at 5:58 PM, Brian K. White <brian@aljex.com> wrote:
The older the binaries are, the more important it is not to break them, because new versions can no longer be generated. There is such a thing as closed source _expensive_ commercial software, and closed source free software that is necessary to operate expensive hardware, or not-particularly-expensive-just-particularly-necessary hardware.
But in any of those cases, the sysadmin can turn randomization off. The distribution should only care about packages on the repositories, not closed source or even built-from-source open source. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/01/12 18:04, Claudio Freire wrote:
The distribution should only care about packages on the repositories, not closed source or even built-from-source open source.
Yes, otherwise the number of scenarios become impossible to support. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Greg KH wrote:
On Mon, Jan 23, 2012 at 11:09:37AM -0300, Cristian Rodríguez wrote:
On 23/01/12 10:54, Ludwig Nussel wrote:
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
You may also want to convince kernel people to default to kernel.randomize_va_space = 2a
We would love to, can we then assign all bugs that fall out from that to you?
(hint, some legacy binaries and other wierd programs can't handle it.)
Well, some not so legacy binaries couldn't deal with vm.mmap_min_addr != 0 either. I'm for trying out kernel.randomize_va_space = 2 in Factory. There's still plenty of time left until 12.2 to get a feeling for the fallout. Cristian, mind filing a feature request for documentation purpose? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian RodrC-guez wrote:
On 23/01/12 10:54, Ludwig Nussel wrote:
Hi,
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
You may also want to convince kernel people to default to kernel.randomize_va_space = 2
That's another reason why building a your own kernel is a good thing... You don't have to play politics and worry about outlier compat problems... Been running with a Vanilla k. that boots from DISK (~24 seconds from load to handover-to init), another 20-25 after that -- had ASR, since I was sure that I was running a compat gnu-library. But I don't have any 10 year proprietary legacy apps on my box either... Haven't ever noticed a problem with any binary that was **attributable** to doing so... Andy people might remember I was way conservative on the 'leap' to the new boot system that __would__ have required reformatting existing systems... (/usr + root on 1 drive).... I don't see this as a general problem -- but this is only my particular viewpoint... maybe others have more specific problems... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/01/12 10:54, Ludwig Nussel wrote:
Hi,
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
In case someone wants details and rationale, please read http://people.redhat.com/drepper/nonselsec.pdf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 23 janvier 2012, à 14:54 +0100, Ludwig Nussel a écrit :
Hi,
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
What's the right way to fix this? I was hoping there'd be a ./configure option for this, but I don't see one... Thanks, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 23 janvier 2012 à 15:45 +0100, Vincent Untz a écrit :
Le lundi 23 janvier 2012, à 14:54 +0100, Ludwig Nussel a écrit :
Hi,
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
What's the right way to fix this? I was hoping there'd be a ./configure option for this, but I don't see one...
Usually, compilation should be done by adding -fPIC to CFLAGS. libtool handles this automatically. For other compilation environment, try adding -fPIC to CFLAGS or CXXFLAGS. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/01/12 11:53, Frederic Crozat wrote:
Le lundi 23 janvier 2012 à 15:45 +0100, Vincent Untz a écrit :
Le lundi 23 janvier 2012, à 14:54 +0100, Ludwig Nussel a écrit :
Hi,
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
What's the right way to fix this? I was hoping there'd be a ./configure option for this, but I don't see one...
Usually, compilation should be done by adding -fPIC to CFLAGS.
libtool handles this automatically. For other compilation environment, try adding -fPIC to CFLAGS or CXXFLAGS.
No, -fpie or -fPIE in CFLAGS and -pie in LDFLAGS -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 23 janvier 2012 à 11:54 -0300, Cristian Rodríguez a écrit :
On 23/01/12 11:53, Frederic Crozat wrote:
Le lundi 23 janvier 2012 à 15:45 +0100, Vincent Untz a écrit :
Le lundi 23 janvier 2012, à 14:54 +0100, Ludwig Nussel a écrit :
Hi,
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
What's the right way to fix this? I was hoping there'd be a ./configure option for this, but I don't see one...
Usually, compilation should be done by adding -fPIC to CFLAGS.
libtool handles this automatically. For other compilation environment, try adding -fPIC to CFLAGS or CXXFLAGS.
No, -fpie or -fPIE in CFLAGS and -pie in LDFLAGS
oops, my bad.. This show how Vincent question was important ;) -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/01/12 11:45, Vincent Untz wrote:
Le lundi 23 janvier 2012, à 14:54 +0100, Ludwig Nussel a écrit :
Hi,
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
What's the right way to fix this? I was hoping there'd be a ./configure option for this, but I don't see one...
There is no autofoo macro for this ;-( nor even in autoconf archive or similar repos. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 23 janvier 2012, à 11:58 -0300, Cristian Rodríguez a écrit :
On 23/01/12 11:45, Vincent Untz wrote:
Le lundi 23 janvier 2012, à 14:54 +0100, Ludwig Nussel a écrit :
Hi,
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
What's the right way to fix this? I was hoping there'd be a ./configure option for this, but I don't see one...
There is no autofoo macro for this ;-( nor even in autoconf archive or similar repos.
So can we first get all this integrated in autotools? I'm not really keen on adding some custom CFLAGS to the packages, unless it's a temporary fix. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Vincent Untz wrote:
Le lundi 23 janvier 2012, à 11:58 -0300, Cristian Rodríguez a écrit :
On 23/01/12 11:45, Vincent Untz wrote:
Le lundi 23 janvier 2012, à 14:54 +0100, Ludwig Nussel a écrit :
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
What's the right way to fix this? I was hoping there'd be a ./configure option for this, but I don't see one...
There is no autofoo macro for this ;-( nor even in autoconf archive or similar repos.
So can we first get all this integrated in autotools? I'm not really keen on adding some custom CFLAGS to the packages, unless it's a temporary fix.
How deep you want it to be integrated? util-linux for example honors optional extra variables for setuid binaries, e.g. write_CFLAGS = $(SUID_CFLAGS) $(AM_CFLAGS) write_LDFLAGS = $(SUID_LDFLAGS) $(AM_LDFLAGS) Then you can call SUID_CFLAGS=-fPIE SUID_LDFLAGS=-pie ./configure ... cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 23 janvier 2012, à 16:46 +0100, Ludwig Nussel a écrit :
Vincent Untz wrote:
Le lundi 23 janvier 2012, à 11:58 -0300, Cristian Rodríguez a écrit :
On 23/01/12 11:45, Vincent Untz wrote:
Le lundi 23 janvier 2012, à 14:54 +0100, Ludwig Nussel a écrit :
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
What's the right way to fix this? I was hoping there'd be a ./configure option for this, but I don't see one...
There is no autofoo macro for this ;-( nor even in autoconf archive or similar repos.
So can we first get all this integrated in autotools? I'm not really keen on adding some custom CFLAGS to the packages, unless it's a temporary fix.
How deep you want it to be integrated? util-linux for example honors optional extra variables for setuid binaries, e.g. write_CFLAGS = $(SUID_CFLAGS) $(AM_CFLAGS) write_LDFLAGS = $(SUID_LDFLAGS) $(AM_LDFLAGS)
Then you can call SUID_CFLAGS=-fPIE SUID_LDFLAGS=-pie ./configure ...
There is ./configure --with-pic, so similarly, I'd love a --with-pie. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/01/12 12:59, Vincent Untz wrote:
There is ./configure --with-pic, so similarly, I'd love a --with-pie.
Yeah, but that would require modifing libtool , lots of luck with that ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 23 janvier 2012, à 13:03 -0300, Cristian Rodríguez a écrit :
On 23/01/12 12:59, Vincent Untz wrote:
There is ./configure --with-pic, so similarly, I'd love a --with-pie.
Yeah, but that would require modifing libtool , lots of luck with that ;-)
Why would we need luck? If that's the right thing to do, let's just do it. If people upstream disagree that such a change is needed, then they might have good arguments that should question the proposed change. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Ludwig Nussel <ludwig.nussel@suse.de> writes:
Vincent Untz wrote:
Le lundi 23 janvier 2012, à 11:58 -0300, Cristian Rodríguez a écrit :
On 23/01/12 11:45, Vincent Untz wrote:
Le lundi 23 janvier 2012, à 14:54 +0100, Ludwig Nussel a écrit :
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
What's the right way to fix this? I was hoping there'd be a ./configure option for this, but I don't see one...
There is no autofoo macro for this ;-( nor even in autoconf archive or similar repos.
So can we first get all this integrated in autotools? I'm not really keen on adding some custom CFLAGS to the packages, unless it's a temporary fix.
How deep you want it to be integrated? util-linux for example honors optional extra variables for setuid binaries, e.g. write_CFLAGS = $(SUID_CFLAGS) $(AM_CFLAGS) write_LDFLAGS = $(SUID_LDFLAGS) $(AM_LDFLAGS)
Then you can call SUID_CFLAGS=-fPIE SUID_LDFLAGS=-pie ./configure ...
Just to make sure, you want to compile *ALL* software with -fPIE? Or just those that do not explicitly mention that they'd break with -fPIE set? Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 23 January 2012 17:54:55 Ludwig Nussel wrote:
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
kdebase3
Fix to kdebase3 submitted to Factory https://build.opensuse.org/request/show/101231 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Ludwig Nussel wrote:
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
JFYI, tracker bug is here: https://bugzilla.novell.com/showdependencytree.cgi?id=744091 cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 30 janvier 2012, à 16:12 +0100, Ludwig Nussel a écrit :
Ludwig Nussel wrote:
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
JFYI, tracker bug is here: https://bugzilla.novell.com/showdependencytree.cgi?id=744091
I'm really not fond of the way we're approaching this: we're just patching all packages. This is not a good long term solution (patches will have to be rebased, people might remove the patches because they don't understand what they're for, etc.) and this is not scalable. Can't we do something a little bit better? I see that Debian has this, for instance: http://wiki.debian.org/Hardening http://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_PIE_.28gcc.2BAC8-g.2B-.... I feel that having a wrapper like they do is a much cleaner solution in the end. Is this something we could take inspiration from? Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Feb 14, 2012 at 10:40:13AM +0100, Vincent Untz wrote:
Le lundi 30 janvier 2012, à 16:12 +0100, Ludwig Nussel a écrit :
Ludwig Nussel wrote:
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
JFYI, tracker bug is here: https://bugzilla.novell.com/showdependencytree.cgi?id=744091
I'm really not fond of the way we're approaching this: we're just patching all packages. This is not a good long term solution (patches will have to be rebased, people might remove the patches because they don't understand what they're for, etc.) and this is not scalable.
Those patches should of course get sent upstream, with autoconf wrappers when necessary. Usual distro work and it should scale...
Can't we do something a little bit better? I see that Debian has this, for instance: http://wiki.debian.org/Hardening http://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_PIE_.28gcc.2BAC8-g.2B-....
I feel that having a wrapper like they do is a much cleaner solution in the end. Is this something we could take inspiration from?
They have the same concerns like you voiced above... We can change the defaults for the whole distro of course. ld -z relro is btw already default, Hmm, wonder if special .spec file things like debian does there are the way to go. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 14 février 2012, à 10:54 +0100, Marcus Meissner a écrit :
On Tue, Feb 14, 2012 at 10:40:13AM +0100, Vincent Untz wrote:
Le lundi 30 janvier 2012, à 16:12 +0100, Ludwig Nussel a écrit :
Ludwig Nussel wrote:
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
JFYI, tracker bug is here: https://bugzilla.novell.com/showdependencytree.cgi?id=744091
I'm really not fond of the way we're approaching this: we're just patching all packages. This is not a good long term solution (patches will have to be rebased, people might remove the patches because they don't understand what they're for, etc.) and this is not scalable.
Those patches should of course get sent upstream, with autoconf wrappers when necessary.
Usual distro work and it should scale...
But I've not seen any of them getting sent upstream. And in some cases, like dbus-1, we just change CFLAGS and LDFLAGS, which is not even upstreamable.
Can't we do something a little bit better? I see that Debian has this, for instance: http://wiki.debian.org/Hardening http://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_PIE_.28gcc.2BAC8-g.2B-....
I feel that having a wrapper like they do is a much cleaner solution in the end. Is this something we could take inspiration from?
They have the same concerns like you voiced above...
I beg to disagree: - no need to rebase patches - seeing such a flag/wrapper in a package is much clearer than seeing "-fpie" (which most people won't understand once this thread will be forgotten) - easy to add to a package
We can change the defaults for the whole distro of course.
ld -z relro is btw already default,
Hmm, wonder if special .spec file things like debian does there are the way to go.
I'm not saying we should do everything that is on the Debian wiki page. I'm just suggesting that we add a similar mechanism. An alternative approach, that I suggested earlier, is to fix the autotools to provide a --with-pie (since it already provides --with-pic). And then everyone benefits from this. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 14/02/12 07:54, Vincent Untz wrote:
An alternative approach, that I suggested earlier, is to fix the autotools to provide a --with-pie (since it already provides --with-pic). And then everyone benefits from this.
Yes, but we need someone that groks libtool internals to add two flags disabled by default --with-pie --with-full-relro (this one sets linker flags -Wl,-z,relro,-z,now) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 14/02/12 14:28, Cristian Rodríguez wrote:
On 14/02/12 07:54, Vincent Untz wrote:
--with-full-relro (this one sets linker flags -Wl,-z,relro,-z,now)
or maybe --enable-bind-now ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Vincent Untz wrote:
[...] An alternative approach, that I suggested earlier, is to fix the autotools to provide a --with-pie (since it already provides --with-pic). And then everyone benefits from this.
Well, if someone steps up and fixes autotools that would be nice indeed :-) The parameter would affect all binaries of package tough I guess. Atm only some binaries are compiled position independent. Meanwhile to avoid coding the actual flags into each package we could encourage to do it the way util-linux does it, ie honor $SUID_CLFAGS and $SUID_LDFLAGS for intended-to-be-setuid binaries. We could simply export those variables in rpm always, just like RPM_OPT_FLAGS. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 15 février 2012, à 10:01 +0100, Ludwig Nussel a écrit :
Meanwhile to avoid coding the actual flags into each package we could encourage to do it the way util-linux does it, ie honor $SUID_CLFAGS and $SUID_LDFLAGS for intended-to-be-setuid binaries.
For reference, this is the approach I've taken. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Ludwig Nussel wrote:
Ludwig Nussel wrote:
The following packages in Factory have setuid binaries that are not compiled with position independent code according to rpmlint. I'd like to make the check (non-position-independent-executable ) fatal on March 1st. I'll also file bugs for the individual packages.
JFYI, tracker bug is here: https://bugzilla.novell.com/showdependencytree.cgi?id=744091
93% fixed meanwhile. Only virtualbox and pdns left. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (16)
-
Brian K. White -
Bryen M Yunashko -
Claudio Freire -
Cristian Rodríguez -
Frederic Crozat -
Gerald Pfeifer -
Greg Freemyer -
Greg KH -
Ilya Chernykh -
Linda Walsh -
Ludwig Nussel -
Marcus Meissner -
Nelson Marques -
Pascal Bleser -
Sebastian Freundt -
Vincent Untz