f.haeder.net

Search

Items tagged with: CentOS

News from #Fedora Infrastructure
https://communityblog.fedoraproject.org/news-from-fedora-infrastructure/ #redhat #gnu #linux #centos
News from Fedora Infrastructure
 
Image/photo

Understanding the Red Hat Enterprise Linux random number generator interface


January 30, 2019
Nikos Mavrogiannopoulos
Like other operating systems, Red Hat Enterprise Linux provides a cryptographically-secure pseudo-random number generator (CSPRNG) as part of our kernel. It is intended to be used by cryptographic back-ends and applications requiring cryptographic operations. Unfortunately, there is much mystery around the interfaces provided. While the new random(7) manual page does clarify some aspects, it does not fully address all common questions. In this post, we will make a brief overview of these interfaces, starting from their initialization to their use.

Note that, this post will not get into the internals of a CSPRNG. We will go through these interfaces, intentionally staying on the high-level, without considering internal details, and discuss their usefulness for an application or library that requires access to such a CSPRNG.

Note that these interfaces are a compromise of various schools of thought in the free software ecosystem and carry their historical mistakes for backward compatibility.

How does the kernel initialize its CSPRNG?



The kernel has an “entropy pool,” a place where unpredictable input observed by the kernel is mixed and stored. That pool serves as a seed to the internal CSPRNG, and until some threshold of estimated entropy is reached initially, it is considered uninitialized.

Let’s now see how the kernel initializes its entropy pool.

- After the kernel takes control on power-on, it starts filling its entropy pool by mixing interrupt timing and other unpredictable input.
- The kernel gives control to systemd.
- Next, systemd starts and initializes itself.
- Systemd, optionally, loads kernel modules which will improve the kernel's entropy gathering process on a virtual machine (e.g., virtio-rng).
- Systemd loads the rngd.service which will gather additional input entropy obtained via a random generator exposed by hardware (e.g., the x86 RDRAND instruction or similar) and jitter entropy1; this entropy is fed back into the kernel to initialize its entropy pool, typically in a matter of milliseconds.

After the last step, the kernel has its entropy pool initialized, and any systemd services started can take advantage of the kernel’s random generator.

Note that the virtio-rng kernel module loading in step (3), is an optional step which improves entropy gathering in a virtual machine by using the host's random generator to initialize the guest systems in KVM. The rngd.service loading at the final step (4) is what ensures that the kernel entropy pools are initialized on every scenario, and furthermore it continues mixing additional data in the kernel pool during system runtime.

How does the kernel provide access to its CSPRNG?



The Linux kernel, as shipped with Red Hat Enterprise Linux after 7.4, provides the following interfaces for accessing the CSPRNG:

- getrandom(): A system call which provides random data from the kernel CSPRNG. It will block only when the CSPRNG is not yet initialized.
- /dev/random: a file which if read from, will output data from the kernel CSPRNG. Reading from this file is blocked until the kernel estimates that enough random events have been accumulated since the last use (many details are omitted for clarity).
- /dev/urandom: a file which if read from, will provide data from the kernel CSPRNG. Reading from /dev/urandom will never block.
- AT_RANDOM: a location in process’ memory containing 16-bytes of random data; these are accessible via getauxval() and are always available.

The recommended kernel interface for Red Hat Enterprise Linux 7 is getrandom(); in the following paragraphs we will discuss the weaknesses and strengths of each interface which will make our statement above apparent.

/dev/random

This interface is described in the random(4) manpage as: “/dev/random is suitable for applications that need high-quality randomness, and can afford indeterminate delays.” The interface was designed to work even when the cryptographic primitives it depended on were broken in a catastrophic way.

In practice, because that interface depends on proven primitives like the stream cipher ChaCha20 (in the past it was SHA256), that did not prove to be a reasonable risk, and in practice its dependence on conservative randomness estimation which blocks indefinitely made it unsuitable for applications. Putting its threat model in contrast with existing applications, if the /dev/random threat model applies, the majority of the protocols and algorithms that take advantage of the random generator are already untrustworthy as they depend on the same primitives.

