Category: News
How to encrypt etcd and use secrets in OpenShift
Secrets contain sensitive information, but they aren’t encrypted by default. Learn how to encrypt an etcd database to manage vital information in OpenShift. Read More at Enable Sysadmin
The post How to encrypt etcd and use secrets in OpenShift appeared first on Linux.com.
Simon Josefsson: Privilege separation of GSS-API credentials for Apache
To protect web resources with Kerberos you may use Apache HTTPD with mod_auth_gssapi — however, all web scripts (e.g., PHP) run under Apache will have access to the Kerberos long-term symmetric secret credential (keytab). If someone can get it, they can impersonate your server, which is bad.
The gssproxy project makes it possible to introduce privilege separation to reduce the attack surface. There is a tutorial for RPM-based distributions (Fedora, RHEL, AlmaLinux, etc), but I wanted to get this to work on a DPKG-based distribution (Debian, Ubuntu, Trisquel, PureOS, etc) and found it worthwhile to document the process. I’m using Ubuntu 22.04 below, but have tested it on Debian 11 as well. I have adopted the gssproxy package in Debian, and testing this setup is part of the scripted autopkgtest/debci regression testing.
First install the required packages:
root@foo:~# apt-get update
root@foo:~# apt-get install -y apache2 libapache2-mod-auth-gssapi gssproxy curl
This should give you a working and running web server. Verify it is operational under the proper hostname, I’ll use foo.sjd.se
in this writeup.
root@foo:~# curl --head http://foo.sjd.se/
HTTP/1.1 200 OK
…
The next step is to create a keytab containing the Kerberos V5 secrets for your host, the exact steps depends on your environment (usually kadmin ktadd
or ipa-getkeytab
), but use the string “HTTP/foo.sjd.se
” and then confirm using something like the following.
root@foo:~# ls -la /etc/gssproxy/httpd.keytab
-rw------- 1 root root 176 Sep 18 06:44 /etc/gssproxy/httpd.keytab
root@foo:~# klist -k /etc/gssproxy/httpd.keytab -e
Keytab name: FILE:/etc/gssproxy/httpd.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 HTTP/foo.sjd.se@GSSPROXY.EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 HTTP/foo.sjd.se@GSSPROXY.EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
root@foo:~#
The file should be owned by root and not be in the default /etc/krb5.keytab
location, so Apache’s libapache2-mod-auth-gssapi
will have to use gssproxy to use it.
Then configure gssproxy to find the credential and use it with Apache.
root@foo:~# cat<<EOF > /etc/gssproxy/80-httpd.conf
[service/HTTP]
mechs = krb5
cred_store = keytab:/etc/gssproxy/httpd.keytab
cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
euid = www-data
process = /usr/sbin/apache2
EOF
For debugging, it may be useful to enable more gssproxy
logging:
root@foo:~# cat<<EOF > /etc/gssproxy/gssproxy.conf
[gssproxy]
debug_level = 1
EOF
root@foo:~#
Restart gssproxy so it finds the new configuration, and monitor syslog as follows:
root@foo:~# tail -F /var/log/syslog &
root@foo:~# systemctl restart gssproxy
You should see something like this in the log file:
Sep 18 07:03:15 foo gssproxy[4076]: [2022/09/18 05:03:15]: Exiting after receiving a signal
Sep 18 07:03:15 foo systemd[1]: Stopping GSSAPI Proxy Daemon…
Sep 18 07:03:15 foo systemd[1]: gssproxy.service: Deactivated successfully.
Sep 18 07:03:15 foo systemd[1]: Stopped GSSAPI Proxy Daemon.
Sep 18 07:03:15 foo gssproxy[4092]: [2022/09/18 05:03:15]: Debug Enabled (level: 1)
Sep 18 07:03:15 foo systemd[1]: Starting GSSAPI Proxy Daemon…
Sep 18 07:03:15 foo gssproxy[4093]: [2022/09/18 05:03:15]: Kernel doesn't support GSS-Proxy (can't open /proc/net/rpc/use-gss-proxy: 2 (No such file or directory))
Sep 18 07:03:15 foo gssproxy[4093]: [2022/09/18 05:03:15]: Problem with kernel communication! NFS server will not work
Sep 18 07:03:15 foo systemd[1]: Started GSSAPI Proxy Daemon.
Sep 18 07:03:15 foo gssproxy[4093]: [2022/09/18 05:03:15]: Initialization complete.
The NFS-related errors is due to a default gssproxy configuration file, it is harmless and if you don’t use NFS with GSS-API you can silence it like this:
root@foo:~# rm /etc/gssproxy/24-nfs-server.conf
root@foo:~# systemctl try-reload-or-restart gssproxy
The log should now indicate that it loaded the keytab:
Sep 18 07:18:59 foo systemd[1]: Reloading GSSAPI Proxy Daemon…
Sep 18 07:18:59 foo gssproxy[4182]: [2022/09/18 05:18:59]: Received SIGHUP; re-reading config.
Sep 18 07:18:59 foo gssproxy[4182]: [2022/09/18 05:18:59]: Service: HTTP, Keytab: /etc/gssproxy/httpd.keytab, Enctype: 18
Sep 18 07:18:59 foo gssproxy[4182]: [2022/09/18 05:18:59]: New config loaded successfully.
Sep 18 07:18:59 foo systemd[1]: Reloaded GSSAPI Proxy Daemon.
To instruct Apache — or actually, the MIT Kerberos V5 GSS-API library used by mod_auth_gssap loaded by Apache — to use gssproxy instead of using /etc/krb5.keytab
as usual, Apache needs to be started in an environment that has GSS_USE_PROXY=1
set. The background is covered by the gssproxy-mech(8) man page and explained by the gssproxy README.
When systemd is used the following can be used to set the environment variable, note the final command to reload systemd.
root@foo:~# mkdir -p /etc/systemd/system/apache2.service.d
root@foo:~# cat<<EOF > /etc/systemd/system/apache2.service.d/gssproxy.conf
[Service]
Environment=GSS_USE_PROXY=1
EOF
root@foo:~# systemctl daemon-reload
The next step is to configure a GSS-API protected Apache resource:
root@foo:~# cat<<EOF > /etc/apache2/conf-available/private.conf
<Location /private>
AuthType GSSAPI
AuthName "GSSAPI Login"
Require valid-user
</Location>
Enable the configuration and restart Apache — the suggested use of reload is not sufficient, because then it won’t be restarted with the newly introduced GSS_USE_PROXY
variable. This just applies to the first time, after the first restart you may use reload again.
root@foo:~# a2enconf private
Enabling conf private.
To activate the new configuration, you need to run:
systemctl reload apache2
root@foo:~# systemctl restart apache2
When you have debug messages enabled, the log may look like this:
Sep 18 07:32:23 foo systemd[1]: Stopping The Apache HTTP Server…
Sep 18 07:32:23 foo gssproxy[4182]: [2022/09/18 05:32:23]: Client [2022/09/18 05:32:23]: (/usr/sbin/apache2) [2022/09/18 05:32:23]: connected (fd = 10)[2022/09/18 05:32:23]: (pid = 4651) (uid = 0) (gid = 0)[2022/09/18 05:32:23]:
Sep 18 07:32:23 foo gssproxy[4182]: message repeated 4 times: [ [2022/09/18 05:32:23]: Client [2022/09/18 05:32:23]: (/usr/sbin/apache2) [2022/09/18 05:32:23]: connected (fd = 10)[2022/09/18 05:32:23]: (pid = 4651) (uid = 0) (gid = 0)[2022/09/18 05:32:23]:]
Sep 18 07:32:23 foo systemd[1]: apache2.service: Deactivated successfully.
Sep 18 07:32:23 foo systemd[1]: Stopped The Apache HTTP Server.
Sep 18 07:32:23 foo systemd[1]: Starting The Apache HTTP Server…
Sep 18 07:32:23 foo gssproxy[4182]: [2022/09/18 05:32:23]: Client [2022/09/18 05:32:23]: (/usr/sbin/apache2) [2022/09/18 05:32:23]: connected (fd = 10)[2022/09/18 05:32:23]: (pid = 4657) (uid = 0) (gid = 0)[2022/09/18 05:32:23]:
root@foo:~# Sep 18 07:32:23 foo gssproxy[4182]: message repeated 8 times: [ [2022/09/18 05:32:23]: Client [2022/09/18 05:32:23]: (/usr/sbin/apache2) [2022/09/18 05:32:23]: connected (fd = 10)[2022/09/18 05:32:23]: (pid = 4657) (uid = 0) (gid = 0)[2022/09/18 05:32:23]:]
Sep 18 07:32:23 foo systemd[1]: Started The Apache HTTP Server.
Finally, set up a dummy test page on the server:
root@foo:~# echo OK > /var/www/html/private
To verify that the server is working properly you may acquire tickets locally and then use curl to retrieve the GSS-API protected resource. The "--negotiate"
enables SPNEGO and "--user :"
asks curl to use username from the environment.
root@foo:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: jas@GSSPROXY.EXAMPLE.ORG
Valid starting Expires Service principal
09/18/22 07:40:37 09/19/22 07:40:37 krbtgt/GSSPROXY.EXAMPLE.ORG@GSSPROXY.EXAMPLE.ORG
root@foo:~# curl --negotiate --user : http://foo.sjd.se/private
OK
root@foo:~#
The log should contain something like this:
Sep 18 07:56:00 foo gssproxy[4872]: [2022/09/18 05:56:00]: Client [2022/09/18 05:56:00]: (/usr/sbin/apache2) [2022/09/18 05:56:00]: connected (fd = 10)[2022/09/18 05:56:00]: (pid = 5042) (uid = 33) (gid = 33)[2022/09/18 05:56:00]:
Sep 18 07:56:00 foo gssproxy[4872]: [CID 10][2022/09/18 05:56:00]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "HTTP", euid: 33,socket: (null)
Sep 18 07:56:00 foo gssproxy[4872]: [CID 10][2022/09/18 05:56:00]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "HTTP", euid: 33,socket: (null)
Sep 18 07:56:00 foo gssproxy[4872]: [CID 10][2022/09/18 05:56:00]: gp_rpc_execute: executing 1 (GSSX_INDICATE_MECHS) for service "HTTP", euid: 33,socket: (null)
Sep 18 07:56:00 foo gssproxy[4872]: [CID 10][2022/09/18 05:56:00]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "HTTP", euid: 33,socket: (null)
Sep 18 07:56:00 foo gssproxy[4872]: [CID 10][2022/09/18 05:56:00]: gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "HTTP", euid: 33,socket: (null)
The Apache log will look like this, notice the authenticated username shown.
127.0.0.1 - jas@GSSPROXY.EXAMPLE.ORG [18/Sep/2022:07:56:00 +0200] "GET /private HTTP/1.1" 200 481 "-" "curl/7.81.0"
Congratulations, and happy hacking!
Announcing the Launch of the Chrome Root Program
In 2020, we announced we were in the early phases of establishing the Chrome Root Program and launching the Chrome Root Store.
The Chrome Root Program ultimately determines which website certificates are trusted by default in Chrome, and enables more consistent and reliable website certificate validation across platforms.
This post shares an update on our progress and how these changes help us better protect Chrome’s users.
What’s a root store or root program, anyway?
Chrome uses digital certificates (often referred to as “certificates,” “HTTPS certificates,” or “server authentication certificates”) to ensure the connections it makes on behalf of its users are secure and private. Certificates are responsible for binding a domain name to a public key, which Chrome uses to encrypt data sent to and from the corresponding website.
As part of establishing a secure connection to a website, Chrome verifies that a recognized entity known as a “Certification Authority” (CA) issued its certificate. Certificates issued by a CA not recognized by Chrome or a user’s local settings can cause users to see warnings and error pages.
Root stores, sometimes called “trust stores”, tell operating systems and applications what certification authorities to trust. The Chrome Root Store contains the set of root CA certificates Chrome trusts by default.
A root program is a governance structure that establishes the requirements and security review functions needed to manage the corresponding root store. Members of the Chrome Security Team are responsible for the Chrome Root Program. Our program policy, which establishes the minimum requirements for CAs to be included in the Chrome Root Store, is publicly available here.
Why is Chrome making these changes?
Historically, Chrome integrated with the root store and certificate verification process provided by the platform on which it was running. Standardizing the set of CAs trusted by Chrome across platforms through the transition to the Chrome Root Store, coupled with a consistent certificate verification experience through the use of the Chrome Certificate Verifier, will result in more consistent user and developer experiences.
Launching the Chrome Root Program also represents our ongoing commitment to participating in and improving the Web PKI ecosystem. Innovations like ACME have made it easier than ever for website owners to obtain HTTPS certificates. Technologies like Certificate Transparency promote increased accountability and transparency, further improving security for Chrome’s users. These enhancements, only made possible through community collaboration, make the web a safer place. However, there’s still more work to be done.
We want to work alongside CA owners to define and operationalize the next generation of the Web PKI. Our vision for the future includes modern, reliable, highly agile, purpose-driven PKIs that promote automation, simplicity, and security – and we formed the Chrome Root Program and corresponding policy to achieve these goals.
When are these changes taking place?
A “rollout” is a gradual launch of a new feature. Sometimes, to ensure it goes smoothly, we don’t enable a new feature for all of our users at once. Instead, we start with a small percentage of users and increase that percentage over time to ensure we minimize unanticipated compatibility issues. The Chrome Root Store and Certificate Verifier began rolling out on Windows and macOS in Chrome 105, with other platforms to follow.
Testing ahead of the rollout described above is possible on Windows and macOS using these instructions.
Will these changes impact me?
We expect the transition to the Chrome Root Store and Certificate Verifier to be seamless for most users, enterprises, and CA owners.
The Chrome Certificate Verifier considers locally-managed certificates during the certificate verification process. This means if an enterprise distributes a root CA certificate as trusted to its users (for example, by a Windows Group Policy Object), it will be considered trusted in Chrome.
Troubleshooting procedures and other frequently asked questions are available here.
What’s next?
While we don’t know exactly what the future of the Web PKI will look like, we remain focused on promoting changes that increase speed, security, stability, and simplicity throughout the ecosystem.
With that in mind, the Chrome team continues to explore introducing future root program policy requirements related to the following initiatives:
-
Encouraging modern infrastructures and agility
-
Focusing on simplicity
-
Promoting automation
-
Reducing mis-issuance
-
Increasing accountability and ecosystem integrity
-
Streamlining and improving domain validation practices
-
Preparing for a “post-quantum” world
We look forward to continuing our collaboration with members of the CA/Browser Forum and other Web PKI ecosystem participants to make the Internet a safer place.
Unicode 15.0.0 adds more eyes to ꙮ
Viral Video | Dad Jumps in to Join Daughter Dancing Without Partner on Stage in School Function
Argus News is Odisha’s fastest-growing news channel having its presence on satellite TV and various web platforms. Watch the latest news updates LIVE on matters related to politics, sports, gadgets, business, entertainment, and more. Argus News is setting new standards for journalism through its differentiated programming, philosophy, and tagline ‘Satyara Sandhana’.
To stay updated on-the-go,
Visit Our Official Website: www.argusnews.in
iOS App: http://bit.ly/ArgusNewsiOSApp
Android App: http://bit.ly/ArgusNewsAndroidApp
Live TV: https://argusnews.in/live-tv/
Facebook: https://www.facebook.com/argusnews.in
YouTube: www.youtube.com/c/TheArgusNewsOdia
Twitter: https://twitter.com/ArgusNews_in
Instagram: https://www.instagram.com/argusnewsin
Argus News Is Available on:
TataPlay channel No – 1780
Airtel TV channel No – 609
Dish TV channel No – 1369
d2h channel No – 1757
SITI Networks – 18
Hathway – 732
GTPL KCBPL – 713
& other Leading Cable Networks please visit https://argusnews.in/channel_number for channel number list
You Can WhatsApp Us Your News On- 8480612900
#Viralvideo #fatherdaughterduo #love #Dad #Daughter #Argusnews #Argusenglish
Sistema de Luz Inteligente con Arduino y Tinkercad
Código de programación de este video: https://github.com/MauroMA-99/Archivos_Arduino_Educatronicos/tree/main/sistema_de_luz_inteligente_21
Marcas de tiempo:
00:00 Introducción
00:27 Diseño en 3D en Tinkercad
01:12 Programación en Arduino
09:55 Simulación en Tinkercad
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
NUESTRAS REDES SOCIALES
► Síguenos en Facebook: https://www.facebook.com/MajeltronicGroup
► Síguenos en Instagram: https://www.instagram.com/majeltronic_group/?hl=es-la
► Visita nuestro Blog: https://educatronicosisc.blogspot.com/
► Suscríbete a nuestro canal de YT: https://www.youtube.com/channel/UC93Nt6sA-7r_S7EtGO44GeA
İSTANBUL CHALLENGER TED OPEN ULUSLARARASI TENİS TURNUVASI’NDA ŞAMPİYON RADU ALBOT OLDU
Bu yıl QNB Finansbank’ın katkılarıyla 74. kez düzenlenen turnuvada tek erkekler finalinde şampiyon Moldovalı tenisçi Radu Albot oldu.
Türkiye’nin en köklü spor organizasyonlarından biri olan İstanbul Challenger TED Open Uluslararası Tenis Turnuvası sona erdi. Bu yıl QNB Finansbank’ın katkılarıyla 74. kez Tenis Eskrim Dağcılık (TED) Spor Kulübü’nün ev sahipliğinde düzenlenen turnuvada yıldızlar sahne aldı. Eleme turu, ana-tablo ve çiftler de dahil olmak üzere 8 gün içerisinde 3 set üzerinden 74 maç oynandığı İstanbul Challenger TED Open Uluslararası Tenis Turnuvası’nda finalde Lukas Rosol (Çekya) ve Radu Albot (Moldova) karşı karşıya geldi.
Kıyasıya rekabetle geçen final maçında rakibini setlerde 2-0 yenen Radu Albot şampiyon oldu. Final maçının ardından ödül töreni düzenlendi.
https://www.haberler.com/spor/istanbul-challenger-ted-open-da-moldovali-tenisci-15289330-haberi/
How to get or register a domain for free | Free domain | WordPress tutorial
It’s totally free for 1 year after 1 year you can renew it for free
Hurry up and avail this bumper offer
Website link ▶️ https://www.freenom.com
Also, check out the video in which free hosting provide
.
.
.
LIKE — COMMENT– SHARE– SUBSCRIBE
.
.
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
FOLLOW US ON SOCIAL
Get updates or reach out to Get updates on our Social Media Profiles!
➡️Twitter: https://twitter.com/MAsadSattar5
➡️Facebook: https://web.facebook.com/asadsattar768
➡️Facebook page: https://web.facebook.com/asadseoexpert/
➡️Instagram: https://www.instagram.com/asadsattar768/
➡️Linkdin: https://www.linkedin.com/in/asad-sattar-4439b123b/
| Thanks |