Stories with Tag Ubuntu

• Memory-safe sudo to become the default in Ubuntu

  permalink

  Posted: 2025-05-06 11:22:55

  Verbose tl;dr

  Ubuntu is switching its default sudo implementation to a memory-safe version written in Rust. This change, starting with Ubuntu 23.10 "Mantic Minotaur", significantly improves security by mitigating vulnerabilities related to memory corruption, such as buffer overflows and use-after-free bugs, which are common targets for exploits. This Rust-based sudo is developed and maintained by the OpenSSF's Secure Software Supply Chain project, and represents a major step towards a more secure foundation for the widely-used system administration tool.

  The Trifacta Tech blog post "Memory-safe sudo to become the default in Ubuntu" details the upcoming transition in Ubuntu to a memory-safe version of sudo, the ubiquitous command-line utility that allows users to execute commands with elevated privileges. This change, a significant step towards enhancing system security, is being implemented by switching the default sudo implementation from the traditional C version to a rewritten version leveraging Rust, a modern programming language renowned for its memory safety guarantees.

  The blog post highlights the inherent vulnerability of C code to memory-related bugs, such as buffer overflows and use-after-free errors. These vulnerabilities can be exploited by malicious actors to gain unauthorized access to a system, potentially escalating privileges and compromising security. Rust's ownership and borrowing system, along with its strict compile-time checks, effectively prevents these types of memory-related vulnerabilities, making it a compelling choice for security-sensitive applications like sudo.

  Ubuntu's adoption of the Rust-based sudo is part of a broader industry trend towards embracing memory-safe languages for system programming. This movement is driven by the increasing awareness of the prevalence and severity of memory-related vulnerabilities in C and C++ codebases. By switching to Rust, Ubuntu aims to significantly reduce the attack surface of sudo and enhance the overall security posture of its systems.

  The post explains that the transition will be gradual and transparent to most users. The new Rust-based sudo will be installed alongside the existing C version initially, and users will be able to choose which version to use. Eventually, the Rust version will become the default, providing enhanced security by default for all Ubuntu users. This phased approach allows for thorough testing and ensures compatibility with existing systems and workflows.

  The blog post emphasizes the importance of this change in the context of modern security threats, where exploiting memory-related vulnerabilities remains a common attack vector. By adopting a memory-safe implementation of sudo, Ubuntu is taking a proactive step towards mitigating these risks and bolstering the security of its users. The post concludes by highlighting the potential for this transition to serve as a catalyst for wider adoption of memory-safe languages in critical system software.

  • Ubuntu
  • Linux
  • Security
  • sudo
  • Memory Safety
  • Rust
  • system administration
  • Privilege Escalation
  • Software Security
  • Operating Systems

  Summary of Comments ( 69 )
  https://news.ycombinator.com/item?id=43903853

  Verbose tl;dr

  Hacker News commenters generally expressed approval for Ubuntu's move to a memory-safe sudo, viewing it as a positive step towards improved security. Some questioned the significance of the change, pointing out that sudo itself isn't a frequent source of vulnerabilities and suggesting that efforts might be better directed elsewhere. A few expressed concerns about potential performance impacts, while others highlighted the importance of addressing memory safety issues in widely used system utilities like sudo to mitigate even rare but potentially impactful vulnerabilities. The discussion also touched upon the broader trend of adopting Rust for system programming and the trade-offs between memory safety and performance. Several commenters shared anecdotes about past vulnerabilities related to sudo and other core utilities, reinforcing the argument for enhanced security measures.

  The Hacker News post "Memory-safe sudo to become the default in Ubuntu" generated several comments discussing the implications of switching to a memory-safe version of sudo.

  Several commenters expressed strong approval for the move, emphasizing the importance of memory safety in a critical utility like sudo. They highlighted how sudo's privileged position makes it a prime target for exploitation, and how memory safety mitigations can significantly reduce the risk of successful attacks. One commenter specifically mentioned how this change aligns with a broader industry trend towards prioritizing memory safety.

  Some discussion revolved around the choice of Rust as the language for the rewritten sudo. While generally praised for its memory safety features, a few commenters raised concerns about the potential performance overhead and the learning curve for developers accustomed to C. One commenter pointed out that the performance impact is likely negligible for a tool like sudo, which isn't typically performance-critical. Another countered that while Rust's performance is often comparable to C, achieving optimal performance in Rust can require more effort.

  A few comments delved into the technical details of the rewrite, including the challenges of integrating Rust code with existing C codebases. One commenter mentioned the use of bindgen to create safe bindings, acknowledging the complexities involved in such integrations.

  Several commenters expressed hope that other distributions would follow Ubuntu's lead in adopting a memory-safe sudo. The discussion also touched upon the wider adoption of memory-safe languages in system programming, with some suggesting that this move by Ubuntu could signal a significant shift in the industry.

  A couple of comments inquired about the timeline for the transition and the testing procedures in place to ensure a smooth rollout. There was also a brief discussion about the potential impact on existing scripts and configurations, with one commenter suggesting that the changes are unlikely to cause significant disruption.

  Overall, the comments reflect a generally positive reception to the news, with many commenters acknowledging the importance of memory safety in system utilities and praising Ubuntu for taking the lead in this area. While some concerns were raised regarding performance and the learning curve associated with Rust, the overall sentiment leaned towards the long-term benefits of increased security.

