Home Blog Page 49

How to fix permission errors in pods using service accounts

Learn how to change a default security context constraint (SCC) in OpenShift to manage permissions within a cluster.

Read More at Enable Sysadmin

Secure Coding Practice – A Developer’s Learning Experience of Developing Secure Software Course – Linux Foundation

The original article appeared on the OpenSSF blog. The author, Harimohan Rajamohanan, is a Solution Architect and Full Stack Developer with Wipro Limited. Learn more about the Linux Foundation’s Developing Secure Software (LFD121) course

All software is under continuous attack today, so software architects and developers should focus on practical steps to improve information security. There are plenty of materials available online that talk about various aspects of secure development practices, but they are scattered across various articles and books. Recently, I had come across a course developed by the Open Source Security Foundation (OpenSSF), which is a part of the Linux Foundation, that is geared towards software developers, DevOps professionals, web application developers and others interested in learning the best practices of secure software development. My learning experience taking the DEVELOPING SECURE SOFTWARE (LFD121) course was positive, and I immediately started applying these learnings in my work as a software architect and developer.

“A useful trick for creating secure systems is to think like an attacker before you write the code or make a change to the code” – DEVELOPING SECURE SOFTWARE (LFD121)

My earlier understanding about software security was primarily focused on the authentication and the authorization of users. In this context the secure coding practices I was following were limited to:

No unauthorized read
No unauthorized modification
Ability to prove someone did something
Auditing and logging

It may not be broad enough to assume a software is secure if a strong authentication and authorization mechanism is present. Almost all application development today depends on open source software and it is important that developers verify the security of the open source chain of contributors and its dependencies. Recent vulnerability disclosures and supply chain attacks were an eye opener for me about the existing potential of vulnerabilities in open source software. The natural focus of majority of developers is to get the business logic working and deliver the code without any functional bugs.

The course gave me a comprehensive outlook on the secure development practices one should follow to defend from the kind of attacks that happen in modern day software.

What does risk management really mean?

The course has detailed practical advice on considering security as part of the requirements of a system. Being part of various global system integrators for over a decade, I was tasked to develop application software for my customers. The functional requirements were typically written down in such projects but covered only a few aspects of security in terms of user authentication and authorization. Documenting the security requirement in detail will help developers and future maintainers of the software to have an idea of what the system is trying to accomplish for security.

Key takeaways on risk assessment:

Analyze security basics including risk management, the “CIA” triad, and requirements
Apply secure design principles such as least privilege, complete mediation, and input validation
Supply chain evaluation tips on how to reuse software with security in mind, including selecting, downloading, installing, and updating such software
Document the high-level security requirements in one place

Secure design principles while designing a software solution

Design principles are guides based on experience and practice. The software will generally be secure if you apply the secure design principles. This course covers a broad spectrum of design principles in terms of the components you trust and the components you do not trust. The key principles I learned from the course that guide me in my present-day software design areas are:

The user and program should operate using the least privilege. This limits the damage from error or attack.
Every data access or manipulation attempt should be verified and authorized using a mechanism that cannot be bypassed.
Access to systems should be based on more than one condition. How do you prove the identity of the authenticated user is who they claimed to be? Software should support two-factor authentication.
The user interface should be designed for ease of use to make sure users routinely and automatically use the protection mechanisms correctly.
Importance of understanding what kind of attackers you expect to counter.

A few examples on how I applied the secure design principles in my solution designs:

The solutions I build often use a database. I have used the SQL GRANT command to limit the privilege the program gets. In particular, the DELETE privilege is not given to any program. And I have implemented a soft delete mechanism in the program that sets the column “active = false” in the table for delete use cases.
The recent software designs I have been doing are based on microservice architecture where there is a clear separation between the GUI and backend services. Each part of the overall solution is authenticated separately. This may minimize the attack surface.
Client-side input validation is limited to counter accidental mistakes. But the actual input validation happens at the server side. The API end points validates all the inputs thoroughly before processing it. For instance, a PUT API not just validates the resource modification inputs, but also makes sure that the resource is present in the database before proceeding with the update.
Updates are allowed only if the user consuming the API is authorized to do it.
Databases are not directly accessible for use by a client application.
All the secrets like cryptographic keys and passwords are maintained outside the program in a secure vault. This is mainly to avoid secrets in source code going into version control systems.
I have started to look for OpenSSF Best Practices Badge while selecting open source software and libraries in my programs. I also look for the security posture of open source software by checking the OpenSSF scorecards score.
Another practice I follow while using open source software is to check whether the software is maintained. Are there recent releases or announcements from the community?

