Discuss June 2016

discuss@lists.centos.org

114 participants
99 discussions

CentOS Virtual Machine System Time
by Chris Olson 18 Jun '16

18 Jun '16

We run several CentOS 6 and CentOS 7 systems as virtual machines using VirtualBox on Windows 7. Most of these systems have continuous up time. The Windows 7 foundation platforms have no difficulty keeping accurate system time unless they are shut down for some reason, which is rare in our environment. We generally restart the Windows 7 machines at leastweekly rather than performing a complete power up restart. The CentOS virtual machines are shut down at times, usually to switch between versions that support various applications and for updates using yum. When the virtual CentOS systems are brought up, the system time always matches the Windows 7 host system time. We have recently noticed that after several hours, the CentOS system time has started to lag behind. The time difference in a week can be as much as four days. This system time lag has not always been immediately discovered by the user resulting in some annoying file date issues. Access to some web sites have also been a problem due to the "date in the future" issue. We are now on the lookout for this system time problem and restart the virtual machine to set the current date and time. Is this a common time problem when running CentOS as a virtual machine? Any suggestions regarding the cause if this problem and how to keep the CentOS system time locked to the host platform time would be greatly appreciated. Thanks.

3 2

Re: [CentOS] https and self signed
by James B. Byrne 18 Jun '16

18 Jun '16

On Thu, June 16, 2016 13:53, Walter H. wrote: > On 15.06.2016 16:17, Warren Young wrote: >> but it also affects the other public CAs: you canât get a >> publicly-trusted cert for a machine without a publicly-recognized >> and -visible domain name. For that, you still need to use >> self-signed certs or certs signed by a private CA. >> > A private CA is the same as self signed; > No it is not. A private CA is as trustworthy as the organisation that operates it. No more and not one bit less. We operate a private CA for our domain and have since 2005. We maintain a public CRL strictly in accordance with our CPS and have our own OID assigned. Our CPS and CRL together with our active, expired and revoked certificate inventory is available online at ca.harte-lyne.ca. Our CPS states that we will only issue certificates for our own domain and furthermore we only issue them for equipment and personnel under our direct control. In a few years DANE is going to destroy the entire market of 'TRUSTED' root CA's -- because really none of them are trust 'worthy' --. And that development is long overdue. When we reach that point many domains, if not most, will have their DNS forward zones providing TLSA RRs for their domain CA certificates and signatures. And most of those that do this are going to be running their own private CA's simply to maintain control of their certificates. Our DNS TLSA flags tell those that verify using DANE that our private CA is the only authority that can issue a valid certificate for harte-lyne.ca and its sub-domains. Compare that to the present case wherein any 'trusted' CA can issue a certificate for any domain whatsoever; whether they are authorised by the domain owner or not[1]. So in a future with DANE it will be possible to detect when an apparently 'valid' certificate is issued by a rogue CA. The existing CA structure could not have been better designed for exploitation by special interests. It has been and continues to be so exploited. Personally I distrust every one of the preloaded root CAs shipped with Firefox by manually removing all of their trust flags. I do the same with any other browser I use. I then add back in those trusts essential for my browser operation as empirical evidence warrants. So I must trust certain DigiCert certificates for GitHub and DuckDuckGo, GeoTrust for Google, COMODO for Wikipedia, and so forth. These I set the trust flags for web services only. The rest can go pound salt as we used to say. [1] https://nakedsecurity.sophos.com/2013/12/09/serious-security-google-finds-f… -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3

5 6

Re: [CentOS] https and self signed
by Gordon Messmer 18 Jun '16

18 Jun '16

On 06/17/2016 07:56 AM, James B. Byrne wrote: > On Thu, June 16, 2016 14:09, Gordon Messmer wrote: >> I doubt that most users check the dates on SSL certificates, >> unless they are familiar enough with TLS to understand that >> a shorter validity period is better for security. > What evidence do you possess that supports this assertion and would > you care to share it with us? https://letsencrypt.org/2015/11/09/why-90-days.html

2 1

Re: [CentOS] https and self signed
by James B. Byrne 18 Jun '16

18 Jun '16