• Make Ubuntu packages 90% faster by rebuilding them

  permalink

  Posted: 2025-03-18 23:55:17

  Verbose tl;dr

  Rebuilding Ubuntu packages from source with sccache, a compiler cache, can drastically reduce compile times, sometimes up to 90%. The author demonstrates this by building the Firefox package, achieving a 7x speedup compared to a clean build and a 2.5x speedup over using the system's build cache. This significant performance improvement is attributed to sccache's ability to effectively cache and reuse compilation results, both locally and remotely via cloud storage. This approach can be particularly beneficial for continuous integration and development workflows where frequent rebuilds are necessary.

  The post "Make Ubuntu packages 90% faster by rebuilding them" explores a significant performance improvement achieved by rebuilding Ubuntu Debian packages using a modified configuration. The author, frustrated by the slow build times of certain packages, specifically gcsfuse, observed that the default build process utilized a single core, severely underutilizing the available processing power of modern multi-core systems.

  The post then meticulously details the process of accelerating the build process. The core of the optimization lies in leveraging the DEB_BUILD_OPTIONS environment variable. By setting this variable to parallel=N, where N represents the desired number of concurrent build jobs (ideally matching the number of CPU cores), the compilation process can be parallelized. This modification instructs the build system, specifically dpkg-buildpackage, to utilize multiple cores during the compilation and linking stages, dramatically reducing the overall build time.

  The author showcases the remarkable impact of this simple change. A rebuild of the gcsfuse package, which initially took an hour and a half, completed in a mere ten minutes after implementing the parallelization. This represents an approximately 90% reduction in build time. Furthermore, the post demonstrates how to make this optimization permanent by setting the DEB_BUILD_OPTIONS variable within the user's shell configuration file (e.g., .bashrc or .zshrc). This ensures that all future builds automatically benefit from parallel processing.

  The post concludes by emphasizing the ease and effectiveness of this optimization, suggesting that it could significantly improve the development workflow for anyone building Debian packages on multi-core systems. The author also notes the potential for further performance gains by exploring other compiler flags and build optimizations, although these are not explored within the post itself. The provided example focuses on a specific package, gcsfuse, but the technique is applicable to any Debian package built with tools like dpkg-buildpackage that respect the DEB_BUILD_OPTIONS variable.

  • Ubuntu
  • Packages
  • build process
  • optimization
  • performance
  • Speed
  • Rebuilding
  • Linux
  • Debian
  • Software Development
  • dpkg
  • APT

  Summary of Comments ( 10 )
  https://news.ycombinator.com/item?id=43406710

  Verbose tl;dr

  Hacker News users discuss various aspects of the proposed method for speeding up Ubuntu package builds. Some express skepticism, questioning the 90% claim and pointing out potential downsides like increased rebuild times after initial installation and the burden on build servers. Others suggest the solution isn't practical for diverse hardware environments and might break dependency chains. Some highlight the existing efforts within the Ubuntu community to optimize build times and suggest collaboration. A few users appreciate the idea, acknowledging the potential benefits while also recognizing the complexities and trade-offs involved in implementing such a system. The discussion also touches on the importance of reproducible builds and the challenges of maintaining package integrity.

  The Hacker News post "Make Ubuntu packages 90% faster by rebuilding them" generated a significant discussion with several compelling comments exploring various facets of the proposed speed improvements.

  Several commenters focused on the reproducibility aspect. One user questioned the reproducibility of builds using ccache given its potential to mask underlying issues that might manifest differently on different systems. This concern stemmed from the idea that while ccache might speed up builds, it could also hide bugs that would otherwise be caught during a clean build. Another commenter echoed this sentiment, emphasizing the importance of clean builds for verifying package integrity and catching errors. They also highlighted the inherent tension between build speed and ensuring correct and reproducible builds across diverse environments.

  Another thread of conversation revolved around the technical details of the proposed speed improvements. One commenter inquired about the specific changes implemented to achieve the 90% speed increase, prompting the original poster (OP) to provide more context. The discussion delved into the mechanics of ccache and how it leverages caching mechanisms to accelerate compilation times. This technical exchange shed light on the underlying principles enabling the performance gains.

  The practicality and applicability of the proposed changes were also discussed. One commenter questioned whether the changes would be upstreamed, given the potential benefits for a wider audience. This prompted a conversation about the challenges and considerations involved in integrating such changes into the broader Ubuntu ecosystem. Further discussion focused on the trade-offs between build speed and resource consumption, specifically memory usage. Some users raised concerns about the potential impact on systems with limited resources, while others argued that the benefits outweighed the drawbacks.

  Finally, some comments focused on alternative approaches and existing best practices. One commenter mentioned that using ccache is already a common practice within the community and suggested that the observed speed improvements might not be entirely novel. Another commenter pointed out the importance of distributing build processes to further enhance performance, especially for larger projects. These comments provided valuable context and expanded the discussion beyond the specific approach presented in the original post.