Secure coding practices

In my opinion, this course covers almost all aspects of secure coding practices that a developer should focus on. The key focus areas include:

Input validations
How to validate numbers
Key issues with text, including Unicode and locales
Usage of regular expression to validate text input
Importance of minimizing the attack surfaces
Secure defaults and secure startup.

For example, apply API input validation on IDs to make sure that records belonging to those IDs exists in the database. This reduces the attack surface. Also make sure first that the object in the object modify request exists in the database.

Process data securely
Importance of treating untrusted data as dangerous
Avoid default and hardcoded credentials
Understand the memory safety problems such as out-of-bounds reads or writes, double-free, and use-after-free
Avoid undefined behavior
Call out to other programs
Securely call other programs
How to counter injection attacks such as SQL injection and OS command injection
Securely handle file names and file paths
Send output
Securely send output
How to counter Cross-Site scripting (XSS) attacks
Use HTTP hardening headers including Content Security Policy (CSP)
Prevent common output related vulnerability in web applications
How to securely format strings and templates.

Conclusion

“Security is a process – a journey – and not a simple endpoint” – DEVELOPING SECURE SOFTWARE (LFD121)

This course gives a practical guidance approach for you to develop secure software while considering security requirement, secure design principles, counter common implementation mistakes, tools to detect problems before you ship the code, promptly handle vulnerability reports. I strongly recommend this course and the certification to all developers out there.

About the author

Harimohan Rajamohanan is a Solution Architect and Full Stack Developer, Open Source Program Office, Lab45, Wipro Limited. He is an open source software enthusiast and worked in areas such as application modernization, digital transformation, and cloud native computing. Major focus areas are software supply chain security and observability.

How to configure a hostname on a Linux system

Make it easier to access your Linux computer by giving it a human-friendly name that’s simpler to use than an IP address.

Read More at Enable Sysadmin

Oracle Linux and BPF

Oracle Linux contains all of the tooling

Click to Read More at Oracle Linux Kernel Development

How to deploy MicroShift on your laptop quickly

Try out MicroShift, Kubernetes optimized for small form factor and edge computing, on your local machine.

Read More at Enable Sysadmin

What’s your favorite way to edit remote files?

As a sysadmin, you spend a lot of time on somebody else’s computer. Choose your remote file-editing tools wisely!

Read More at Enable Sysadmin

Boeing joins the ELISA Project as a Premier Member to Strengthen its Commitment to Safety-Critical Applications

Boeing to lead New Aerospace Working Group

SAN FRANCISCO – August 11, 2022 –  Today, the ELISA (Enabling Linux in Safety Applications) Project announced that Boeing has joined as a Premier member, marking its commitment to Linux and its effective use in safety critical applications. Hosted by the Linux Foundation, ELISA is an open source initiative that aims to create a shared set of tools and processes to help companies build and certify Linux-based safety-critical applications and systems.

“Boeing is modernizing software to accelerate innovation and provide greater value to our customers,” said Jinnah Hosein, Vice President of Software Engineering at the Boeing Company. “The demand for safe and secure software requires rapid iteration, integration, and validation. Standardizing around open source products enhanced for safety-critical avionics applications is a key aspect of our adoption of state-of-the-art techniques and processes.”

As a leading global aerospace company, Boeing develops, manufactures and services commercial airplanes, defense products, and space systems for customers in more than 150 countries. It’s already using Linux in current avionics systems, including commercial systems certified to DO-178C Design Assurance Level D. Joining the ELISA Project will help pursue the vision for generational change in software development at Boeing. Additionally, Boeing will work with the ELISA Technical Steering Committee (TSC) to launch a new Aerospace Working Group that will work in parallel with the other working groups like automotive, medical devices, and others.

“We want to improve industry-standard tools related to certification and assurance artifacts in order to standardize improvements and contribute new features back to the open source community. We hope to leverage open source tooling (such as a cloud-based DevSecOps software factory) and industry standards to build world class software and provide an environment that attracts industry leaders to drive cultural change at Boeing,” said Hosein.

