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 2012-01-23 07:49:19 (-0800), Greg KH 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 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

On Mon, Jan 23, 2012 at 12:49 PM, Greg KH 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 Mon, Jan 23, 2012 at 2:49 PM, Cristian Rodríguez 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 Mon, Jan 23, 2012 at 6:32 PM, Brian K. White 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 Mon, Jan 23, 2012 at 6:54 PM, Brian K. White 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, 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 || SUSE || Director Product Management

On Mon, Jan 23, 2012 at 8:23 PM, 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.

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

2012/1/23 Gerald Pfeifer :

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  || 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 Mon, Jan 23, 2012 at 5:58 PM, Brian K. White 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

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

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 SUSE -- 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 SUSE -- 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

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

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

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

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 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

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