Hi,
I recently noticed that several packages in Fedora create RSA keys with
inappropriate key sizes:
dnssec-trigger creates RSA 1536 keys with certificate that is valid for
20 years:
https://bugzilla.redhat.com/show_bug.cgi?id=1045689
dropbear-keygen creates by default RSA 1024 keys:
https://bugzilla.redhat.com/show_bug.cgi?id=1039311
Some other observations:
ssh-keygen on F19 creates RSA 2048 keys by default
ENISA recommends to at least RSA 3072 keys:
http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverabl…
If e.g. AES-256 is used. RSA 15360 is recommended for long-term usage.
Therefore I would like to propose a packaging guideline about which
minimum key size software in Fedora should generate by default. It seems
to me that requiring RSA 3072 key by default in Fedora is a good initial
compromise. I did not notice RSA keys with more than 4096 bits
regularly, therefore I am not sure whether using RSA 15360 keys by
default is a good idea.
What is your opinion?
Regards
Till
Shortish version:
On Fedora devel@, a concern has been raised regarding binaries with vulnerablities being persistently available via Btrfs snapshots in the normal file system hierarchy. This is a request for assessing the significance of this concern, and how to mitigate it. Therefore the context is rootfs on Btrfs.
The first email bringing up the concern is here:
https://lists.fedoraproject.org/pipermail/devel/2014-January/194558.html
And a possible work around proposed here:
https://lists.fedoraproject.org/pipermail/devel/2014-January/194620.html
How significant is the risk of stale binaries being persistently available in the normal file system hierarchy? Should something be done to either make sure they aren't persistently available (make sure they aren't available in the mounted file system hierarchy), and if they're mounted should noexec or nosuid be used?
Slightly longer version:
Other distros install to Btrfs the way they do any other file system. This means any snapshots are available via the mounted top level of the file system.
Fedora on the other hand has a different layout, with a subvolume named root in the top level of the file system. Inside this subvolume is the tree you'd normally find as rootfs. Instead of the top level file system being mounted, the root subvolume is mounted at /. This means it's possible to "hide" snapshots in the unmounted top level of the file system; or nested within a subvolume called snapshots, for example.
Presently, the optional yum-plugin-fs-snapshot creates snapshots of subvolumes prior to updates, and places the snapshots in the parent subvolume. (Since snapshotting subvolumes isn't recursive, the snapshots themselves aren't snapshot.) For example:
#btrfs subvolume list /
ID 256 gen 352 top level 5 path root
ID 257 gen 352 top level 5 path home
ID 266 gen 95 top level 256 path yum_20140212183241
ID 267 gen 97 top level 5 path home/yum_20140212183242
Because the snapshot is located within a mounted subvolume, it makes the snapshot's stale binaries persistently available. So restating the earlier question, is this a security risk, how significant is it, and is it worth changing the behavior? Instead, these yum snapshots could be placed in a subvolume at the top level of the file system, which isn't mounted by default. The other question is whether there's a meaningful distinction between persistently mounting this snapshots subvolume, or only mounting it on demand when snapshots are about to be taken? And then when it's mounted, should the mount option be noexec or nosuid.
For what it's worth, the questions use this yum plug in as an example, but I'm uncertain if a future snapshot/rollback strategy will actually use it, or snapper, or some other utility entirely.
Rollbacks and logs:
Another thing that comes to mind, is the possibility of doing a rollback on the system. The yum snapshot plugin doesn't automatically do, or aid the user in doing rollbacks. Optional package snapper can.
Setting aside, for the moment, the granularity needed to properly do such rollbacks with file system snapshots, I'm wondering about logging behavior from a security perspective. It seems pretty clear to me we'd want a single persistent audit log kept, regardless of which snapshot is booted.
Some of the questions I have are, what logs shouldn't be rolled back? Maybe none should be? And is there a use case for snapshotting, for example /var/log, but simply not rolling it back. For what it's worth, Btrfs supports read only snapshots. They're not writable even by root, and even if they're mounted with a rw option. The snapshot also contains a UUID, as well as its parent's UUID. So, I don't know, maybe there's some benefit to the audit daemon tracking this information in a persistent log that we simply never rollback, even if it's being snapshot.
A part of the dialog I hope this generates is not only what we should be doing, but also how important it is to do it, as it might affect how anaconda creates its layouts for different Fedora.next products. Do any of the questions or concerns (and unasked questions of course) have different answers depending on whether the context is workstation, server, or cloud?
Thanks,
Chris Murphy
Chris Murphy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
On 02/08/2014 12:11 PM, updates(a)fedoraproject.org wrote:
> The following Fedora 20 Security updates need testing: Age URL 74
> https://admin.fedoraproject.org/updates/FEDORA-2013-22130/chicken-4.8.0.5-1…
This
>
security update here is worrying -- there was an earlier update
that fixed the issue (4.8.0.4-4) and was pushed for all other releases
*but* F20. 4.8.0.5-1 is then pushed to Bodhi which means it obsoleted
the previous update but it has been sitting there for over two months.
The update seems to work fine, so could the update submitter
(codeblock) push it? Alternatively it needs another +1 from anyone to
get it pushed.
Best regards,
- --
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: A36A937A
Jabber: hircus(a)jabber.ccc.de | IRC: michel-slm(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJS9iokAAoJEEr1VKujapN6a2AH/3OOBrgFgy2g4zW1pZD/Lwm2
YgCB2z96WQnE0evzPXrBnUYqwmdQsXVGtPbuKmnvC29ajzWRRKsd7/KokfWtyfmV
QTfWWc0TwI3fpXKiKHr6jdOodvM6QrFYZGBBySUKWVqZ+P8/MMk4v9OVtL9EvKK3
YTTaDFW8xPwz/BUMgOCb3g55tgkc+DaJFy26M7m5ufJ7KzHv+bIdBtRPyaYmtHoK
pk6NkMlCbta5bJ0z+BAj/9xBRY7nDGaWfdJy3oQGyoU3LMl3vFN/9GLVoGakzst3
t3KhqhEwThRdWa9xUtqoAKMisIaSfOyhUW0LFrwKTZA62maHO6DlAOYRbEEmGsM=
=u/XJ
-----END PGP SIGNATURE-----
