Re: Expanding the list of "Hardened Packages"

On 04/04/2013 11:16 AM, Jakub Jelinek wrote: On Thu, Apr 04, 2013 at 10:59:41AM +0200, Florian Weimer wrote: On 04/04/2013 10:42 AM, Jakub Jelinek wrote: I think a similar optimization would be possible for access to global variables because ld could compute the final layout of all global varia

Re: Expanding the list of "Hardened Packages"

Perhaps is not working because most of the new policy are deployed in enforcing mode and not in permissive ? But permissive not was born exactly for this ? Best 2013/4/23, Kevin Kofler : > Adam Williamson wrote: >> SELinux keeps having bugs *because* they progressively build out the >> policies.

C++ library design (was: Re: Expanding the list of "Hardened Packages")

On 05/17/2013 07:17 AM, Ben Boeckel wrote: While we're dredging up old threads ;) . On Fri, 10 May, 2013 at 12:29:16 GMT, Florian Weimer wrote: There is some fairly horrible stuff, like std::copy: You can pass a std::vector::iterator (say, the

Re: Expanding the list of "Hardened Packages"

While we're dredging up old threads ;) . On Fri, 10 May, 2013 at 12:29:16 GMT, Florian Weimer wrote: > There is some fairly horrible stuff, like std::copy: > > > > You can pass a std::vector::iterator (say, the result of begin()) as > the output it

Re: Expanding the list of "Hardened Packages"

On 04/23/2013 11:36 PM, Kevin Kofler wrote: Moving from C/C++ to a slower language is neither helpful nor necessary. If you really want full bound checking, it can be added to C/C++ rather than moving to a completely different language, and you'd still get the other benefits of C/C++, in particul

Re: Expanding the list of "Hardened Packages"

On 04/14/2013 03:34 AM, Steve Grubb wrote: -fstack-protector-all really is all. The default in Fedora is 4 bytes which would cover cases where ints and char[] are interposed as in some networking code. But more importantly, the defaul stack-protector only kicks in when the object is a char arra

Re: Expanding the list of "Hardened Packages"

Miloslav Trmač wrote: > The logical conclusion from this is to move to a language with automatic > memory management. The "top vulnerability" reports for programs written > in C/C++ and most other languages so different that starting a new project > that processes untrusted data in C/C++ is becomi

Re: Expanding the list of "Hardened Packages"

Richard W.M. Jones wrote: > We also suffer this problem in reverse: passing a pointer between two > C libraries is not possible in another non-C language. eg. Passing a > libvirt virDomainPtr from (Perl) Sys::Virt to Sys::Guestfs. Well, if the language supports sufficiently large integers and ru

Re: Expanding the list of "Hardened Packages"

On Tue, 23 Apr 2013 22:35:41 +0200 Kevin Kofler wrote: > It isn't working because it's adding hundreds of new policy bugs in > every new Fedora release. Seriously, can you please stop extrapolating from your personal usecase, and think of both the developers and actual users of the technology t

Re: Expanding the list of "Hardened Packages"

Adam Williamson wrote: > SELinux keeps having bugs *because* they progressively build out the > policies. The coverage of the -targeted policy is now greater than it > was a few releases back. If they kept the coverage of the stock policies > the same over time there would be almost no new bugs, bu

Re: Expanding the list of "Hardened Packages"

Przemek Klosowski wrote: > I agree that it's tedious, but practical evidence seems to suggest that > it's a converging process and we're almost there---'enforcing' SELinux > is a viable setting for a majority of deployments. I fail to see any kind of convergence. We still have weekly selinux-poli

Re: Expanding the list of "Hardened Packages"

Steve Grubb wrote: > On Monday, April 15, 2013 09:12:57 AM Richard W.M. Jones wrote: >> which I interpret to mean that after using -fstack-protector-all and >> removing prelink, SELinux would become obsolete because no executable >> can be exploited. > > I would say there is a place for SE Linux ev

Re: Expanding the list of "Hardened Packages"

