Hi,
First some background:
Anaconda 22.17+ has started to enforce the following:
+- Don't allow weak LUKS passwords either (bcl)
+- Don't allow weak passwords (text mode). (sbueno+anaconda)
+- Remove the press done twice to exit text (bcl)
+- Don't allow weak user passwords (bcl)
test@ list 1st announcement of change, and the ensuing 91 (and
counting) email thread which you're welcome to skip as I'll attempt to
cover the salient points in this email:
https://lists.fedoraproject.org/pipermail/test/2015-January/124827.html
The impetus behind the change are the two scope bullets in this rejected change:
https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
A FESCO ticket has been opened asking for review:
https://fedorahosted.org/fesco/ticket/1412
And then some points:
- I think it'll make users angry. The test@ list is overwhelmingly
against the change, and I expect they're more tolerant and
understanding compared to the wider community.
- On Windows and OS X server variants, remote access (in-bound)
services are disabled by default. It's expected to use an OOB method
to initially connect to a server (or even VM) and enable the desired
services.
- libpwquality is what's being used to "grade" the quality of the
passwords used in anaconda. This has been referred to as having
capricious behavior in the test@ thread. In a 2 day old build of
boot.iso which contains the current version of libpwquality and
anaconda 22.17, I'm finding the following:
The gibberish password that an infamous xkcd comic strip railed against
# pwscore
Tr0ub4dor&3
67 ##anaconda=good
8 actually random lowercase latin characters.
# pwscore
liampres
4
# pwscore
amptiato
4
# pwscore
tempeadj
1
# pwscore
clungerm
1
8 random characters mixed case, numbers, specials.
# pwscore
CHYtU$W3
27
# pwscore
ja#P2etw
27
# pwscore
6*T!MsjD
21
Portions of widely published phrases, lowercase latin characters.
# pwscore
correcthorse
41 ##anaconda=fair
# pwscore
batterystaple
55
# pwscore
correcthorsebatterystaple
100
# pwscore
onceuponatimetherewasa
100
# pwscore
itwasthebestoftimes
100
# pwscore
lookbeforeyouleap
90
# pwscore
dropdeadgorgeous
75
I don't have an easy way to prove this, but in a millions+ attempt
brute force attack, I find it difficult to believe that
correcthorsebatterystaple is not attempted, but 6*T!MsjD is attempted.
I had recently read that up to 100 character dictionary only word
based passwords were routinely attempted in brute force attacks.
I think the change improperly shifts burden to all users without
respect to their use case, in a manner inconsistent with the device
control they've come to expect: no password requirements at all on
mobile devices, and very minimalist ones on Windows and OS X. I don't
see how being an outliar in this area, even among Linux distros,
helps.
Conclusion: I think the concerning services need to be disabled by
default, and use OOB management to enable those services, since it's a
long standing practice elsewhere. If we can do better than this, fine,
but not by shifting the security burden.
Thanks,
--
Chris Murphy
I mentioned this before but I figured a reminder might be appreciated.
:)
----- Forwarded message from David Millar <david.millar(a)bc.edu> -----
> Date: Thu, 5 Feb 2015 17:46:29 -0500
> From: David Millar <david.millar(a)bc.edu>
> To: security-camp(a)mit.edu
> Subject: [security-camp] Registration Open: Winter 2015 Security Camp at
> Boston College
>
> Hello! We are pleased to invite you to Winter, 2015 Security Camp @
> Boston College. This event is a unique opportunity for security
> professionals at area schools responsible for networks and computer
> systems to assemble and to exchange knowledge, insights, and
> solutions.
>
> Security Camp will again be held in Higgins Hall at Boston College, on
> Thursday, March 5, 2015. It will run from 9:00 a.m. - 4:45 p.m., with
> check-in beginning at 8:30 a.m. Our make up date in case of snow is
> Friday, March 6, 2015.
>
> All who are interested in the topics being presented are encouraged to
> attend. The goal of Boston College's Security Camp is to target the
> interests and needs of our community of professionals working in an
> academic environment. Every effort has been made to enlist a diverse
> group of computer security experts including those who can uniquely
> contribute to security discussions. Your presence will help promote a
> rich experience and successful 2015 camp!
>
> Featured topics for this year include:
> -Identity Management
> -Managing Nessus vulnerability scanning programs - panel discussion
> -Mitigating distributed denial of service attacks
> -Data breach insurance
> -Docker - open platform secure application sandbox runtime and packaging
>
> For full details and registration information, visit:
> http://www.bc.edu/securitycamp
>
> Please register as soon as possible as space is limited. Registration
> ends on Sunday, March 1st.
>
> We look forward to you joining us at Boston College on March 5!
>
> David Millar
> Security Camp Administrator
> Boston College
> _______________________________________________
> security-camp mailing list
> security-camp(a)mit.edu
> https://mailman.mit.edu/mailman/listinfo/security-camp
>
----- End forwarded message -----
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
There have been many bugs filed against apps using crypto libraries to
update them to use the system crypto policy by default. I'm currently
looking at how to address the one filed against GTK-VNC
https://bugzilla.redhat.com/show_bug.cgi?id=1179301
The current GTK-VNC code sets the priority conditionally depending on
wht VNC auth mech chosen earlier:
gnutls_priority_set_direct(priv->tls_session,
anonDH ? "NORMAL" : "NORMAL:+ANON-DH",
NULL)
So I can't just use gnutls_set_default_priority(), unless there's a way
to ask for "+ANON-DH" separately afterwards ?
At first I thought I could just replace "NORMAL" with "@SYSTEM". Looking
at the GNUTLS upstream code though, the "@SYSTEM" string is only ever
defined in the external crypto policy file and GNUTLS does not appear to
install any such file by default. So I can't use "@SYSTEM" unconditionally
when building against newer gnutls versions, as I can't rely on it existing
even ifi gnutls is new enough.
So it seems like either these crypto policy changes require apps to carry
Fedora/RHEL specific patches, or to pass in the default crypto policy
name as a configure arg perhaps & rely on distro maintainers to set it
when needed (eg ./configure --crypto-policy=@SYSTEM).
Anyone have any better suggestions for cleanly supporting the new system
crypto policies in upstream apps while maintaining compat across distros
and old gnutls versions, assunming gnutls_set_default_priority is out of
the question?
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Saturday, February 07, 2015 10:15:17 AM you wrote:
> I have just tested it ... it works just fine here with the 3.18 kernel.
Are you using Android Studio or Eclipse with ADT? What hardware profile, api
level and GPU enabled/disabled profiles are you using for your avds?
I deleted all avds on my system and created new ones with default profiles.
Nexus 4 avds work from API 10 to 19 but API 21 doesn't work.
Nexus 5 & 6 hardware profiles don't work with any APIs.
I have tried both arm and x86 ones and enabled/disabled GPU, and also tried
starting with snapshots.
All profiles worked in 3.17 kernel series and some work and some don't in
3.18. None of the API 21 are working.
--
Regards,
Sudhir Khanger,
sudhirkhanger.com,
github.com/donniezazen,
5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394.