As such, due to its unpredictable semantics, we do not recommend the use of that interface in any scenario.

/dev/urandom

The device /dev/urandom provides access to the same random generator, however it will never block, nor apply any restrictions to the amount of new random events that must be mixed in the kernel entropy pool in order to provide any output. That is quite natural given that the cryptographic primitives used by the Linux kernel random generator, when initialized, can provide enormous amounts (practically unlimited) of output prior to being considered insecure in an informational-theory sense.

Unfortunately /dev/urandom has a quite important flaw. If used early on in the boot process when the random number generator of the kernel is not fully initialized, it will still output data. The "unpredictability" or "randomness" of that data is system-specific.

AT_RANDOM

That interface provides 16-bytes of randomness to each process, following the same rules and having the same limitations as /dev/urandom above, i.e., its value may be derived from an uninitialized entropy pool. Its value remains constant for the lifetime of the process, and is shared with potential children processes after fork(). It can be accessed by using the getauxval() glibc call.

Due to the limitations above, we do not recommend the use of that interface in any scenario.

getrandom()

The getrandom() interface provides non-blocking access to kernel CSPRNG, after the kernel's entropy pool is initialized. When the entropy pool is not initialized the function blocks, making this interface suitable not only for the typical user-space application, but also for applications requiring random data early, during the system's boot process.

Another advantage of this interface is that it does not require a file descriptor to operate. That not only simplifies code using the random generator, but also makes applications more resilient when operating in chroot() environments, because it does not require the presence of a device file.
MORE:

Which CSPRNG interface should I use in my application?

How to use getrandom() in an application safely?

Don’t leave randomness to chance


https://www.redhat.com/en/blog/understanding-red-hat-enterprise-linux-random-number-generator-interface

#gnu #linux #redhat #rhel #fedora #centos #systemd #kernel #openssl #gnutls #nss #libgcrypt #crypto #random #urandom #security #privacy #programming #generator
 
Ever wondered how #Fedora Linux, #RHEL, #CentOS and #EPEL work interact and how the software flow from one to the other? Then this diagram in a slide that showed at #devconf2019 is for you Image/photo

 
#techrights and #tuxmachines are #centos (now #redhat -owned) servers, running under #alpine - in the future we intend to become completely Red Hat-free. #ibm is an enemy of #freesw and time will show the extent to which it's true.
 
10GbE #Linux Networking Performance Between #CentOS #Fedora #ClearLinux & #Debian
 
Image/photo

The simple and quick way to ~~fuck your ISP,~~ enable obfuscation, bridges and local proxy (Fedora 29 + systemd)

Part 1. Obfuscation

In network security, obfuscation refers to methods used to obscure an attack payload from inspection by network protection systems.
If you want to search something as "obfs4proxy"...
# dnf search obfs4proxy
(...)

NOTHING! Because the right name for obfuscator (v.4) is obfs4.x86_64! (or obfs4)

But don't forget: the right name of this pluggable installed transport is obfs4proxy (man obfs4proxy, etc.)

Well... Just install:
# dnf install obfs4.x86_64
Now stop tor.service:
# systemctl stop tor
... And edit tor configuration:
# nano /etc/tor/torrc
You must add two strings:
# Use obfs4proxy to provide the obfs4 protocol.
ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy

