security October 2013

security@lists.fedoraproject.org

15 participants
8 discussions

[Secure Coding] master: C Language: Mention mixed signed/unsigned comparisons (ace93c0)
by fweimer＠fedoraproject.org 30 Oct '13

30 Oct '13

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git On branch : master >--------------------------------------------------------------- commit ace93c0dd61b3da84e8bf78e1fc50f4426ff5c55 Author: Florian Weimer <fweimer(a)redhat.com> Date: Wed Oct 30 20:42:26 2013 +0100 C Language: Mention mixed signed/unsigned comparisons >--------------------------------------------------------------- defensive-coding/en-US/C-Language.xml | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/defensive-coding/en-US/C-Language.xml b/defensive-coding/en-US/C-Language.xml index b039ed2..f50e36c 100644 --- a/defensive-coding/en-US/C-Language.xml +++ b/defensive-coding/en-US/C-Language.xml @@ -141,6 +141,20 @@ lot when implementing overflow checks. </para> <para> + Sometimes, it is necessary to compare unsigned and signed + integer variables. This results in a compiler warning, + <emphasis>comparison between signed and unsigned integer + expressions</emphasis>, because the comparison often gives + unexpected results for negative values. When adding a cast, + make sure that negative values are covered properly. If the + bound is unsigned and the checked quantity is signed, you should + cast the checked quantity to an unsigned type as least as wide + as either operand type. As a result, negative values will fail + the bounds check. (You can still check for negative values + separately for clarity, and the compiler will optimize away this + redundant check.) + </para> + <para> Legacy code should be compiled with the <option>-fwrapv</option> GCC option. As a result, GCC will provide 2's complement semantics for integer arithmetic, including defined behavior on

1 0

scap-security-guide now available in Fedora updates-testing repository
by Jan Lieskovsky 23 Oct '13

23 Oct '13

Hello guys, this is a heads-up / notification that scap-security-rpm (AKA SCAP content for Fedora) is now available in updates-testing [*] repository for both of Fedora 18 and Fedora 19 (scap-security-guide-0.1-3.fc18 vs scap-security-guide-0.1-3.fc19). If you are running Fedora 20 Alpha yet, you can install scap-security-guide-0.1-3.fc20 directly from Koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=472985 Regarding the content - there isn't much content / rules yet. But it will improve since from now I can focus more on the content itself, than on the RPM building infrastructure issues. Feel free to test it (have a look at scap-security-guide(8) man page to see how it's expected to be run), and report noticed bugs / RFEs for future improvements. Also feel free to actively participate on contributing the SCAP content / rules. Either by submitting patches directly to upstream: [1] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide [2] https://fedorahosted.org/scap-security-guide/wiki/becomeadeveloper or indirectly via Red Hat Bugzilla functionality. Questions / comments / patches / proposals welcome. Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team [*] Install normally via yum with fedora-updates-testing.repo enabled.

1 0

Inheritable file system capabilities
by Florian Weimer 23 Oct '13

23 Oct '13

We've been looking at file system capabilities recently. I noticed this particular instance in Fedora: wireshark,/usr/sbin/dumpcap,"= cap_net_admin,cap_net_raw+eip" If I understand things correctly, the "i" part is unnecessary because dumpcap doesn't spawn other programs (unless exploited, that is). So making these capabilities non-inheritable makes sense to me. Comments? -- Florian Weimer / Red Hat Product Security Team

1 1

prelink performance gains
by Dhiru Kholia 14 Oct '13

14 Oct '13

Hi, During the development of "unSPEC" [1] benchmarking suite, I made some interesting observations regarding prelink. - Here are some measurements (for LibreOffice [2] loading time in seconds) done using the "unSPEC" bench-marking suite. These numbers are repeatable and you are encouraged to try "unSPEC" to do independent validation of these numbers. - hkario (modern SSD based system, cache flushed): (1.816, 1.811, 1.797, 1.827 with prelink), (2.034, 2.042, 2.027, 2.016 without prelink) - hkario (modern SSD based system, cache intact): (2.155, 2.121, 2.101, 2.299 with prelink), (2.311, 2.052, 2.047, 2.037 without prelink) - halfie (T430s): (10.725, 10.095, 10.378, 10.568 with prelink), (8.901, 8.993, 9.075, 9.448, 9.489 without prelink) - danpb (T530): I see basically no measurable difference in times with or without prelink - quite a lot of variation, but all in same ballpark, (8.374, 7.849, 8.457, 7.673, 7.608, 8.031, 8.350, 8.183, 7.381 with prelink), (7.366, 8.009, 7.500, 7.949, 8.208, 8.351, 7.849, without prelink). - For building kernels (using the "kernel-bench" [3] component of unSPEC suite), prelink saved <= 250 ms over the non-prelink environment (which took 1m19.138s). hkario even reports worse performance numbers for the prelink environment. Additionally, we have specialized softwares like ccache and distcc to solve long-compilation-time problems. In short, we could not distinguish the performance gains of prelink over the "background noise" in many (or even most) cases. So, I was wondering if you are aware of any use-cases where prelink provides measurable benefits. It would be awesome if you could run unSPEC on your systems and report back the numbers. unSPEC is easy to use and doesn't take much time (or steps) to run. For more information, please see the following links. References: [1] https://github.com/kholia/unSPEC [2] https://github.com/kholia/unSPEC/tree/master/LibreOffice [3] https://github.com/kholia/unSPEC/tree/master/kernel-bench -- Dhiru

