[Secure Coding] master: C Language: Mention mixed signed/unsigned comparisons (ace93c0)
by fweimer＠fedoraproject.org
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
9 years, 7 months
scap-security-guide now available in Fedora updates-testing repository
by Jan Lieskovsky
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.
9 years, 7 months
Inheritable file system capabilities
by Florian Weimer
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
9 years, 7 months
prelink performance gains
by Dhiru Kholia
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
9 years, 7 months
leaving setfcap in docker containers
by Matthew Miller
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>
9 years, 7 months
Re: F19 Firewall
by Lance Lassetter
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
9 years, 8 months
Re: F19 Firewall
by Lance Lassetter
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
9 years, 8 months
Emergency destruction of LUKS partition
by Eric Christensen
-----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-----
9 years, 8 months