On Thu, June 16, 2016 14:23, Valeri Galtsev wrote: > > On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote: >> >> I doubt that most users check the dates on SSL certificates, >> unless they are familiar enough with TLS to understand that >> a shorter validity period is better for security. > > Oh, this is what he meant: Cert validity period. Though I agree > with you in general (shorter period public key is exposed smaller > chance secret key brute-force discovered), Like many things that appear to be common-sense these assumptions have no empirical basis. A properly generated RSA certificate and key of sufficient strength -- RSA k>=2048bits -- should provide protection from brute force attacks for decades if not centuries. The usual way a private key gets compromised is by theft or by tampering with its generation. Putting yourself on a hamster wheel of constant certificate generation and distribution simply increases the opportunities for key theft and tampering. Keys issued to individuals certainly should have short time limits on them. In the same way that user accounts on systems should always have a near term expiry date set. People are careless. And their motivations are subject to change. So having a guillotine date on a personal certificate makes sense from an administrative standpoint. One wants to fail safe. But modifying certificates on sealed servers?. Really, unless one has evidence of penetration and theft of the key store, what possible benefit accrues from changing secured device keys on a frequent basis? We mainly use 4096bit keys which will be secure from brute force until the advent of Quantum computing. At which point brute force attacks will become a pointless worry. Not because the existing RSA certificates and keys will withstand those attacks but because the encryption process itself will move onto quantum devices. That development, if and when it occurs, will prove more than the code breakers will ever be able to handle. Of course then one must worry about the people who build the devices. But we all have to do that already. Bought any USB devices from China recently? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3

2 1

Getting hibernate to work on a new CentOS 7.2.1115 install
by Globe Trotter 18 Jun '16

18 Jun '16

Hi, I am a new CentOS user (quite familiar with Fedora 1-23+) and I decided to try a new install of CentOS on a ASUS R503U. However, I can not get hibernate to work. I try: systemctl hibenaate and I get: Failed to execute operation: sleep verb not supported Btw, the problem does not go away with super-user. I was wondering how to get around this issue. I would like the abililty to hibernate and come back in the last state. Thanks!

3 5

[Fwd: Re: https and self signed]
by James B. Byrne 17 Jun '16

17 Jun '16

On Fri, June 17, 2016 12:31, Valeri Galtsev wrote: > > On Fri, June 17, 2016 10:19 am, James B. Byrne wrote: > >> Keys issued to individuals certainly should have short time limits >> on them. In the same way that user accounts on systems should >> always have a near term expiry date set. People are careless. >> And their motivations are subject to change. > > James, though in general one is likely to agree with this, I still > consider the conclusion I came to after discussions more than decade > ago valid for myself. Namely: forcing everyone to change password > often pisses careful people off for nothing. Passwords they create > and carefully keep can stand for decades, and only can be > compromised on some compromised machine. But I never mentioned anything about passwords. I quite agree with you with respect to avoiding needless password churn. What I wrote was specifically user accounts and their expiry dates. These should be short. Say six to twelve months or so. When the account expires then it can be renewed for another six or 12 months. The password for it is not changed. One can always write a script to automatically search for and report pending expirations. There is no real need for accounts to actually expire. But, even if accounts do expire for active users then it is not much of a hardship to report the fact and to have them reactivated. On the other hand, disused accounts never get reported and remain deactivated. Also, when a person leaves our employ and somehow the cancellation of all or some their accounts gets overlooked in the out-processing then shortly their accounts will be deactivated automatically. A fail safe mechanism. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3

2 1

Would centos 7 backport this libnl3 header fix
by Harry Mallon 17 Jun '16

17 Jun '16

Hello, Would CentOS7 consider adding the following patch to libnl3? https://github.com/thom311/libnl/commit/cdf2d4baf376e4a3030a2c1169516358b4f… g++ fails to build against the headers in the default devel package at the moment so I am having to package my own. The patch is very small and easily applies on top of the c7 branch from the RPM git. https://git.centos.org/summary/rpms!libnl3.git Harry Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry(a)codexdigital.com<mailto:harry@codexdigital.com> | T +44 203 7000 989<callto:+44%20203%207000%20989> Website<www.codexdigital.com> | Facebook<https://www.facebook.com/codexdigital> | Twitter<http://twitter.com/codexdigital> [http://www.codexdigital.com/?action=asset&id=E55D8A6F-AF62-4978-8FF1-435A85…]<http://www.codexdigital.com>

2 1

Re: [CentOS] https and self signed
by Valeri Galtsev 17 Jun '16

17 Jun '16