Linux is used in all major industries because it can enable faster time to market for new features and take advantage of the quality of the code development processes. Launched in February 2019, ELISA works with Linux kernel and safety communities to agree on what should be considered when Linux is used in safety-critical systems. The project has several dedicated working groups that focus on providing resources for system integrators to apply and use to analyze qualitatively and quantitatively on their systems.

“Linux has a history of being a reliable and stable development platform that advances innovation for a wide range of industries,” said Kate Stewart, Vice President of Dependable Embedded Systems at the Linux Foundation. “With Boeing’s membership, ELISA will start a new focus in the aerospace industry, which is already using Linux in selected applications. We look forward to working with Boeing and others in the aerospace sector, to build up best practices for working with Linux in this space.”

Other ELISA Project members include ADIT, AISIN AW CO., Arm, Automotive Grade Linux, Automotive Intelligence and Control of China, Banma, BMW Car IT GmbH, Codethink, Elektrobit, Horizon Robotics, Huawei Technologies, Intel, Lotus Cars, Toyota, Kuka, Linuxtronix. Mentor, NVIDIA, SUSE, Suzuki, Wind River, OTH Regensburg, Toyota and ZTE.

Upcoming ELISA Events

The ELISA Project has several upcoming events for the community to learn more or to get involved including:

ELISA Summit – Hosted virtually for participants around the world on September 7-8, this event will feature overview of the project, the mission and goals for each working group and an opportunity for attendees to ask questions and network with ELISA leaders. The schedule is now live and includes speakers from Aptiv Services Deutschland GmbH, Boeing, CodeThink, The Linux Foundation, Mobileye, Red Hat and Robert Bosch GmbH. Check out the schedule here: https://events.linuxfoundation.org/elisa-summit/program/schedule/. Registration is free and open to the public. https://elisa.tech/event/elisa-summit-virtual/ELISA Forum – Hosted in-person in Dublin, Ireland, on September 12, this event takes place the day before Open Source Summit Europe begins. It will feature an update on all of the working groups, an interactive System-Theoretic Process Analysis (STPA) use case and an Ask Me Anything session.  Pre-registration is required. To register for ELISA Forum, add it to your Open Source Summit Europe registration.Open Source Summit Europe – Hosted in-person in Dublin and virtually on September 13-16, ELISA will have two dedicated presentations about enabling safety in safety-critical applications and safety and open source software. Learn more.

For more information about ELISA, visit https://elisa.tech/.

About the Linux Foundation

Founded in 2000, the Linux Foundation and its projects are supported by more than 2,950 members. The Linux Foundation is the world’s leading home for collaboration on open source software, hardware, standards, and data. Linux Foundation projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, ONAP, Hyperledger, RISC-V, and more. The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see its trademark usage page: www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

###

The post Boeing joins the ELISA Project as a Premier Member to Strengthen its Commitment to Safety-Critical Applications appeared first on Linux Foundation.

How to integrate Active Directory Federation Services (ADFS) authentication with Red Hat SSO using SAML

Add Red Hat Single Sign-On (RHSSO) to ADFS to help improve user authentication and management.

Read More at Enable Sysadmin

Adopting Sigstore Incrementally

This post is authored by Hayden Blauzvern and originally appeared on Sigstore’s blog. Sigstore is a new standard for signing, verifying, and protecting software. It is a project of the Linux Foundation. 

Developers, package maintainers, and enterprises that would like to adopt Sigstore may already sign published artifacts. Signers may have existing procedures to securely store and use signing keys. Sigstore can be used to sign artifacts with existing self-managed, long-lived signing keys. Sigstore provides a simple user experience for signing, verification, and generating structured signature metadata for artifacts and container signatures. Sigstore also offers a community-operated, free-to-use transparency log for auditing signature generation.

Sigstore additionally has the ability to use code signing certificates with short-lived signing keys bound to OpenID Connect identities. This signing approach offers simplicity due to the lack of key management; however, this may be too drastic of a change for enterprises that have existing infrastructure for signing. This blog post outlines strategies to ease adoption of Sigstore while still using existing signing approaches.

Signing with self-managed, long-lived keys