3 4

leaving setfcap in docker containers
by Matthew Miller 07 Oct '13

07 Oct '13

Quick backstory: unless run in privledged mode, Docker drops a bunch of capabilities when launching a container. One of these is setfcap. This breaks of binary RPMs like httpd where the daemon is installed with file capabilities instead. We're considering removing setfcap from the list of dropped capabilities. It seems safe to me (note that you run as root inside the container), but I'd like some security-minded review. Could this be used for evil? https://bugzilla.redhat.com/show_bug.cgi?id=1012952 Thanks! -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

6 17

Re: F19 Firewall
by Lance Lassetter 03 Oct '13

03 Oct '13

Firewalld is just not workable enough for me. For instance I need to have quirky netfilter rules to make my squid proxy setup to work properly. There is no easy way to do this with firewalld. Also I set up an iptables queue so that netfilter supports suricata ips mode. This also, no easy way... Netfilter is just so diverse and firewalld seems to strip a lot of that diversity away. What about the idea that people who want to write their own iptables custom scripts that can be, after wiriting the script and implementening it, a smart way for the script to be imported...the whole script, into firewalld. Last I tried, my nat rules weren't compatible with firewalld. Like maybe a simpe iptables-save then a firewalld-save or the like. Then maybe ask if to import it into firewalld's 'home', 'work', 'public', etc. Lance Kurt Seifried <kseifried(a)redhat.com> wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Some random thoughts: > >1) it would be nice to have capabilities like "do you want to let >program X talk to the internet/receive connections" for client >software with a GUI notification (like basically all the windows >client/Mac OS X client firewall stuff). I would say this is probably >the biggest capability needed for normal end users. > >2) Tying firewall into networking detection, e.g. windows "is this >your home/business/public network" and then remembering it (I assume >IP/Mac address of default gateway would be a reasonably good way to >identify networks). > >3) Make it easy to modify policy, e.g. in section 1) if you choose to >block/deny something and realize that was the wrong decision how do >you go in an modify it? In Windows this is a PITA for normal users. > >Overall I'm not really sure firewalld solves much, anyone running a >server will probably be able to tweak iptables to allow incoming >services they want. So do we aim it at the end user/workstation style >usage primarily (especially ones that move around networks)? > >- -- >Kurt Seifried Red Hat Security Response Team (SRT) >PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.14 (GNU/Linux) > >iQIcBAEBAgAGBQJSQdXYAAoJEBYNRVNeJnmTC6wQAIW3HNlAqfSkMSZqbFG6kbj/ >GOlnzjJOrUzt/LWwOGPCTmg/GgSOHrT4t1gT1577sL2LM5wPGCF/oll84RehiZd8 >PXNiyq3QnsOJFLjmEbm1YfGpDGae5+uR4IR3Bm1MVHBjvquhlqaje0b1yI2gs8Do >LY9sXeGmYh+YjKIUDJrOCCS/I/xE8Zl4D+aU/s1BumV9LxwsOURTzXv5x32C8zwS >5MH5rvX9LO5vJn0VMByRsoXrCSybyLnRmsDvAH9yYx+WjforKsU4wq2QVLYDtjU/ >0TO/n7qP1WO7doixYLymxwm+Fnk8J7HGa2t/2of2ZvX2AB3eRLmzj+tKzKohZR4H >jxCLImHLx/puPr6VA/4ENSrHltCCbTSDvlZGxTHAeHwszmQzYMXZ8Qv/leRf4ThO >E3wvuoIpgUWSEbE8RjVmXjX/Cd1GYz6ns35ydy2kZgHr4AfQifF+hdWHPP63/hrJ >C21iZylvIMJKF2cWOXwR4X+Zr9tDthf+UDeEE3J/uQAfj3LDvjdHXqd0xcgOSrae >nP0hPHj0apZrzY0zJfcn3JNipRDDl3qNgs8Q8tFAut5WvubCdLlVFXvLWMs6mOA2 >6TmN4ZzEh0zfeGLq+LZ1kAY0ZsIds9ziyKsxAPGlTQz3Ax9rjb40BOwClHc4wbOF >6DzOg7WN87fRSO/wCTy3 >=dDnL >-----END PGP SIGNATURE----- >-- >security mailing list >security(a)lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/security