Start tor again:
# systemctl start tor
And check the efficiency:
# systemctl status tor● tor.service - Anonymizing overlay network for TCP
Loaded: loaded (/usr/lib/systemd/system/tor.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2019-01-03 12:29:51; 2min 38s ago
Process: 8045 ExecStartPre=/usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --verify-config (code=exited, status=0/SUCCESS)
Main PID: 8046 (tor)
Tasks: 1 (limit: 4201)
Memory: 29.2M
CGroup: /system.slice/tor.service
└─8046 /usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc (...)
jan 03 12:29:50 localhost.localdomain Tor[8046]: Bootstrapped 0%: Starting
jan 03 12:29:51 localhost.localdomain Tor[8046]: Starting with guard context "default"
jan 03 12:29:51 localhost.localdomain Tor[8046]: Bootstrapped 80%: Connecting to the Tor network
jan 03 12:29:51 localhost.localdomain Tor[8046]: Signaled readiness to systemd
jan 03 12:29:51 localhost.localdomain systemd[1]: Started Anonymizing overlay network for TCP.
jan 03 12:29:51 localhost.localdomain Tor[8046]: Opening Control listener on /run/tor/control
jan 03 12:29:51 localhost.localdomain Tor[8046]: Bootstrapped 85%: Finishing handshake with first hop
jan 03 12:31:37 localhost.localdomain Tor[8046]: Bootstrapped 90%: Establishing a Tor circuit
jan 03 12:31:49 localhost.localdomain Tor[8046]: Tor has successfully opened a circuit. Looks like client functionality is working.
jan 03 12:31:49 localhost.localdomain Tor[8046]: Bootstrapped 100%: Done

Part 2. Enable bridges

Bridge relays (or "bridges" for short) are relays that aren't listed in the main directory. Since there is no complete public list of them, even if your ISP is filtering connections to all the known relays, they probably won't be able to block all the bridges. If you suspect your access to the Tor network is being blocked, you may want to use bridges.
Firstly, get the bridges (if it's possible).

Secondly, stop tor.service again:
# systemctl stop tor
Edit tor configuration:
# nano /etc/tor/torrc
Enable bridges (just add this string):
UseBridges 1
Then add some strings below (type of obfuscation, server's IP and port, cert., mode, etc.), for example:
obfs4 192.000.000.000:9443 79E9704E7061819(...) cert=wTk9WGFM0(...) iat-mode=0

obfs4 153.000.000.000:44249 51E81FB1A3F4F(...) cert=NaFBvtCH5wc(...) iat-mode=0

obfs4 176.000.000.000:9002 8DC46911B3DBC5C(...) cert=36aqRi8iive(...) iat-mode=0

If you want, insert and enable this option too:
UpdateBridgesFromAuthority 1
N.B.!

- UseBridges 0|1
When set, Tor will fetch descriptors for each bridge listed in the "Bridge" config lines, and use these relays as both entry guards and directory guards. (Default: 0)

- UpdateBridgesFromAuthority 0|1
When set (along with UseBridges), Tor will try to fetch bridge descriptors from the configured bridge authorities when feasible. It will fall back to a direct request if the authority responds with a 404. (Default: 0)
Start tor again:
# systemctl start tor

Part 3. Connect your browser (mail-client, jabber-client, rss-client)


Unfortunately, the development of the lightweight #polipo (local proxy) is dead! Now I am using #privoxy.
Privoxy is a free non-caching web proxy with filtering capabilities for enhancing privacy, manipulating cookies and modifying web page data and HTTP headers before the page is rendered by the browser. Privoxy is a "privacy enhancing proxy", filtering web pages and removing advertisements. Privoxy can be customized by users, for both stand-alone systems and multi-user networks. Privoxy can be chained to other proxies and is frequently used in combination with Squid and can be used to bypass Internet censorship.
# dnf install privoxy

# systemctl enable privoxy

Created symlink /etc/systemd/system/multi-user.target.wants/privoxy.service → /usr/lib/systemd/system/privoxy.service.

# nano /etc/privoxy/config

You must uncomment only one(!) string:
forward-socks5 / 127.0.0.1:9050 .
Start privoxy as a service:
# systemctl start privoxy

Now you must edit your browser (email-client, rss-aggregator, etc.) settings:

127.0.0.1:8118

... and...

Don't forget about possible client's DNS-leaks and use global system dnscrypt-proxy in any case: https://diasp.org/posts/a02706b0efe301367610047d7b62795e


MORE:
man tor
man obfs4proxy
man privoxy

#gnu #linux #redhat #centos #fedora #privacy #security #anonymity #man #manual #config #tor #onion #router #privoxy #systemd #systemctl #service #obfuscation #bridge #proxy #transport #obfs4proxy #obfs #obfs4 #relay #network #www #internet #isp #dnscrypt #dnscrypt-proxy #dns #dnssec #doh #server #console #terminal #bash
 
Image/photo

The simple and quick way to ~~fuck your ISP,~~ enable obfuscation, bridges and local proxy (Fedora 29 + systemd)

Part 1. Obfuscation

In network security, obfuscation refers to methods used to obscure an attack payload from inspection by network protection systems.
If you want to search something as "obfs4proxy"...
# dnf search obfs4proxy
(...)

NOTHING! Because the right name for obfuscator (v.4) is obfs4.x86_64! (or obfs4)

But don't forget: the right name of this pluggable installed transport is obfs4proxy (man obfs4proxy, etc.)

Well... Just install:
# dnf install obfs4.x86_64
Now stop tor.service:
# systemctl stop tor
... And edit tor configuration:
# nano /etc/tor/torrc
You must add two strings:
# Use obfs4proxy to provide the obfs4 protocol.
ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy

Start tor again:
# systemctl start tor
And check the efficiency:
# systemctl status tor● tor.service - Anonymizing overlay network for TCP
Loaded: loaded (/usr/lib/systemd/system/tor.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2019-01-03 12:29:51; 2min 38s ago
Process: 8045 ExecStartPre=/usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --verify-config (code=exited, status=0/SUCCESS)
Main PID: 8046 (tor)
Tasks: 1 (limit: 4201)
Memory: 29.2M
CGroup: /system.slice/tor.service
└─8046 /usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc (...)
jan 03 12:29:50 localhost.localdomain Tor[8046]: Bootstrapped 0%: Starting
jan 03 12:29:51 localhost.localdomain Tor[8046]: Starting with guard context "default"
jan 03 12:29:51 localhost.localdomain Tor[8046]: Bootstrapped 80%: Connecting to the Tor network
jan 03 12:29:51 localhost.localdomain Tor[8046]: Signaled readiness to systemd
jan 03 12:29:51 localhost.localdomain systemd[1]: Started Anonymizing overlay network for TCP.
jan 03 12:29:51 localhost.localdomain Tor[8046]: Opening Control listener on /run/tor/control
jan 03 12:29:51 localhost.localdomain Tor[8046]: Bootstrapped 85%: Finishing handshake with first hop
jan 03 12:31:37 localhost.localdomain Tor[8046]: Bootstrapped 90%: Establishing a Tor circuit
jan 03 12:31:49 localhost.localdomain Tor[8046]: Tor has successfully opened a circuit. Looks like client functionality is working.
jan 03 12:31:49 localhost.localdomain Tor[8046]: Bootstrapped 100%: Done

Part 2. Enable bridges

Bridge relays (or "bridges" for short) are relays that aren't listed in the main directory. Since there is no complete public list of them, even if your ISP is filtering connections to all the known relays, they probably won't be able to block all the bridges. If you suspect your access to the Tor network is being blocked, you may want to use bridges.
Firstly, get the bridges (if it's possible).

Secondly, stop tor.service again:
# systemctl stop tor
Edit tor configuration:
# nano /etc/tor/torrc
Enable bridges (just add this string):
UseBridges 1
Then add some strings below (type of obfuscation, server's IP and port, cert., mode, etc.), for example:
obfs4 192.xxx.xxx.xxx:9443 79E9704E7061819(...) cert=wTk9WGFM0(...) iat-mode=0

obfs4 153.xxx.xxx.xxx:44249 51E81FB1A3F4F(...) cert=NaFBvtCH5wc(...) iat-mode=0

obfs4 176.xxx.xxx.xxx:9002 8DC46911B3DBC5C(...) cert=36aqRi8iive(...) iat-mode=0

If you want, insert and enable this option too:
UpdateBridgesFromAuthority 1
N.B.!

- UseBridges 0|1
When set, Tor will fetch descriptors for each bridge listed in the "Bridge" config lines, and use these relays as both entry guards and directory guards. (Default: 0)

- UpdateBridgesFromAuthority 0|1
When set (along with UseBridges), Tor will try to fetch bridge descriptors from the configured bridge authorities when feasible. It will fall back to a direct request if the authority responds with a 404. (Default: 0)
Start tor again:
# systemctl start tor

Part 3. Connect your browser (mail-client, jabber-client, rss-client)


Unfortunately, the development of the lightweight #polipo (local proxy) is dead! Now I am using #privoxy.
Privoxy is a free non-caching web proxy with filtering capabilities for enhancing privacy, manipulating cookies and modifying web page data and HTTP headers before the page is rendered by the browser. Privoxy is a "privacy enhancing proxy", filtering web pages and removing advertisements. Privoxy can be customized by users, for both stand-alone systems and multi-user networks. Privoxy can be chained to other proxies and is frequently used in combination with Squid and can be used to bypass Internet censorship.
# dnf install privoxy

# systemctl enable privoxy

Created symlink /etc/systemd/system/multi-user.target.wants/privoxy.service → /usr/lib/systemd/system/privoxy.service.

# nano /etc/privoxy/config

You must uncomment only one(!) string:
forward-socks5 / 127.0.0.1:9050 .
Start privoxy as a service:
# systemctl start privoxy

Now you must edit your browser (email-client, rss-aggregator, etc.) settings:

127.0.0.1:8118

... and...

Don't forget about possible client's DNS-leaks and use global system dnscrypt-proxy in any case: https://diasp.org/posts/a02706b0efe301367610047d7b62795e


MORE:
man tor
man obfs4proxy
man privoxy

#gnu #linux #redhat #centos #fedora #privacy #security #anonymity #man #manual #config #tor #onion #router #privoxy #systemd #systemctl #service #obfuscation #bridge #proxy #transport #obfs4proxy #obfs #obfs4 #relay #network #www #internet #isp #dnscrypt #dnscrypt-proxy #dns #dnssec #doh #server #console #terminal #bash
 
The Italian #centos based NethServer 7.6 is released
Home page
 
WLinux Enterprise: Start-up bringt RHEL-Klon auf Windows-Subsystem für Linux #Linux #CentOS #RHEL #RedHat #Windows #OpenSource
 
Verdammt, das ist jetzt schon das zweite System, auf dem nach einem Update oder Upgrade der #openvpn - Client via #NetworkManager nicht mehr funktioniert. #CentOS und #Fedora

Es scheitert am 'TLS handshake error' und scheint am NetworkManager zu liegen, denn ein nativer openvpn-Client funktioniert problemlos. WTF!?!
Germany 
New: #CentOS 7-1810 "Gnome" overview | The community enterprise operating system #redhat #gnu #linux
 
Uff, keine Probleme beim Upgrade auf #CentOS 7.6. Immer wieder schön, wenn ein Systemupgrade problemlos durchläuft.

Einen Schritt weiter zur Weltherrschaft:
# yum history info 42 | grep -A1 prosody
Aktualisiert prosody-0.10.2-3.el7.x86_64 @epel
Aktualisieren 0.11.0-1.el7.x86_64 @epel

Läuft...

#Prosody
Germany 
#opensource #CentOS
 
No, #OpenShift and #Ansible are not #redhat crown jewels; #RHEL is. And its derivs, e.g. #centos https://www.computerdealernews.com/news/ibms-acquisition-of-red-hat-gives-them-access-to-crown-jewels-openshift-and-ansible/62950 #ibm
IBM’s acquisition of Red Hat gives them access to crown jewels: OpenShift and Ansible
 

Fedora 29: Freigabe Swapspace?

Hhmm, nun habe ich die Migration von #CentOS nach #Fedora abgeschlossen - auf einem 12 Jahre alten PC.

Zuvor habe ich diesen Schritt schon mehrfach gemacht auf jüngerer Hardware, und es gab keine Probleme. Aber bei diesem PC fühlt es sich doch deutlich zäher an.

Ein Blick in die Prozessliste (htop) zeigt, dass über längere Zeit 1,5 von 4 G Swapspace belegt sind, obwohl im selben Zeitraum noch ~1,8 von 4G Memory frei sind. Auch der Ressourcen-Monitor von Gnome sagt, dass 37% geswapped werden - konstant.

AFAIK wurde das früher(c) dynamisch gehandelt - sprich, dass der Swap-Space auch wieder freigegeben wurde, wenn er nicht mehr benötigt wird.

Hat sich daran was geändert? Wie kann feststellen, ob das System tatsächlich swappt (und dies überhaupt mein Problem ist)?
TNX
Germany 
Lost an hour today diagnosing server issues; ended up having to reboot after 5 months' uptime. But at least it's back in good shape now: #centos #gnu #linux
 
Side note reminder: I'm posting about stuff from the #RedHat #CentOS and #fedora universe on a different account these days. So if you are interested in topics from that universe you better follow ! And if you are interested in gnome topics, follow !
https://twitter.com/knurd42rhfc/status/1060218159351980032 #FOSDEM
 
Schedule, Registration now available for #CentOS Dojo at #FOSDEM https://t.co/Ibs3Dl6TKu "[…] Details, and the schedule, are now available at wiki.centos.org/Events/Dojo/Br… (Schedule subject to change). Registration is free, but we need to know how many people are coming, […]"

 
4 Stunden! Diese Zeit habe ich heute mit wachsender Verzweiflung damit verbracht, zu ergründen, warum #seahorse nach einer Migration von #CentOS nach #Fedora meine Passworte nicht mehr rausrückt. Also alle Passworte für alles...

Erst als auch das Restore aus dem Backup nix brachte, kam ich auf den Trichter, dass es dort (neu?) einen Filter im UI gibt. Ratet mal, was ich sehe, wenn 'Alles anzeigen' ausgewählt wird!?!

Vier Stunden - ARRGGHHHH

Warnung: Klugscheisser-Kommentare nur mit Schutzanzug!

#EinmalMitProfis #WTF
Germany 
Das #EPEL mal so bei uns im Ticker erwähnt würde, hätte ich auch nicht gedacht, als einige #Fedora-Leute und ich das für #RHEL und #CentOS gedachte Repository vor zirka zehn Jahren gestartet haben… heise.de/newsticker/mel…

 
JFYI for those that do not know yet: I build #Linux vanilla kernel packages for Fedora. Won't normally tweet about those here, as I leave tweets from the #redhat, #centos and #fedora universe to my alter ego For even more alter egos see leemhuis.info/me/
https://twitter.com/knurd42rhfc/status/1059547982016757760 #kernel #Fedora
 
Parallel-Installation ging fix und problemlos, aber die einzelnen Application-Configs zu migrieren wird noch dauern. Das liegt daran, dass die Versionen sich zwischen #CentOS und #Fedora doch erheblich unterscheiden.

Da muss ich jetzt wohl durch...

Immerhin läuft der Firefox mit #Friendica schon wieder:
Hello World!
 
#IBM übernimmt #RedHat. Sehe ich sehr skeptisch, vor allem in Bezug auf Engagement bei der freien Software und #Fedora + #CentOS. Ich bin alt genug um mich zu erinnern, dass IBM mit OS/2 schon mal ein Betriebssystem an die Wand gefahren hat.
 
Ich nehme das mal als Anlass, meine verbleibenden Desktop-Systeme von #CentOS auf #Fedora zu migrieren. Die sind schon lange bei #Wayland.

Ursächlich ist aber der Wunsch nach aktuellerer Software und das Vertrauen, welches ich mittlerweile in den Upgrade-Prozess von Fedora entwickelt habe. #security #GNU/Linux #X.org
Germany 

OpenIT CentOS box runs for 1174 days

Not close to the 3.12 #NetWare server has made, 16.5 years of up-time. But today I found here #atwork a server that runs #CentOS on it and has an up-time of almost 1175 days. See this screenshot for details:
Image/photo
Sad to know that this server is being cancel (contract), I see no real reason why? Also the new server ( #Mittwald ) has down-times ...
 
newer older