Developers that maintain their own signing keys but want to migrate to Sigstore can first switch to using Cosign to generate a signature over an artifact. Cosign supports importing an existing RSA, ECDSA, or ED25519 PEM-encoded PKCS#1 or PKCS#8 key with cosign import-key-pair –key key.pem, and can sign and verify with cosign sign-blob –key cosign.key artifact-path and cosign verify-blob –key cosign.pub artifact-path.

Benefits

Developers can get accustomed to Sigstore tooling to sign and verify artifacts.
Sigstore tooling can be integrated into CI/CD pipelines.
For signing containers, signature metadata is published with the OCI image in an OCI registry.

Signing with self-managed keys with auditability

While maintaining their own signing keys, developers can increase auditability of signing events by publishing signatures to the Sigstore transparency log, Rekor. This allows developers to audit when signatures are generated for artifacts they maintain, and also monitor when their signing key is used to create a signature.

Developers can upload a signature to the transparency log during signing with COSIGN_EXPERIMENTAL=1 cosign sign-blob –key cosign.key artifact-path. If developers would like to use their own signing infrastructure while still publishing to a transparency log, developers can use the Rekor CLI or API. To upload an artifact and cryptographically verify its inclusion in the log using the Rekor CLI:

rekor-cli upload –rekor_server https://rekor.sigstore.dev
–signature
–public-key
–artifact <url_to_artifact|local_path></url_to_artifact|local_path>
rekor-cli verify –rekor_server https://rekor.sigstore.dev
–signature
–public-key
–artifact <url_to_artifact|local_path></url_to_artifact|local_path>

In addition to PEM-encoded certificates and public keys, Sigstore supports uploading many different key formats, including PGP, Minisign, SSH, PKCS#7, and TUF. When uploading using the Rekor CLI, specify the –pki-format flag. For example, to upload an artifact signed with a PGP key:

gpg –armor -u user@example.com –output signature.asc –detach-sig package.tar.gzgpg –export –armor “user@example.com” > public.keyrekor-cli upload –rekor_server https://rekor.sigstore.dev
–signature signature.asc
–public-key public.key
–pki-format=pgp
–artifact package.tar.gz

Benefits

Developers begin to publish signing events for auditability.
Artifact consumers can create a verification policy that requires a signature be published to a transparency log.

Self-managed keys in identity-based code signing certificate with auditability

When requesting a code signing certificate from the Sigstore certificate authority Fulcio, Fulcio binds an OpenID Connect identity to a key, allowing for a verification policy based on identity rather than a key. Developers can request a code signing certificate from Fulcio with a self-managed long-lived key, sign an artifact with Cosign, and upload the artifact signature to the transparency log.

However, artifact consumers can still fail-open with verification (allow the artifact, while logging the failure) if they do not want to take a hard dependency on Sigstore (require that Sigstore services be used for signature generation). A developer can use their self-managed key to generate a signature. A verifier can simply extract the verification key from the certificate without verification of the certificate’s signature. (Note that verification can occur offline, since inclusion in a transparency log can be verified using a persisted signed bundle from Rekor and code signing certificates can be verified with the CA root certificate. See Cosign’s verification code for an example of verifying the Rekor bundle.)

Once a consumer takes a hard dependency on Sigstore, a CI/CD pipeline can move to fail-closed (forbid the artifact if verification fails).

Benefits

A stronger verification policy that enforces both the presence of the signature in a transparency log and the identity of the signer.
Verification policies can be enforced fail-closed.

Identity-based (“keyless”) signing

This final step is added for completeness. Signing is done using code signing certificates, and signatures must be published to a transparency log for verification. With identity-based signing, fail-closed is the only option, since Sigstore services must be online to retrieve code signing certificates and append entries to the transparency log. Developers will no longer need to maintain signing keys.

Conclusion

The Sigstore tooling and infrastructure can be used as a whole or modularly. Each separate integration can help to improve the security of artifact distribution while allowing for incremental updates and verifying each step of the integration.

The post Adopting Sigstore Incrementally appeared first on Linux Foundation.

Base64 encoding: What sysadmins need to know

By understanding Base64 encoding, you can apply it to Kubernetes secrets, OpenSSL, email applications, and other common situations.

Read More at Enable Sysadmin