On Tue, 16 Apr 2013 14:05:39 +0200 Florian Weimer wrote: > On 04/15/2013 08:17 PM, Miloslav Trmač wrote: > > Sure, moving away from C/C++ does not make programs > > completely secure; however, on average, C/C++ programs > > are noticeably less secure (because most vulnerabilities > > that can hap

Re: Expanding the list of "Hardened Packages"

Once upon a time, Richard W.M. Jones said: > Whatever you think. But it means you can't just write: > > $dom = Sys::Virt->get_domain_by_name ("foo"); > $g = Sys::Guestfs->create (); > $g->add_libvirt_domain ($dom); And that has nothing to do with what you said, languages being able (or no

Re: Expanding the list of "Hardened Packages"

Whatever you think. But it means you can't just write: $dom = Sys::Virt->get_domain_by_name ("foo"); $g = Sys::Guestfs->create (); $g->add_libvirt_domain ($dom); Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines.

Re: Expanding the list of "Hardened Packages"

Once upon a time, Richard W.M. Jones said: > I shouldn't say "not possible", but not very easy. A virDomainPtr in > Sys::Virt is wrapped in some object which is very specific to the > internals of Sys::Virt, thus cannot be extracted by Sys::Guestfs. It > would require Sys::Virt to have a separat

Re: Expanding the list of "Hardened Packages"

Richard W.M. Jones wrote: > On Thu, Apr 18, 2013 at 01:14:33AM +0200, Björn Persson wrote: > [...] > > > Passing pointers to objects from one language to another is likely > > > *not* possible however. > > > > Ada imports and exports C pointers just fine, including pointers to > > functions and re

Re: Expanding the list of "Hardened Packages"

On Thu, Apr 18, 2013 at 10:39:43AM -0500, Chris Adams wrote: > Once upon a time, Richard W.M. Jones said: > > We also suffer this problem in reverse: passing a pointer between two > > C libraries is not possible in another non-C language. eg. Passing a > > libvirt virDomainPtr from (Perl) Sys::V

Re: Expanding the list of "Hardened Packages"

Once upon a time, Richard W.M. Jones said: > I should have been clearer. I meant passing pointers between non-C > languages is likely not possible. Well, it depends on the language, but it is probably possible with some glue code (not necessarily practical though). For example, giving perl code

Re: Expanding the list of "Hardened Packages"

On Thu, Apr 18, 2013 at 01:14:33AM +0200, Björn Persson wrote: [...] > > Passing pointers to objects from one language to another is likely > > *not* possible however. > > Ada imports and exports C pointers just fine, including pointers to > functions and records. I should have been clearer. I m

Re: Expanding the list of "Hardened Packages"

Richard W.M. Jones wrote: > On Tue, Apr 16, 2013 at 03:12:38PM +0200, Miloslav Trmač wrote: > > On Mon, Apr 15, 2013 at 11:19 PM, Richard W.M. Jones > > wrote: > > > > > On Mon, Apr 15, 2013 at 06:48:32PM +0200, Miloslav Trmač wrote: > > > > Now, what to move to? I currently don't have see any l

Re: Expanding the list of "Hardened Packages"

On Wed, Apr 17, 2013 at 1:16 AM, Adam Williamson wrote: > On 15/04/13 09:48 AM, Miloslav Trmač wrote: > >> The logical conclusion from this is to move to a language with automatic >> memory management. The "top vulnerability" reports for programs written >> in C/C++ and most other languages so di

Re: Expanding the list of "Hardened Packages"

On 13/04/13 11:36 AM, Kevin Kofler wrote: And I would argue that this amounts to second-guessing/duplicating what the program tries to do in an unmaintainable morass of rules, which even for the targeted policy (which is not even close to covering all programs in Fedora other than as "unconfined

Re: Expanding the list of "Hardened Packages"

On 15/04/13 09:48 AM, Miloslav Trmač wrote: On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald mailto:h.rei...@thelounge.net>> wrote: which raises the question again: would it be not the better way to build the whole distribution hardened by expierience that nearly anything is exploitab

Re: Expanding the list of "Hardened Packages"

On 15/04/13 10:10 -0400, Steve Grubb wrote: > I would say there is a place for SE Linux even if we compiled everything with > "all" because FORTIFY_SOURCE coverage is not absolute. For example, about a > month ago i ran the following test: > > procs=`ls /proc | grep '^[0-9]' | sort -n` > for p i

Re: Expanding the list of "Hardened Packages"

On Tue, Apr 16, 2013 at 03:12:38PM +0200, Miloslav Trmač wrote: > On Mon, Apr 15, 2013 at 11:19 PM, Richard W.M. Jones wrote: > > > On Mon, Apr 15, 2013 at 06:48:32PM +0200, Miloslav Trmač wrote: > > > Now, what to move to? I currently don't have see any language/runtime I > > > could recommend,

Re: Expanding the list of "Hardened Packages"

On 04/15/2013 08:17 PM, Miloslav Trmač wrote: Sure, moving away from C/C++ does not make programs completely secure; however, on average, C/C++ programs are noticeably less secure (because most vulnerabilities that can happen in higher-level languages can also happen in C, but not the other way a

Re: Expanding the list of "Hardened Packages"

On Mon, Apr 15, 2013 at 11:19 PM, Richard W.M. Jones wrote: > On Mon, Apr 15, 2013 at 06:48:32PM +0200, Miloslav Trmač wrote: > > Now, what to move to? I currently don't have see any language/runtime I > > could recommend, which is in itself rather frightening. > > Ada, Eiffel, Go, Coq + OCaml, E

Re: Expanding the list of "Hardened Packages"

les wrote: > I do not believe that C or C++ are > inherently less secure than other languages, nor do I believe that there > is some statistical way of proving that fact. One can write good or bad > code in all languages. I believe you are wrong. Some languages are more secure than other language

Re: Expanding the list of "Hardened Packages"

On Mon, Apr 15, 2013 at 06:48:32PM +0200, Miloslav Trmač wrote: > Now, what to move to? I currently don't have see any language/runtime I > could recommend, which is in itself rather frightening. Ada, Eiffel, Go, Coq + OCaml, Erlang, Haskell, CompCert[*], etc. etc. All these languages are viable

Re: Expanding the list of "Hardened Packages"

> From: les >Maybe I'm wrong, but given that I won't likely be around by the time > these newer languages have become senior, I won't see my statement > refuted. You needn't wait long. Ada has been around for three some decades already. ;-) -- John Florian -- devel mailing list devel@l

Re: Expanding the list of "Hardened Packages"

On Mon, 2013-04-15 at 20:17 +0200, Miloslav Trmač wrote: > On Mon, Apr 15, 2013 at 7:40 PM, Reindl Harald > wrote: > > Am 15.04.2013 18:48, schrieb Miloslav Trmač: > > On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald > mailto:h.rei...@thelounge.net>> > wrote:

What to move to? (was: Expanding the list of "Hardened Packages")

Miloslav Trmač wrote: > The logical conclusion from this is to move to a language with automatic > memory management. The "top vulnerability" reports for programs written in > C/C++ and most other languages so different that starting a new project > that processes untrusted data in C/C++ is becomi

Re: Expanding the list of "Hardened Packages"

On Mon, Apr 15, 2013 at 7:40 PM, Reindl Harald wrote: > > Am 15.04.2013 18:48, schrieb Miloslav Trmač: > > On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald > > h.rei...@thelounge.net>> wrote: > > > > which raises the question again: > > > > would it be not the better way to build the whole

Re: Expanding the list of "Hardened Packages"

Am 15.04.2013 18:48, schrieb Miloslav Trmač: > On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald > wrote: > > which raises the question again: > > would it be not the better way to build the whole distribution hardened > by expierience that nearly anythin

Re: Expanding the list of "Hardened Packages"

On 04/13/2013 07:43 PM, Kevin Kofler wrote: Richard W.M. Jones wrote: This would be excellent, and projects in this area could make a significant contribution. I suspect that any general code-to-policy translator will hit the Halting Problem, since it seems trivial to write a program which wo

Re: Expanding the list of "Hardened Packages"

On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald wrote: > which raises the question again: > > would it be not the better way to build the whole distribution hardened > by expierience that nearly anything is exploitable over the long and > performance comes after security > The logical conclusion f

Re: Expanding the list of "Hardened Packages"

On Mon, 2013-04-15 at 09:12 +0100, Richard W.M. Jones wrote: > which I interpret to mean that after using -fstack-protector-all and > removing prelink, SELinux would become obsolete because no executable > can be exploited. No; there are plenty of exploits which aren't due to buffer overflows. Pa

Re: Expanding the list of "Hardened Packages"

On Monday, April 15, 2013 09:12:57 AM Richard W.M. Jones wrote: > which I interpret to mean that after using -fstack-protector-all and > removing prelink, SELinux would become obsolete because no executable > can be exploited. I would say there is a place for SE Linux even if we compiled everythin

Re: Expanding the list of "Hardened Packages"

On Sun, Apr 14, 2013 at 01:43:05AM +0200, Kevin Kofler wrote: > Richard W.M. Jones wrote: > > I said it "doesn't implement full bounds checking for every C object", > > and I stand by that. I doesn't cover stack objects smaller than some > > cut-off size, nor any objects in static data or on the h

Re: Expanding the list of "Hardened Packages"

On Sun, Apr 14, 2013 at 01:43:05AM +0200, Kevin Kofler wrote: > I repeat: The proper solution is to prevent executing any machine code which > is not part of the program's source code. You're simply wrong about this. It's trivial to come up with a counter-example, if you're prepared to give it a

Re: Expanding the list of "Hardened Packages"

On 04/05/13 at 04:16pm, Jakub Jelinek wrote: > On Fri, Apr 05, 2013 at 07:31:55PM +0530, Dhiru Kholia wrote: > > I repeated the benchmarks (mentioned in the above bug report) for > > Firefox 20.0 running on Fedora 18 64-bit. > > Firefox as benchmark doesn't look like a good idea (and I'm really sur

Re: Expanding the list of "Hardened Packages"

Steve Grubb wrote: > On Saturday, April 13, 2013 08:36:53 PM Kevin Kofler wrote: >> But it prevents (with probability (256^n-1)/256^n, where n is the size of >> the canary in bytes, which for n=4 is approximately .976717) >> exploiting the overflows to change the return address of any C fu

Re: Expanding the list of "Hardened Packages"

Le dimanche 14 avril 2013 à 01:43 +0200, Kevin Kofler a écrit : > Richard W.M. Jones wrote: > > This would be excellent, and projects in this area could make a > > significant contribution. I suspect that any general code-to-policy > > translator will hit the Halting Problem, since it seems trivia

Re: Expanding the list of "Hardened Packages"

On Saturday, April 13, 2013 08:36:53 PM Kevin Kofler wrote: > > (1) -fstack-protector{,-all} doesn't implement full bounds checking > > for every C object. > > But it prevents (with probability (256^n-1)/256^n, where n is the size of > the canary in bytes, which for n=4 is approximately .

Re: Expanding the list of "Hardened Packages"

On Saturday, April 13, 2013 12:28:04 PM Jerry James wrote: > > I have not run the script that checks a distribution on F19 yet, so maybe > > there are more? > > > > http://people.redhat.com/sgrubb/files/rpm-chksec > > That script reports all .o files (yes, those are sometimes packaged) > as "exec

Re: Expanding the list of "Hardened Packages"

On Saturday, April 13, 2013 08:44:44 PM Richard W.M. Jones wrote: > On Sat, Apr 13, 2013 at 08:36:53PM +0200, Kevin Kofler wrote: > > Richard W.M. Jones wrote: > > > (1) -fstack-protector{,-all} doesn't implement full bounds checking > > > for every C object. > > > > But it prevents (with probabil

Re: Expanding the list of "Hardened Packages"

Richard W.M. Jones wrote: > I said it "doesn't implement full bounds checking for every C object", > and I stand by that. I doesn't cover stack objects smaller than some > cut-off size, nor any objects in static data or on the heap at all. I never claimed it did. I said it prevents overwriting th

Re: Expanding the list of "Hardened Packages"

On Sat, Apr 13, 2013 at 08:36:53PM +0200, Kevin Kofler wrote: > Richard W.M. Jones wrote: > > (1) -fstack-protector{,-all} doesn't implement full bounds checking > > for every C object. > > But it prevents (with probability (256^n-1)/256^n, where n is the size of > the canary in bytes, which for

Re: Expanding the list of "Hardened Packages"

On Sun, Apr 14, 2013 at 12:26 AM, Dhiru Kholia wrote: > On Sat, Apr 13, 2013 at 11:16 PM, Steve Grubb wrote: >> On Saturday, April 13, 2013 12:19:42 PM Rahul Sundaram wrote: >>> Is there a tracker bug? Proven packagers can help >> >> I have a tracker bug for issues identified on the core set of

Re: Expanding the list of "Hardened Packages"

On Sat, Apr 13, 2013 at 11:16 PM, Steve Grubb wrote: > On Saturday, April 13, 2013 12:19:42 PM Rahul Sundaram wrote: >> Is there a tracker bug? Proven packagers can help > > I have a tracker bug for issues identified on the core set of packages that > would be part of a common criteria certificat

Re: Expanding the list of "Hardened Packages"

Richard W.M. Jones wrote: > (1) -fstack-protector{,-all} doesn't implement full bounds checking > for every C object. But it prevents (with probability (256^n-1)/256^n, where n is the size of the canary in bytes, which for n=4 is approximately .976717) exploiting the overflows to change

Re: Expanding the list of "Hardened Packages"

On Sat, Apr 13, 2013 at 11:46 AM, Steve Grubb wrote: > I have not run the script that checks a distribution on F19 yet, so maybe > there are more? > > http://people.redhat.com/sgrubb/files/rpm-chksec That script reports all .o files (yes, those are sometimes packaged) as "exec no no", with a red

Re: Expanding the list of "Hardened Packages"

Am 13.04.2013 19:46, schrieb Steve Grubb: > http://people.redhat.com/sgrubb/files/rpm-chksec > > To check a typical install and only get the packages that do not meet policy, > ./rpm-chksec --all | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[m|K]//g" | > egrep -w 'no|PACKAGE' > > A small sampl

Re: Expanding the list of "Hardened Packages"

On Saturday, April 13, 2013 12:19:42 PM Rahul Sundaram wrote: > On Sat, Apr 13, 2013 at 11:33 AM, Steve Grubb wrote: > > I don't think there is any need to extend the set of packages that > > _should_ > > get hardening. The current guidelines are sufficient. What is not > > happening is > > the pac

Re: Expanding the list of "Hardened Packages"

On Sat, Apr 13, 2013 at 11:33 AM, Steve Grubb wrote: > > I don't think there is any need to extend the set of packages that _should_ > get hardening. The current guidelines are sufficient. What is not > happening is > the packages that have apps that fit the need to be hardened are not > getting >

Re: Expanding the list of "Hardened Packages"

On Friday, April 12, 2013 06:44:33 AM Josh Bressers wrote: > On Thu, Apr 11, 2013 at 12:54 PM, Reindl Harald wrote: > > which is exactly the goal ASLR is desigend for > > It's designed to make certain types of attacks more difficult. It > doesn't make them impossible, just much harder. > > Here

Re: Expanding the list of "Hardened Packages"

On Wednesday, April 10, 2013 03:55:46 PM Miloslav Trmač wrote: > Hello all, > the discussion has somewhat died down... If you have a specific proposal > for a change in policy, please add it to > https://fedorahosted.org/fesco/ticket/1104 ; hard data that demonstrate the > impact, if any, in a sit

Re: Expanding the list of "Hardened Packages"

Am 12.04.2013 13:44, schrieb Josh Bressers: > On Thu, Apr 11, 2013 at 12:54 PM, Reindl Harald > wrote: >> >> which is exactly the goal ASLR is desigend for >> > > It's designed to make certain types of attacks more difficult. It > doesn't make them impossible, just much harder. > > Here is an

Re: Expanding the list of "Hardened Packages"

On Thu, Apr 11, 2013 at 7:19 PM, Richard W.M. Jones wrote: > On Thu, Apr 11, 2013 at 05:19:46PM +0200, Miloslav Trmač wrote: > > With the current setup, we get "mutating ASLR" when compiled as PIE, > > Surely ... you get "mutating ASLR" only when compiled as PIE > *and* the server process restarts

Re: Expanding the list of "Hardened Packages"

On Thu, Apr 11, 2013 at 12:54 PM, Reindl Harald wrote: > > which is exactly the goal ASLR is desigend for > It's designed to make certain types of attacks more difficult. It doesn't make them impossible, just much harder. Here is an example. When you write a security exploit, you generally have

Re: Expanding the list of "Hardened Packages"

Am 11.04.2013 19:52, schrieb Björn Persson: > Richard W.M. Jones wrote: >> On Thu, Apr 11, 2013 at 05:19:46PM +0200, Miloslav Trmač wrote: >>> With the current setup, we get "mutating ASLR" when compiled as PIE, >> >> Surely ... you get "mutating ASLR" only when compiled as PIE >> *and* the serve

Re: Expanding the list of "Hardened Packages"

Richard W.M. Jones wrote: > On Thu, Apr 11, 2013 at 05:19:46PM +0200, Miloslav Trmač wrote: > > With the current setup, we get "mutating ASLR" when compiled as PIE, > > Surely ... you get "mutating ASLR" only when compiled as PIE > *and* the server process restarts itself between each connection o

Re: Expanding the list of "Hardened Packages"

On Thu, Apr 11, 2013 at 05:19:46PM +0200, Miloslav Trmač wrote: > With the current setup, we get "mutating ASLR" when compiled as PIE, Surely ... you get "mutating ASLR" only when compiled as PIE *and* the server process restarts itself between each connection or at least on a regular basis (ie. i

Re: Expanding the list of "Hardened Packages"

On Thu, Apr 11, 2013 at 6:32 PM, John Reiser wrote: > On 04/11/2013 08:19 AM, Miloslav Trmač wrote: > > (I'll call "mutating ASLR" a setup where the addresses change frequently, > > and "static ASLR" a setup where the addresses change only sometimes > > but differ between systems.) > > > > * Serv

Re: Expanding the list of "Hardened Packages"

On 04/11/2013 08:19 AM, Miloslav Trmač wrote: > (I'll call "mutating ASLR" a setup where the addresses change frequently, > and "static ASLR" a setup where the addresses change only sometimes > but differ between systems.) > > * Servers that accept outside connections definitely should have mutati

Re: Expanding the list of "Hardened Packages"

Some more thoughts on possibly hardening more by default - comments and corrections very welcome. (I'll call "mutating ASLR" a setup where the addresses change frequently, and "static ASLR" a setup where the addresses change only sometimes but differ between systems.) * Servers that accept outsi

Re: Expanding the list of "Hardened Packages"

Hello all, the discussion has somewhat died down... If you have a specific proposal for a change in policy, please add it to https://fedorahosted.org/fesco/ticket/1104 ; hard data that demonstrate the impact, if any, in a situation relevant to Fedora (in particular, taking into account prelink as

Re: Expanding the list of "Hardened Packages"

On Fri, Apr 05, 2013 at 07:31:55PM +0530, Dhiru Kholia wrote: > On 04/04/13 at 09:26am, Steve Grubb wrote: > > On Wednesday, April 03, 2013 09:05:18 PM Josh Bressers wrote: > > > On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb wrote: > > > How much does it (PIE) slow things down? I'm fairly certain yo

Re: Expanding the list of "Hardened Packages"

On 04/04/13 at 09:26am, Steve Grubb wrote: > On Wednesday, April 03, 2013 09:05:18 PM Josh Bressers wrote: > > On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb wrote: > > How much does it (PIE) slow things down? I'm fairly certain you don't have > > any > > good data on this point. Dhiru is working ou

Re: Expanding the list of "Hardened Packages"

Am 04.04.2013 20:54, schrieb Bill Nottingham: > Jakub Jelinek (ja...@redhat.com) said: >> On Wed, Apr 03, 2013 at 01:53:27AM +0200, Reindl Harald wrote: A prelinked module reduces time spent in ld-linux, and increases sharing of pages (which reduces time spent in kernel duplicating cop

Re: Expanding the list of "Hardened Packages"

Jakub Jelinek (ja...@redhat.com) said: > On Wed, Apr 03, 2013 at 01:53:27AM +0200, Reindl Harald wrote: > > > A prelinked module reduces time spent in ld-linux, and increases sharing > > > of pages (which reduces time spent in kernel duplicating copy-on-write > > > pages.) > > > The savings are *

Re: Expanding the list of "Hardened Packages"

On Thu, Apr 04, 2013 at 10:05:31AM -0400, Matthew Miller wrote: > Well, when I brought this up four years ago, we kept it around to appease > the GCC development gods. (Or, at least, Jakub Jelinek.) (In case it wasn't clear, I didn't mean this to be a jab or sarcastic remark in any way; after havi

Re: Expanding the list of "Hardened Packages"

On Tue, Apr 02, 2013 at 05:14:21PM -0600, Stephen Smoogen wrote: > At this point I have the feeling that Prelink is a cargo cult which > we keep around to appease the Airplane Gods. Well, when I brought this up four years ago, we kept it around to appease the GCC development gods. (Or, at least, J

Re: Expanding the list of "Hardened Packages"

On Thu, Apr 04, 2013 at 09:26:34AM -0400, Steve Grubb wrote: > Last week I was looking at nspr and wondering why fortify_source was not > getting used and found that it wrapped functions for "portability". For > example, it has PL_strcpy which only wraps strcpy. The problem is the size > informa

Re: Expanding the list of "Hardened Packages"

On Wednesday, April 03, 2013 09:05:18 PM Josh Bressers wrote: > On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb wrote: > > On Wednesday, April 03, 2013 01:48:17 PM Miloslav Trmač wrote: > > > On Tue, Apr 2, 2013 at 9:57 PM, Steve Grubb wrote: > > > > On Saturday, March 30, 2013 08:54:30 AM Dhiru Khol

Re: Expanding the list of "Hardened Packages"

On Thu, Apr 04, 2013 at 10:59:41AM +0200, Florian Weimer wrote: > On 04/04/2013 10:42 AM, Jakub Jelinek wrote: > >>I think a similar optimization would be possible for access to > >>global variables because ld could compute the final layout of all > >>global variables in the binary itself, just as

Re: Expanding the list of "Hardened Packages"

On 04/04/2013 10:42 AM, Jakub Jelinek wrote: I think a similar optimization would be possible for access to global variables because ld could compute the final layout of all global variables in the binary itself, just as in the non-PIE case. Nope. The thing is, depending on if the variable is

Re: Expanding the list of "Hardened Packages"

On Thu, Apr 04, 2013 at 10:27:31AM +0200, Florian Weimer wrote: > On 04/04/2013 09:47 AM, Jakub Jelinek wrote: > >On Thu, Apr 04, 2013 at 09:39:18AM +0200, Paolo Bonzini wrote: > >>>I'm willing to agree that PIE on x86 is going to be very slow due to > >>>register pressure. > >> > >>Yes, but not on

Re: Expanding the list of "Hardened Packages"

On 04/04/2013 09:47 AM, Jakub Jelinek wrote: On Thu, Apr 04, 2013 at 09:39:18AM +0200, Paolo Bonzini wrote: I'm willing to agree that PIE on x86 is going to be very slow due to register pressure. Yes, but not on x86-64 which has %rip-relative addressing. It is probably a wash there. On x86_

Re: Expanding the list of "Hardened Packages"

On Thu, Apr 04, 2013 at 09:39:18AM +0200, Paolo Bonzini wrote: > > I'm willing to agree that PIE on x86 is going to be very slow due to > > register pressure. > > Yes, but not on x86-64 which has %rip-relative addressing. It is > probably a wash there. It isn't, while the register pressure doesn

Re: Expanding the list of "Hardened Packages"

Il 04/04/2013 04:05, Josh Bressers ha scritto: > > > > On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb > wrote: > > On Wednesday, April 03, 2013 01:48:17 PM Miloslav Trmač wrote: > > On Tue, Apr 2, 2013 at 9:57 PM, Steve Grubb > wrot

Re: Expanding the list of "Hardened Packages"

Il 29/03/2013 23:10, Richard W.M. Jones ha scritto: >> > >> > Qemu is surely a good candidate for this. Although it's not network- >> > accessible, it is accessible from the guests that it runs via its huge >> > and ill-specified surface of emulated devices. > I'm running my own modified qemu pac

Re: Expanding the list of "Hardened Packages"

On 04/02/13 at 03:04pm, Richard W.M. Jones wrote: > On Tue, Apr 02, 2013 at 07:15:29PM +0530, Dhiru Kholia wrote: > > http://dl.dropbox.com/u/1522424/probable-violations-F19.csv > > FWIW, the following command produces much better output: > > > > like this: > > Package: autodir (autodir-0.99.9-1

Re: Expanding the list of "Hardened Packages"

On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb wrote: > On Wednesday, April 03, 2013 01:48:17 PM Miloslav Trmač wrote: > > On Tue, Apr 2, 2013 at 9:57 PM, Steve Grubb wrote: > > > On Saturday, March 30, 2013 08:54:30 AM Dhiru Kholia wrote: > > > > "_hardened_build" rpm spec macro can be used to har

Re: Expanding the list of "Hardened Packages"

On Wednesday, April 03, 2013 01:48:17 PM Miloslav Trmač wrote: > On Tue, Apr 2, 2013 at 9:57 PM, Steve Grubb wrote: > > On Saturday, March 30, 2013 08:54:30 AM Dhiru Kholia wrote: > > > "_hardened_build" rpm spec macro can be used to harden a package. > > > > > > For an example, see > > > http://

Re: Expanding the list of "Hardened Packages"

On 04/03/2013 05:38 AM, Tom Lane wrote: > A different issue that worries me about PIE is the impact on the > available address space in 32-bit builds A test program says that the unused space is bounded by 1MiB per module (main program or shared library) and in a 32-bit environment the placement i

Re: Expanding the list of "Hardened Packages"

On Wed, Apr 3, 2013 at 5:19 PM, Paul Wouters wrote: > To me, prelink is still evil for breaking FIPS. I've requested a few times > that prelink plays nicer with FIPS mode, like running prelink -ua during > bootup when FIPS mode is on. https://bugzilla.redhat.com/show_bug.cgi?id=923782 should re

Re: Expanding the list of "Hardened Packages"

> This proposal was originally at https://fedorahosted.org/fesco/ticket/1104 > http://fedoraproject.org/wiki/Hardened_Packages page mentions > that "FESCo requires some packages to use PIE and relro hardening by > default." "Position independent executables" use a weak form of ASLR on Fedora-19-

Re: Expanding the list of "Hardened Packages"

Am 03.04.2013 01:59, schrieb Kevin Fenzi: > On Tue, 02 Apr 2013 16:50:33 -0700 > John Reiser wrote: > >>> It does rather seem like we should consider just killing it >>> [prelink], at least by default. >> >> Prelinking shortens the time between execve() and first useful output. >> A prelinked m

Re: Expanding the list of "Hardened Packages"

On Wed, 3 Apr 2013, Miloslav Trmač wrote: On Wed, Apr 3, 2013 at 12:18 AM, Adam Williamson wrote: On 31/03/13 08:11 AM, Richard W.M. Jones wrote: However prelink does reduce the effectiveness of ASLR (a bit).  See http://lwn.net/Articles/341440/ and follow-up conv

Re: Expanding the list of "Hardened Packages"

Jakub Jelinek writes: > If you don't care about the speed of execution of any programs, just compile > everything with -fsanitize=address (that will be only ~ 2x slowdown or so). A different issue that worries me about PIE is the impact on the available address space in 32-bit builds. For instan

Re: Expanding the list of "Hardened Packages"

On Tue, Apr 2, 2013 at 9:57 PM, Steve Grubb wrote: > On Saturday, March 30, 2013 08:54:30 AM Dhiru Kholia wrote: > > "_hardened_build" rpm spec macro can be used to harden a package. > > > > For an example, see > > http://pkgs.fedoraproject.org/cgit/clamav.git/tree/clamav.spec > > This flag is ov

Re: Expanding the list of "Hardened Packages"

On Wed, Apr 3, 2013 at 12:18 AM, Adam Williamson wrote: > On 31/03/13 08:11 AM, Richard W.M. Jones wrote: > > However prelink does reduce the effectiveness of ASLR (a bit). See >> http://lwn.net/Articles/**341440/ and >> follow-up conversation. >> > > Ignoring t

Re: Expanding the list of "Hardened Packages"

On Wed, Apr 03, 2013 at 01:53:27AM +0200, Reindl Harald wrote: > > A prelinked module reduces time spent in ld-linux, and increases sharing > > of pages (which reduces time spent in kernel duplicating copy-on-write > > pages.) > > The savings are *visible* when invoking an interactive GUI program

Re: Expanding the list of "Hardened Packages"

Am 03.04.2013 01:50, schrieb John Reiser: >> It does rather seem like we should consider just killing it [prelink], at >> least by default. > > Prelinking shortens the time between execve() and first useful output in theory > A prelinked module reduces time spent in ld-linux, and increases shar

Re: Expanding the list of "Hardened Packages"

On Tue, 02 Apr 2013 16:50:33 -0700 John Reiser wrote: > > It does rather seem like we should consider just killing it > > [prelink], at least by default. > > Prelinking shortens the time between execve() and first useful output. > A prelinked module reduces time spent in ld-linux, and increases

Re: Expanding the list of "Hardened Packages"

> It does rather seem like we should consider just killing it [prelink], at > least by default. Prelinking shortens the time between execve() and first useful output. A prelinked module reduces time spent in ld-linux, and increases sharing of pages (which reduces time spent in kernel duplicating

Re: Expanding the list of "Hardened Packages"

On Tue, 2 Apr 2013, Adam Williamson wrote: Date: Tue, 02 Apr 2013 15:18:55 -0700 From: Adam Williamson Reply-To: Development discussions related to Fedora To: devel@lists.fedoraproject.org Subject: Re: Expanding the list of "Hardened Packages" On 31/03/13 08:11 AM, Richard

Re: Expanding the list of "Hardened Packages"

Am 03.04.2013 00:18, schrieb Adam Williamson: > On 31/03/13 08:11 AM, Richard W.M. Jones wrote: > >> However prelink does reduce the effectiveness of ASLR (a bit). See >> http://lwn.net/Articles/341440/ and follow-up conversation. > > Ignoring the silly stuff, it does seem that this is Yet Ano

  1   2   >