4 9

Re: F19 Firewall
by Lance Lassetter 03 Oct '13

03 Oct '13

Has firewall.state been shipped yet? Jiri Popelka <jpopelka(a)redhat.com> wrote: >On 09/30/2013 05:42 PM, Jiri Popelka wrote: >> <direct> >> [ <rule ipv="ipv4" table="filter" chain="FORWARD_direct" >> priority="0"> -m mark ! --mark 1/1 -j NFQUEUE </rule> ] > >Without the [ and ] (no idea how it got there). > >So once again: > ><?xml version="1.0" encoding="utf-8"?> ><direct> > <rule ipv="ipv4" table="filter" chain="FORWARD_direct" priority="0"> >-m mark ! --mark 1/1 -j NFQUEUE </rule> > <rule ipv="ipv4" table="nat" chain="PREROUTING_direct" priority="0"> >-p tcp --dport 80 -j DNAT --to 192.168.1.2:3129 </rule> > <rule ipv="ipv4" table="nat" chain="OUTPUT_direct" priority="0"> >-p tcp --dport 80 -m owner --gid-owner squid -j ACCEPT </rule> > <rule ipv="ipv4" table="nat" chain="OUTPUT_direct" priority="1"> >-p tcp --dport 80 -m owner --uid-owner squid -j ACCEPT </rule> > <rule ipv="ipv4" table="nat" chain="OUTPUT_direct" priority="2"> >-p tcp --dport 3129 -m owner --uid-owner squid -j ACCEPT </rule> > <rule ipv="ipv4" table="nat" chain="OUTPUT_direct" priority="3"> >-p tcp --dport 80 -j REDIRECT --to-ports 3129 </rule> ></direct> > >-- >Jiri > >-- >security mailing list >security(a)lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/security

1 0

Emergency destruction of LUKS partition
by Eric Christensen 01 Oct '13

01 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Someone asked me about this recently and I haven't had a chance to fully wrap my head around the solution but thought it was an interesting scenario. Background: Someone knows you have encrypted your computer using LUKS. They convince you to enter (or otherwise provide) your passphrase via the large wrench method[0]. Realcrypt method: There is plausible deniability (if properly implemented) whereas you could provide the person with the alternate passphrase which would give them access to a portion of the encrypted partition but not your real working partition. LUKS: There is no way to provide plausible deniability. Proposed solution: LUKS provides four key slots to use for decrypting a partition. How about have one key slot that when used immediately implements a deletion of the encrypted partition (or at least the key record). Thoughts? [0] http://www.xkcd.org/538/ - -- Eric - -------------------------------------------------- Eric "Sparks" Christensen Fedora Project sparks(a)fedoraproject.org - sparks(a)redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGcBAEBCgAGBQJSSaw6AAoJEB/kgVGp2CYvDTAL/jeuWo8r39Apq7QA6hQKmDI9 Oe+GB5SRk99ecqmBKcapC6nGewfVajoeuNo27AG9CfmQ97ZSk6Oabvt8OibgXXc5 S64me8zy+Rqx2uu8i271P8DGbf3IFENMMtCdkPCfJWNU5ZAepGwBXCQXRJwC09jn MWeQ9kDFmvHZE4a8bO/G6ZPkXI+Vm7BxJYsGq6f5SVcAnqWdKWSUiZPfEcAIGPzx AFDmiR8wQpQ2e3PiHEstLYK9DHr6ALIqZxbdwwlLM/vOi7N2Xk3PobIby3KREU4b yCh5lkp2oZKkWhGY2AYgFwm1uo7/jWSDFArcJDTtr9amU1mihrpmRPBxAzcplSFK oj9LJeYXXnpGFRHNyr68Zp8Dp5ckhDgUVMV1m8MCgVgmyn7cIexIvib4kng/c/aE Wo/32VXw8T/++Gszlv4AjLKjMlD4PEVWSO9saJLeQIlwEQFZYulpVkRa/6RKesYZ NbuMocam5uk2z0BeXCXjD5A1nvh7YHnhuCjv4HizqQ== =Tdc5 -----END PGP SIGNATURE-----

10 11

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

security October 2013