On Fri, June 17, 2016 10:19 am, James B. Byrne wrote: > > On Thu, June 16, 2016 14:23, Valeri Galtsev wrote: >> >> On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote: >>> >>> I doubt that most users check the dates on SSL certificates, >>> unless they are familiar enough with TLS to understand that >>> a shorter validity period is better for security. >> >> Oh, this is what he meant: Cert validity period. Though I agree with you in general (shorter period public key is exposed smaller chance secret key brute-force discovered), > > Like many things that appear to be common-sense these assumptions have no empirical basis. A properly generated RSA certificate and key of sufficient strength -- RSA k>=2048bits -- should provide protection from brute force attacks for decades if not centuries. The usual way a private key gets compromised is by theft or by tampering with its generation. Putting yourself on a hamster wheel of constant > certificate generation and distribution simply increases the > opportunities for key theft and tampering. > > Keys issued to individuals certainly should have short time limits on them. In the same way that user accounts on systems should always have a near term expiry date set. People are careless. And their motivations are subject to change. James, though in general one is likely to agree with this, I still consider the conclusion I came to after discussions more than decade ago valid for myself. Namely: forcing everyone to change password often sets careful people off for nothing. Passwords they create and carefully keep can stand for decades, and only can be compromised on some compromised machine. Now, from my (careful person) point of view, US National labs forcing me change password every 6 Months is just confirming the fact they imply their boxes are compromised often. As: my passwords (passphrases) are different everywhere, and I only connect one way ever: from trusted (maintained by me that is) machine to untrusted (maintained by someone else that is). Never from untrusted machine elsewhere. Now, simple argument we had: if you force person to change password often, even worse thing will happen: person will never remember ever changing password and the last will be written on a piece of paper stuck to the back of the screen or similar. Yes, I know about and I do use encrypted storage dedicated for passwords. Does everybody? Things change but people don't (almost don't). So, the best bet for multi-user machine is to run it under assumption that bad guys are already inside. Occasionally you see them attempting elevation of privileges, smash them, and make the user whose password was stolen change that, and change all his/her passwords everywhere, banks and other $$$ accounts first. After this sort of exercise this same person never is the one in this same sort of trouble. Yes I had these cases, not many during last decade and a half. I also have seen an opposite attitude on occasion (user didn't care his password was compromised on machine I administer), then that user had all [bad] what sysadmin can get him... > So having a guillotine date on a > personal certificate makes sense from an administrative standpoint. One wants to fail safe. But modifying certificates on sealed > servers?. Really, unless one has evidence of penetration and theft of the key store, what possible benefit accrues from changing secured device keys on a frequent basis? My point exactly. Only I usually try to say it in so short way, that my point fails to propagate to readers ;-( > > We mainly use 4096bit keys which will be secure from brute force until the advent of Quantum computing. At which point brute force attacks will become a pointless worry. Not because the existing RSA > certificates and keys will withstand those attacks but because the encryption process itself will move onto quantum devices. That > development, if and when it occurs, will prove more than the code breakers will ever be able to handle. Of course then one must worry about the people who build the devices. But we all have to do that already. Bought any USB devices from China recently? Well, I started to avoid Lenovo after they shipped laptop with malware preinstalled. It took them some time after they bought laptop line from IBM. But yes, firmware/microcode malware is something that will bite us soon. BTW, the secret known to two people is not a secret.... Who said that? Cheers, Valeri > > -- > *** e-Mail is NOT a SECURE channel *** > Do NOT transmit sensitive data via e-Mail > Do NOT open attachments nor follow links sent by e-Mail > > James B. Byrne mailto:ByrneJB@Harte-Lyne.ca > Harte & Lyne Limited http://www.harte-lyne.ca > 9 Brockley Drive vox: +1 905 561 1241 > Hamilton, Ontario fax: +1 905 561 0757 > Canada L8E 3C3 > ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++

1 0

Speaking of firefox updates
by m.roth＠5-cent.us 17 Jun '16

17 Jun '16

I haven't gone past 38, because when the 45 update came out, and video... like, say, my *required* training from work, when I tried to run it, it crashed firefox. Repeatedly. 100% of the time. Has anyone been using the current version had trouble with video, etc? I'd like to update, but not if I can't do required training.... mark

2 6

Today's firefox update
by Frank Cox 17 Jun '16

17 Jun '16

Johnny's announcement refers to: firefox-45.2.0-1.el5.centos.src.rpm firefox-45.2.0-1.el6.centos.src.rpm firefox-45.2.0-1.el7.centos.src.rpm The linked rhel webpage refers to: firefox-45.2.0-1.el5_11.src.rpm firefox-45.2.0-1.el6_8.src.rpm firefox-45.2.0-1.el7_2.src.rpm These do not appear to be the same thing. Note the numbers just before the .src part of the filenames. -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com

4 4

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss June 2016