Repository : http://git.fedorahosted.org/git/?p=secure-coding.git
On branch : master
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
@@ -141,6 +141,20 @@
lot when implementing overflow checks.
+ 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.)
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
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
If you are running Fedora 20 Alpha yet, you can install
scap-security-guide-0.1-3.fc20 directly from Koji:
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
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:
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.
We've been looking at file system capabilities recently.
I noticed this particular instance in Fedora:
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.
Florian Weimer / Red Hat Product Security Team
During the development of "unSPEC"  benchmarking suite, I made some
interesting observations regarding prelink.
- Here are some measurements (for LibreOffice  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
- 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
- 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"  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
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.
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
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?
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
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.
Kurt Seifried <kseifried(a)redhat.com> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>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
>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)
>-----END PGP SIGNATURE-----
>security mailing list
-----BEGIN PGP SIGNED MESSAGE-----
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.
Someone knows you have encrypted your computer using LUKS. They convince you to enter (or otherwise provide) your passphrase via the large wrench 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.
There is no way to provide plausible deniability.
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).
- -- Eric
Eric "Sparks" Christensen
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)
-----END PGP SIGNATURE-----