Re: [CentOS] Chromium on CentOS 6
Sorin, Indeed, CentOS 6 is not longer officially supported by Chrome. It hasn't been for a few years, though there are workarounds[1]. It's high time people migrated to EL7. [1] - http://li.nux.ro/download/nux/dextop/el6/x86_64/chrome-deps-stable-3.11-1.x86_64.rpm -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - > From: "Sorin Srbu" > To: "CentOS mailing list" > Sent: Tuesday, 28 November, 2017 07:47:35 > Subject: Re: [CentOS] Chromium on CentOS 6 >> -Original Message- >> From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of H >> Sent: den 27 november 2017 19:45 >> To: centos@centos.org >> Subject: Re: [CentOS] Chromium on CentOS 6 >> >> >> I have chromium installed on CentOS 7 and it works fine, I now need >> >> to install it on a CentOS 6 workstation. However, it is not >> >> available in EPEL as it is for C 7. From what I understand, this is >> >> because it is already available in a supplementary channel from >> >> RHEL for C 6. >> >> >> >> Is this the recommended method for installing it on C 6? >> >> >> >> https://www.tecmint.com/install-google-chrome-on-redhat-centos-fedo >> >> ra-linux/ >> >> >> > Just curious - why are you using the epel, rather than google, >> > release for centos-7? >> > >> > The current google repo releases, (which install without any issues >> > and work well on centos-7) are: >> > >> > stable.x86_6462.0.3202.94-1 >> > beta.x86_64 63.0.3239.59-1 >> > >> > while the epel one is: >> > >> > 61.0.3163.100-1 >> > >> > which was the "google stable" release in late september, and is about >> > five releases back. >> >> Ah, good, so this would be using the google-chrome.repo? I was not > familiar >> with it. > > Wasn't the latest Google Chrome unsupported on CentOS 6 because of some > dependency problems or some such? > > > -- > //Sorin > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Chromium on CentOS 6
> -Original Message- > From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Nux! > Sent: den 28 november 2017 09:17 > To: CentOS mailing list > Subject: Re: [CentOS] Chromium on CentOS 6 > > Sorin, > > Indeed, CentOS 6 is not longer officially supported by Chrome. It hasn't been > for a few years, though there are workarounds[1]. > > It's high time people migrated to EL7. > > [1] - http://li.nux.ro/download/nux/dextop/el6/x86_64/chrome-deps- > stable-3.11-1.x86_64.rpm That was indeed my main incentive to upgrade to CentOS 7! If not for Chrome, I'd have stayed on C6 till 2020. -- //Sorin ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Failed attempts
> > > > - don't run ssh on 22, use a different port. (Things get a lot > > quieter when you do that, but it comes with it's own problems and don't > > get complacent because someone will find the port eventually.) > > I consider that pointless security-through-obscurity. That wasn't meant as a "security" thing - that's why it was under the heading "For your sanity ...". All these things do is to make it so that your machine is no longer the low-hanging-fruit! P. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Failed attempts
Hi Valeri, > Good luck! Use strong passwords (passphrase I call it when I talk to my > users), especially for root account. if possible: Do not use passwords at all. Disable password login, and replace by SSH private/public key authentication, and, again if possible, with OTP (two factor authentication) on top. All the other hints (disallow root access via SSH, use strong passwords, port knocking, different ports etc.) just put the hurdle a bit higher but do not solve the underlying problem: Password authentication is weak by design, as it relies on the well-behaviour of users. Don't restrict their passwords and they'll use simple ore easily-guessible ones. Restrict them and they will write them down. Cheers, Pete. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Chromium on CentOS 6
Hi, On Mon, Nov 27, 2017 at 09:07:36PM +0100, H wrote: > > OK, I have no interest in Flash, however. If you don't mind installing singularity (https://github.com/singularityware/singularity), you can run a CentOS-7 docker based container with google-chrome at the expense of disk space. If you have version >= 2.4 installed you can just do something like: $ mkdir ~/home-for-google-chrome $ singularity run -B /run -H ~/home-for-google-chrome \ shub://truatpasteurdotfr/singularity-docker-centos7-google-chrome caveat: works for me, and google-chrome is running with --no-sandbox Cheers Tru PS: https://github.com/truatpasteurdotfr/singularity-docker-centos7-google-chrome -- Tru Huynh http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBEFA581B pgp82ZOSeE0RT.pgp Description: PGP signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS-announce Digest, Vol 153, Issue 6
Send CentOS-announce mailing list submissions to
centos-annou...@centos.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org
You can reach the person managing the list at
centos-announce-ow...@centos.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."
Today's Topics:
1. CESA-2017:3263 Moderate CentOS 7 curl SecurityUpdate
(Johnny Hughes)
2. CESA-2017:3260 Important CentOS 7 samba Security Update
(Johnny Hughes)
--
Message: 1
Date: Mon, 27 Nov 2017 18:26:45 +
From: Johnny Hughes
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2017:3263 Moderate CentOS 7 curl
SecurityUpdate
Message-ID: <20171127182645.ga1...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Security Advisory 2017:3263 Moderate
Upstream details at : https://access.redhat.com/errata/RHSA-2017:3263
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
12128ce4bbba8672939e49a25dc1bfe1a04e639ac96aa5b732c3d053ddb721ea
curl-7.29.0-42.el7_4.1.x86_64.rpm
04d8b20bd1d0b3f9085d0c842288fc4cba43f954a90c110d85ff9570162e0976
libcurl-7.29.0-42.el7_4.1.i686.rpm
a7402b46263a2e50e9606dfc8ca9311108f1262feb6e239b276e53a693caa4fb
libcurl-7.29.0-42.el7_4.1.x86_64.rpm
bdd1d62cb57d42be83e7541702b54478b0e6cd84e0ee16f256b242b84e922c64
libcurl-devel-7.29.0-42.el7_4.1.i686.rpm
dc6ba209b0ecbb6fd5ff965a48bf331256a1943db9bc8fe10185aadb25ba891e
libcurl-devel-7.29.0-42.el7_4.1.x86_64.rpm
Source:
6af0b6df53096c0cc73dc0646a342612cc47630009ee833d537edec482d0f43a
curl-7.29.0-42.el7_4.1.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS
--
Message: 2
Date: Mon, 27 Nov 2017 18:28:01 +
From: Johnny Hughes
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2017:3260 Important CentOS 7 samba
SecurityUpdate
Message-ID: <20171127182801.ga1...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Security Advisory 2017:3260 Important
Upstream details at : https://access.redhat.com/errata/RHSA-2017:3260
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
0d92a19859285f5d0f5f3f9a00d36234f995f2d1d4a19bc012f983b843cf51ed
ctdb-4.6.2-12.el7_4.x86_64.rpm
b9bb10e17112dec3189fcd2ec0bc731a446d0b2bd406dc54a741cfead05e52c9
ctdb-tests-4.6.2-12.el7_4.x86_64.rpm
f37cb3274edbd98c0f89a2be0e03430cf116d10aa4b89b7461bec8212481abf8
libsmbclient-4.6.2-12.el7_4.i686.rpm
75c3436c655adb05315e4d44969521aa71d6ef63083e0acc2e4bfff94a9077a8
libsmbclient-4.6.2-12.el7_4.x86_64.rpm
e1d76a09e159bd88a8508c51b7b2ef4482dfcf53b2c792af293623fa00c03167
libsmbclient-devel-4.6.2-12.el7_4.i686.rpm
6f468a0c049aa3cdbef96262a7b070da656d715fbf3d0dfa2cfcad36a155985e
libsmbclient-devel-4.6.2-12.el7_4.x86_64.rpm
7f68cb4437d2e7e0780927bab9e8af8d09c266dec00236d65ddb5061f53efb02
libwbclient-4.6.2-12.el7_4.i686.rpm
e23f4fd45ab55ba518f7d15f6810bffb11e9bf27bc9897ff22cd7afdf967
libwbclient-4.6.2-12.el7_4.x86_64.rpm
11e40d6c710327f9ede5138a11b54365673363b20be5fdcdb57dcda6ed41acc7
libwbclient-devel-4.6.2-12.el7_4.i686.rpm
8ec758eda40264eca9168549317ffcf57c704c55e6efc0cecbc51b13e37d74ce
libwbclient-devel-4.6.2-12.el7_4.x86_64.rpm
179b904c15b0748047ca05baf323976867e37c6876a8c46a347dd920d52b34e1
samba-4.6.2-12.el7_4.x86_64.rpm
da7fc42168b4e6b02a70675bd9ad35bd71e910c762b837664baf4eb765410a75
samba-client-4.6.2-12.el7_4.x86_64.rpm
0867fddbc2b5d2a5b339b18bef6187adbfcf19843537036d89761af52ac8150c
samba-client-libs-4.6.2-12.el7_4.i686.rpm
f2d6b03b8a032d8b5a3c8e791c4365c010a394035715f653df7e96fba3abd96d
samba-client-libs-4.6.2-12.el7_4.x86_64.rpm
d2949e2277bcc66de9ace7eef686983256e089635b3700c2d2946a8d0de08f33
samba-common-4.6.2-12.el7_4.noarch.rpm
edd2afaec50afa21059a82f762df22815cd71ed70cf753e3ec9d78d4a1d38340
samba-common-libs-4.6.2-12.el7_4.x86_64.rpm
9c2250b47720590216235faacbc1ce9d5eb160742d6ef7a2317059669a87db03
samba-common-tools-4.6.2-12.el7_4.x86_64.rpm
3a571b646f542e877a5a9343a5b931dbdbb718dc82975d236b00da2095d18ab1
samba-dc-4.6.2-12.el7_4.x86_64.rpm
c76f6d57e16f3b183d38c7deb45f8772197812d4beeda559c48688c23e1c6347
samba-dc-libs-4.6.2-12.el7_4.x86_64.rpm
9b485433b5e9497aa13c1a527dcf0ec8468e23ff295baebf9d5b40ca5a8a220d
samba-devel-4.6.2-12.el7_4.i686.rpm
a85629a7d7d116dc9c7dfa0e09873b4cbc2cc11ca8413302bddbede4790c2f9f
samba-devel-4.6.2-12.el7_4.x86_64.rpm
6a9fae15a632a618313134f8d7781b73feae0b783867dca1e73efde18aac6e08
samba-krb5-printing-4.6.2-1
[CentOS] Admins supporting both RHEL and CentOS
With a few exceptions, I see most admins treat CentOS as a single rolling release and rely on the ABI commitment assuming things just work between point releases. On the other hand I see the opposite with RHEL where admins constrain installations to the point release. What is the case with users on this list who support both? Thanks, Joseph L. Casale ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Admins supporting both RHEL and CentOS
On 11/28/2017 08:06 AM, Joseph L. Casale wrote: With a few exceptions, I see most admins treat CentOS as a single rolling release and rely on the ABI commitment assuming things just work between point releases. On the other hand I see the opposite with RHEL where admins constrain installations to the point release. What is the case with users on this list who support both? I can't really speak for anyone else, but for me, a lot depends on the use of the systems. I typically treat RHEL and CentOS the same way as far as updating to the latest point release. It's never bit me in the past that I am aware of. The only exception to that is with the SGI Altix 4300/4400s I used to manage. We migrated from SLES to RHEL and in those cases, barring a serious enough bug, those boxes were left alone until time came to refresh them, such as the move from RHEL5 to RHEL6. -- Mark Haney Network Engineer at NeoNova 919-460-3330 option 1 mark.ha...@neonova.net www.neonova.net ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Admins supporting both RHEL and CentOS
On 28 November 2017 at 13:48, Mark Haney wrote: > On 11/28/2017 08:06 AM, Joseph L. Casale wrote: >> >> With a few exceptions, I see most admins treat CentOS as a single >> rolling release and rely on the ABI commitment assuming things >> just work between point releases. On the other hand I see the >> opposite with RHEL where admins constrain installations to the >> point release. >> >> What is the case with users on this list who support both? > > > I can't really speak for anyone else, but for me, a lot depends on the use > of the systems. I typically treat RHEL and CentOS the same way as far as > updating to the latest point release. It's never bit me in the past that I > am aware of. > > The only exception to that is with the SGI Altix 4300/4400s I used to > manage. We migrated from SLES to RHEL and in those cases, barring a serious > enough bug, those boxes were left alone until time came to refresh them, > such as the move from RHEL5 to RHEL6. > > Note that RHEL is a special case as there's some situations companies will pay out for the Extended Update Support (EUS)[0] in order to stay on a particular milestone for longer. In addition there is the slight bonus of access to beta of the next milestone or major release which may affect your workflow if you have a suitable test environment, and of course you'll get the milestone quicker on release so that needs to be paid attention to for testing. Outside of this area the two can be, and should be, treated identically in terms of update policies. [0] https://access.redhat.com/support/policy/updates/errata ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Failed attempts
On 11/27/2017 02:02 PM, m.r...@5-cent.us wrote: Pete Biggs wrote: - don't run ssh on 22, use a different port. I consider that pointless security-through-obscurity. Security through obscurity it may be, but it isn't pointless. Tarpits are in a similar class; they don't help with security in the absolute sense, but they slow the attacker down, and that might be enough to prevent the attack from continuing. (that is, put a tarpit on port 22 and run the real ssh elsewhere!) Any and all stumblingblocks you can put in the attacker's way, whether they're 'real' security or not, are worth at least looking at and evaluating their usefulness. Port knocking is an extreme form of security through obscurity, in reality, and falls into this class of tools. Likewise fail2ban; all it really does is slow down the attacker. No, obscurity-increasing tools will not stop the determined attacker, but, it is very true that these sorts of measures can and do increase the signal-to-noise ratio in your logs; what does get logged will likely be much more useful and indicative of a more determined attacker. Anything that substantially increases the log's signal to noise is useful and not pointless, in my opinion. Anything that slows down the attack is even more useful. I actually have training as a locksmith, with a specialty in masterkeying systems like rotating-constant and some obscure variations of RCM (this is one of the two masterkey systems explored in the infamous (in locksmith circles) paper "Cryptology and Physical Security: Rights Amplification in Master-Keyed Mechanical Locks" by Matt Blaze [1] [2]). In physical security all security is, in reality, through obscurity [3] (page 2, first paragraph): things like keeping the drill points secret (example: in a pin-tumbler lock, if you can drill the shear line, you are in; but what if you have extra pins and hidden shear lines?), keeping secret what materials are used for the hardplate and their interactions with commonly-available drill-bit materials [4], having a strategically placed and hidden tear gas vial [5], etc (all of this information is publicly available; I'm not spilling any real locksmith secrets here). The real key to effective physical security is not keeping the attacker out in an absolute, 'can't possibly break in' sense, but buying time for response to the attack; as the attack continues to eat time, the attacker will have increasing incentive to leave the premises. Now, if you want a real eye-opener about physical security, grab a copy of "OPEN IN THIRTY SECONDS" from Amazon [6]. That and the key reference, Marc Weber Tobias' LSS (Locks, Safes, and Security [7]) are fascinating (if expensive) reading and great resources for the syadmin who wants to dig into what is really meant by a security mindset. [1]: http://www.crypto.com/papers/mk.pdf [2]: http://www.crypto.com/masterkey.html [3]: http://www.crypto.com/papers/safelocks.pdf [4]: https://reassembler.wordpress.com/2008/02/04/drilling-into-a-modern-safe/ [5]: http://www.lockpicking101.com/viewtopic.php?f=8&t=16891 [6]: https://www.amazon.com/OPEN-THIRTY-SECONDS-Cracking-America/dp/0975947923 [7]: https://www.amazon.com/Locks-Safes-Security-International-Reference/dp/0398070792 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Admins supporting both RHEL and CentOS
On 11/28/2017 08:06 AM, Joseph L. Casale wrote: What is the case with users on this list who support both [rolling releases like the normal CentOS model and 'constrain to the point releases' as is possible with RHEL]? I personally run RHEL just like my CentOS installs, as a rolling release. If you want to get more input on this idea, you might want to also ask the Scientific Linux mailing list, since SL can be run in a 'constrain to the point release' mode with full security updates maintained, and you're likely to get a broader response base as to why this is done. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Admins supporting both RHEL and CentOS
On 11/28/2017 08:20 AM, James Hogarth wrote: > On 28 November 2017 at 13:48, Mark Haney wrote: >> On 11/28/2017 08:06 AM, Joseph L. Casale wrote: >>> >>> With a few exceptions, I see most admins treat CentOS as a single >>> rolling release and rely on the ABI commitment assuming things >>> just work between point releases. On the other hand I see the >>> opposite with RHEL where admins constrain installations to the >>> point release. >>> >>> What is the case with users on this list who support both? >> >> >> I can't really speak for anyone else, but for me, a lot depends on the use >> of the systems. I typically treat RHEL and CentOS the same way as far as >> updating to the latest point release. It's never bit me in the past that I >> am aware of. >> >> The only exception to that is with the SGI Altix 4300/4400s I used to >> manage. We migrated from SLES to RHEL and in those cases, barring a serious >> enough bug, those boxes were left alone until time came to refresh them, >> such as the move from RHEL5 to RHEL6. >> >> > > > Note that RHEL is a special case as there's some situations companies > will pay out for the Extended Update Support (EUS)[0] in order to stay > on a particular milestone for longer. > > In addition there is the slight bonus of access to beta of the next > milestone or major release which may affect your workflow if you have > a suitable test environment, and of course you'll get the milestone > quicker on release so that needs to be paid attention to for testing. > > Outside of this area the two can be, and should be, treated > identically in terms of update policies. > > > > [0] https://access.redhat.com/support/policy/updates/errata And also note that Red Hat does not publicly release the SRPMs for their EUS packages. The CentOS Project therefore can not build those, so there is NO EUS in CentOS Linux. The only way to get Security updates in CentOS Linux is to be on the current (latest) point release. Also, since all updates are built against the current (latest) release as they are released, there is no way to get only security updates in CentOS Linux. You could TRY to only install security updates on your own .. however, since there are rebases during point releases, things that are built against the newer openssl will not work with older ssl's OR things build against the newer gnome will not work with older gnome's, etc. The only tested way to run CentOS Linux is with all the updates installed together. signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Failed attempts
On 11/28/2017 04:09 AM, Pete Biggs wrote: - don't run ssh on 22, use a different port. (Things get a lot quieter when you do that, but it comes with it's own problems and don't get complacent because someone will find the port eventually.) I consider that pointless security-through-obscurity. That wasn't meant as a "security" thing - that's why it was under the heading "For your sanity ...". All these things do is to make it so that your machine is no longer the low-hanging-fruit! Pointless? I think not. Using (and locking down, which is implicit in my post) a non-standard port isn't pointless. I dare say, it's as valid as using fail2ban or iptables. Let me ask, since you're against pointless changes, do you also advertise the SSHd version you're running on your standard port? If not, isn't that the same thing? Besides, the idea is to /not be low hanging fruit/, is it not? The idea is to make the system as secure as possible. Security is something everyone should take seriously, and sometimes hiding the padlock is probably a better deterrent than just having it in plain sight. The harder you make it for someone to attack you, the better off you will be. Scoff if you will, I've been at this 20 years, I'd rather OVER secure than under if the circumstances require it. -- Mark Haney Network Engineer at NeoNova 919-460-3330 option 1 mark.ha...@neonova.net www.neonova.net ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Admins supporting both RHEL and CentOS
Joseph L. Casale wrote: > With a few exceptions, I see most admins treat CentOS as a single > rolling release and rely on the ABI commitment assuming things > just work between point releases. On the other hand I see the > opposite with RHEL where admins constrain installations to the > point release. > > What is the case with users on this list who support both? > Only time we use CR is on *some* servers during the upgrade to a new subrelease. Otherwise, nope. mark ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Admins supporting both RHEL and CentOS
On 11/28/2017 10:20 AM, m.r...@5-cent.us wrote: > Joseph L. Casale wrote: >> With a few exceptions, I see most admins treat CentOS as a single >> rolling release and rely on the ABI commitment assuming things >> just work between point releases. On the other hand I see the >> opposite with RHEL where admins constrain installations to the >> point release. >> >> What is the case with users on this list who support both? >> > Only time we use CR is on *some* servers during the upgrade to a new > subrelease. Otherwise, nope. When I was a sysadmin for a living, I used CR in my test/staging area to see if everything worked. After I worked out all the kinks, I then either used CR on my production servers and/or waited until the actual point release, based on how close the release was going to be after I finished evaluating in testing/staging. In general, for CentOS Linux 6 and before .. CR takes 3 or 4 days and final release is usually 14 to 21 days. For CentOS Linux 7 (because of more rebases to newer versions that are much less conservative than EL6 and before) CR usually takes 10-14 days and final point release 35 to 42 days. So, the delta in both cases (from CR done to final point release) is 2 to 4 weeks after CR rpms are released. signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Failed attempts
On Tue, November 28, 2017 9:21 am, Lamar Owen wrote: > On 11/27/2017 02:02 PM, m.r...@5-cent.us wrote: >> Pete Biggs wrote: >>>- don't run ssh on 22, use a different port. >> I consider that pointless security-through-obscurity. > Security through obscurity it may be, but it isn't pointless. Tarpits are in a similar class; they don't help with security in the absolute sense, but they slow the attacker down, and that might be enough to prevent the attack from continuing. (that is, put a tarpit on port 22 and run the real ssh elsewhere!) Any and all stumblingblocks you can put in the attacker's way, whether they're 'real' security or not, are worth at least looking at and evaluating their usefulness. Port knocking is an extreme form of security through obscurity, in reality, and falls into this class of tools. Likewise fail2ban; all it really does is slow down the attacker. > > No, obscurity-increasing tools will not stop the determined attacker, but, it is very true that these sorts of measures can and do increase the signal-to-noise ratio in your logs; what does get logged will likely be much more useful and indicative of a more determined attacker. Anything that substantially increases the log's signal to noise is useful and not pointless, in my opinion. Anything that slows down the attack is even more useful. > > I actually have training as a locksmith, with a specialty in > masterkeying systems like rotating-constant and some obscure variations of RCM (this is one of the two masterkey systems explored in the infamous (in locksmith circles) paper "Cryptology and Physical Security: Rights Amplification in Master-Keyed Mechanical Locks" by Matt Blaze [1] [2]). > > In physical security all security is, in reality, through obscurity [3] (page 2, first paragraph): things like keeping the drill points secret (example: in a pin-tumbler lock, if you can drill the shear line, you are in; but what if you have extra pins and hidden shear lines?), keeping secret what materials are used for the hardplate and their interactions with commonly-available drill-bit materials [4], having a strategically placed and hidden tear gas vial [5], etc (all of this information is publicly available; I'm not spilling any real locksmith secrets here). > > The real key to effective physical security is not keeping the attacker out in an absolute, 'can't possibly break in' sense, but buying time for response to the attack; as the attack continues to eat time, the attacker will have increasing incentive to leave the premises. > > Now, if you want a real eye-opener about physical security, grab a copy of "OPEN IN THIRTY SECONDS" from Amazon [6]. That and the key > reference, Marc Weber Tobias' LSS (Locks, Safes, and Security [7]) are fascinating (if expensive) reading and great resources for the syadmin who wants to dig into what is really meant by a security mindset. > > [1]: http://www.crypto.com/papers/mk.pdf > [2]: http://www.crypto.com/masterkey.html > [3]: http://www.crypto.com/papers/safelocks.pdf > [4]: > https://reassembler.wordpress.com/2008/02/04/drilling-into-a-modern-safe/ [5]: http://www.lockpicking101.com/viewtopic.php?f=8&t=16891 > [6]: > https://www.amazon.com/OPEN-THIRTY-SECONDS-Cracking-America/dp/0975947923 [7]: > https://www.amazon.com/Locks-Safes-Security-International-Reference/dp/0398070792 > Thanks, Lamar! that is very instructive. Physical security [of the machine] was first point in the security list, which we often fail to mention. I like the [physical] lock intro you gave. I was always unimpressed with persistence of attempts to make more secure (less pickable) cylinder cased locks (precision, multi-level, pins at a weird locations/angles). Whereas there exists "disk based design" (should I say Abloy?), which with my knowledge of mechanics I can not figure the way to pick. So I consider them un-pickable. Why aren't they widely used [in US]? Because there may be the reason for powers there be to have locks everywhere pickable. On the other hand, I do not have Abloy locks, as they do keep records that link my particular lock to key that opens it. So, there is viable vector of attack ;-) Valeri Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Failed attempts
On Tue, Nov 28, 2017 at 11:04:14AM -0600, Valeri Galtsev wrote: > On Tue, November 28, 2017 9:21 am, Lamar Owen wrote: > > On 11/27/2017 02:02 PM, m.r...@5-cent.us wrote: > >> Pete Biggs wrote: > >>>- don't run ssh on 22, use a different port. > >> I consider that pointless security-through-obscurity. > > Security through obscurity it may be, but it isn't pointless. Tarpits > are in a similar class; they don't help with security in the absolute > sense, but they slow the attacker down, and that might be enough to > prevent the attack from continuing. There's the old saying to the effect that if you're a gazelle being chased by a lion, you don't have to be the fastest in the herd, just faster than the one running next to you. ;) -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Failed attempts
On 11/28/2017 12:04 PM, Valeri Galtsev wrote: Thanks, Lamar! that is very instructive. You're welcome. I was always unimpressed with persistence of attempts to make more secure (less pickable) cylinder cased locks (precision, multi-level, pins at a weird locations/angles). The best way to make an unpickable lock is to make the tolerances of the pins and the cylinder bore as tight as possible, since picking relies on part tolerances to work. But several sidebar designs are out there that are pretty hard to pick, including Schlage Primus, the various Medeco styles, and others, such as the Kaba dimple locks used on Cisco Metro 1500 DWDM gear for power switches (the lasers are powerful enough to permanently damage your eyes in short order in those). Whereas there exists "disk based design" (should I say Abloy?), ... I had an old Bell System payphone with Abloy locks. Very difficult to bypass or pick, and requiring very different techniques than are used with pin-tumbler locks. There were two locks: one on the coin door (activated four large rectangular bolts, one on each side, with the only common point that could be successfully drilled being the lock cylinder itself), and one on the door to the circuitry (which included the programming port to set the per-call rate for use with a standard subscriber line, instead of the dedicated pay lines, as well as the coin-counter electronics). They were used on many payphones twenty years ago or so. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Failed attempts
Lamar Owen wrote: > On 11/28/2017 12:04 PM, Valeri Galtsev wrote: >> Thanks, Lamar! that is very instructive. > You're welcome. > >> I was always unimpressed with >> persistence of attempts to make more secure (less pickable) cylinder >> cased >> locks (precision, multi-level, pins at a weird locations/angles). > > The best way to make an unpickable lock is to make the tolerances of the > pins and the cylinder bore as tight as possible, since picking relies on > part tolerances to work. But several sidebar designs are out there that > are pretty hard to pick, including Schlage Primus, the various Medeco > styles, and others, such as the Kaba dimple locks used on Cisco Metro > 1500 DWDM gear for power switches (the lasers are powerful enough to > permanently damage your eyes in short order in those). Whenever I get a CAT scan, I point out to the techs that half the warning label is missing: all I see is "Do not start into laser", and not the rest that reads "with remaining eye". Don't mind me: I just spent *far* too long doing my "mid-year performance checkin" for my employer, in Workday (the sooner that dies, the better), and it was designed by idiots, and is not suitable for what 90% of the company does And I'm *really* aggravated. mark ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Admins supporting both RHEL and CentOS
On Tue, Nov 28, 2017 at 8:06 AM Joseph L. Casale wrote: > On the other hand I see the > opposite with RHEL where admins constrain installations to the > point release. This is most commonly due to 3rd party support stipulations (I’m looking at you Oracle/SAP) who haven’t/won’t/lag test a fully patched version of the OS. It also has a lot to do with the admins and the admins competence and ability to call 1-800-$vendor when something doesn’t work. . . . Two ends of the same spectrum. > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Chromium on CentOS 6
Am 28.11.2017 um 12:29 schrieb Tru Huynh :
>
> On Mon, Nov 27, 2017 at 09:07:36PM +0100, H wrote:
>>
>> OK, I have no interest in Flash, however.
>
> If you don't mind installing singularity
> (https://github.com/singularityware/singularity), you can
> run a CentOS-7 docker based container with google-chrome
> at the expense of disk space.
>
>
> If you have version >= 2.4 installed you can just do something like:
> $ mkdir ~/home-for-google-chrome
> $ singularity run -B /run -H ~/home-for-google-chrome \
> shub://truatpasteurdotfr/singularity-docker-centos7-google-chrome
>
>
> caveat: works for me, and google-chrome is running with --no-sandbox
>
> Cheers
>
> Tru
> PS:
> https://github.com/truatpasteurdotfr/singularity-docker-centos7-google-chrome
Is it not easier to rebuild for example the EPEL7 package [1]? Did anyone tried
it?
I have something like
$ scl enable devtoolset-${X} rpmbuild chromium.spec
in mind. The difficult part will be the exact examination of the
needed toolchain! Some kind of reconstruction of the build process
that upstream is applying every couple of weeks for packaging the
last stable version [2].
Here some (old) resources:
- https://github.com/hughesjr/chromium_el_builder
- Some efforts have been made at NCSU. From there following sentence [3]:
> I am no longer able to build for RHEL 6 because I can't figure out how to
> patch the source code for
> such an old kernel. Chromium seems to require video features that are only in
> newer kernels.
So, what is upstream exactly doing to get the build done? Do we need an SIG :-)
[1]
http://mirror.us.leaseweb.net/epel/7/SRPMS/Packages/c/chromium-61.0.3163.100-1.el7.src.rpm
[2] $ curl -s "https://omahaproxy.appspot.com/all?csv=1"; |grep -E
"linux,stable" |cut -d"," -f3
[3] http://install.linux.ncsu.edu/pub/yum/itecs/public/chromium/howto/readme.txt
--
Just some thoughts,
LF
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Failed attempts
On Tue, Nov 28, 2017 at 03:52:36PM -0500, m.r...@5-cent.us wrote: > Lamar Owen wrote: > > On 11/28/2017 12:04 PM, Valeri Galtsev wrote: > >> Thanks, Lamar! that is very instructive. > > You're welcome. > > > >> I was always unimpressed with > >> persistence of attempts to make more secure (less pickable) cylinder > >> cased > >> locks (precision, multi-level, pins at a weird locations/angles). > > > > The best way to make an unpickable lock is to make the tolerances of the > > pins and the cylinder bore as tight as possible, since picking relies on > > part tolerances to work. But several sidebar designs are out there that > > are pretty hard to pick, including Schlage Primus, the various Medeco > > styles, and others, such as the Kaba dimple locks used on Cisco Metro > > 1500 DWDM gear for power switches (the lasers are powerful enough to > > permanently damage your eyes in short order in those). > > Whenever I get a CAT scan, I point out to the techs that half the warning > label is missing: all I see is "Do not start into laser", and not the rest > that reads "with remaining eye". > > Don't mind me: I just spent *far* too long doing my "mid-year performance > checkin" for my employer, in Workday (the sooner that dies, the better), > and it was designed by idiots, and is not suitable for what 90% of the > company does And I'm *really* aggravated. Hah! I'm now being forced to use it to record my hours. And I thought I hated the abomination at elabor.com! I may retire sooner because of it. -- Fred Smith -- fre...@fcshome.stoneham.ma.us - But God demonstrates his own love for us in this: While we were still sinners, Christ died for us. --- Romans 5:8 (niv) -- ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Migrating From CentOS-6 To CentOS-7
I've a system that has been running CentOS 6 64-bit for almost 4-years and I want to start the move to CentOS 7 64-bit. I run software RAID-1 with LVM everywhere except /boot which is a standard partition RAID-1. There are 2 areas that concern me greatly about this migration: 1. How do I duplicate my current grub configuration file that supports a failure of /dev/sda to grub2? 2. How do I install CentOS 7 but use my existing hard drive layout so I only format specific OS file systems. My drive layout goes back to the original proposed FHS layout. The separate partitions are: /boot 1GB / 6GB /home 4GB /opt 4GB /tmp 2GB /usr 12GB /usr/local 2GB /var 8GB swap 16GB Plus many other file system dedicated to specific applications and data. When I moved from CentOS 5 to CentOS 6 all of the OS partitions were formatted except /home. All went extremely well then. But I don't see a way to do that with CentOS 7. Is there some detailed installation instructions showing some advanced methods? TIA Gene -- Eugene Poole Woodstock, Georgia ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Admins supporting both RHEL and CentOS
> -Original Message- > From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Joseph L. > Casale > Sent: den 28 november 2017 14:06 > To: 'centos@centos.org' > Subject: [CentOS] Admins supporting both RHEL and CentOS > > With a few exceptions, I see most admins treat CentOS as a single > rolling release and rely on the ABI commitment assuming things > just work between point releases. On the other hand I see the > opposite with RHEL where admins constrain installations to the > point release. > > What is the case with users on this list who support both? I treat them as rolling releases. Except for those I don't. :-) Seriously, some of the RHEL-boxes we use, require a particular point release as well as not allowing any updates to the OS. At all. Yeah, I know... If updated, the instrument software will break, like in an atomic mushroom cloud, rendering critical hardware non-working and lab people standing outside my office with torches, pitch-forks and all the shebang. Yupp, unfortunately that's the current state of some lab equipment manufacturers that use RHEL as a base... -- //Sorin ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Admins supporting both RHEL and CentOS
Le 29/11/2017 à 08:26, Sorin Srbu a écrit : > If updated, the instrument software will break, like in an atomic mushroom > cloud, rendering critical hardware non-working and lab people standing > outside my office with torches, pitch-forks and all the shebang. > Yupp, unfortunately that's the current state of some lab equipment > manufacturers that use RHEL as a base... ProMAX/SeisSpace, a geophysical calculation software edited by Halliburton and costing roughly $ 50.000 / workstation still requires RHEL 5.x to run. :o) -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : i...@microlinux.fr Tél. : 04 66 63 10 32 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Admins supporting both RHEL and CentOS
> -Original Message- > From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Nicolas > Kovacs > Sent: den 29 november 2017 08:31 > To: centos@centos.org > Subject: Re: [CentOS] Admins supporting both RHEL and CentOS > > Le 29/11/2017 à 08:26, Sorin Srbu a écrit : > > If updated, the instrument software will break, like in an atomic mushroom > > cloud, rendering critical hardware non-working and lab people standing > > outside my office with torches, pitch-forks and all the shebang. > > Yupp, unfortunately that's the current state of some lab equipment > > manufacturers that use RHEL as a base... > > ProMAX/SeisSpace, a geophysical calculation software edited by > Halliburton and costing roughly $ 50.000 / workstation still requires > RHEL 5.x to run. > > :o) LOL!! Awesome! Better living through technology, right? :-D -- //Sorin ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
