Vanilla Dpup 11.0.x Development Builds

[d-pupp]

Testing dwl version. Mostly stock the only change I made was to the display resolution.
After my last post yesterday where I was learning how to use dwl. I took a break. When I came back the screen was blanked and it wouldn't resume.
So it seems my resume problem is not with labwc after all.

[retiredt00]

I see!
Thank you TerryH and dimkr.

So spot has root access with its own password, just has to type it constantly to go thorough the pkexec for everything. Thus in vanilla dpup instead of having root and an unprivileged user, spot is elevated to admin, the unprivileged user is eliminated and root is "hidden" till a root password is set.
Is not clear to me why this (cumbersome I feel implementation) is safer or better than the classical puppy or the standard distribution implementation, but I was wondering if the option "open as root/su" could be implemented in the file manager and/or application launchers. This way editing system files can be simpler instead of going through the terminal and typing pkexec application_name path_to_file and then the password

Regarding the pkexec of vanilladpup, my understanding is that is a home grown version. This is very interesting but I was wondering if has been through any kind of rigorous testing, since whoever controls this controls the entire system.

THX.

[dimkr]

@retiredt00 To elevate permissions to root, a malicious application needs a pty and your password, therefore it's not the same as having root privileges. If you know C and have enough OS internals/cyber security knowledge, feel free to review the code at https://github.com/vanilla-dpup/woof-CE ... pot-pkexec: it's really short.

You can run applications like the file manager, the terminal and the browser as root (for example, use the terminal as a launcher, so you type your password only once when you start the terminal), but the problems you'll have will be similar to those Puppy users have when they run some applications as root and some as spot. In addition, some things simply won't run as root, like Flatpak applications, so you're guaranteed to get a worse user experience if you try to force the use of root for everything: this is why other distros don't offer this.

[dimkr]

I strongly recommend anyone concerned about their security and privacy not to download an operating system
1. That is not reproducible by users (not built by a publicly available build system that can produce a 1:1 copy) and doesn't have public information about build process (like logs for the entire build process, with timestamps and versions of components used)
2. That possibly contains components of unknown origins (binaries that don't come from Debian's build servers or built from verified source code that is publicly available and auditable)
3. That's provided by a user with one post, through a forum and a file sharing site (not through a developer platform with 2FA and other security measures, not a trustworthy location like www.debian.org)

(And I strongly recommend "regular users" that don't want bugs and risks like data loss not to use a development build of an OS or even worse, a derivative of an old development build, as their daily driver)

[retiredt00]

If you know C and have enough OS internals/cyber security knowledge, feel free to review the code at https://github.com/vanilla-dpup/woof-CE ... pot-pkexec: it's really short.

I do not know enough C to evaluate risks but Open AI has the following recommendations

Question: is the following code (pkexecd.c) is prone to hacking ?

The code you've provided appears to be part of a Unix-based daemon or service that interacts with client applications via a Unix domain socket. While it performs several steps to handle a request, there are some potential security concerns that could make this code prone to hacking or exploitation if not properly controlled. Let's walk through a few points of concern:

1. Environment Variable Handling
The code processes environment variables passed by the client (envp) and checks them against a set of allowed prefixes. However, it seems to use memchr and strchr to parse these variables, which could potentially be exploited if the parsing is not correctly handled or if unexpected input leads to buffer overflows.
It's good practice to have stronger input validation and sanitization, especially when environment variables are passed from untrusted sources.
2. Potential Buffer Overflow
The code makes extensive use of buffers (e.g., envp, argv, buf), and there’s no clear indication that the size of the buffers is strictly controlled or checked for overflows during parsing. There are some checks in place (like checking for a null terminator or buffer limits), but buffer overflows can still occur if the size calculations are incorrect.
Ensure that buf, envp, and argv are not subject to overflow and that lengths are always verified before any copy or usage.
3. Use of execve and fork
The code forks a new process using fork() and then uses execve() to run the desired command. If an attacker can control the arguments passed to execve, they may attempt to execute malicious code.
While the safe_envp array is intended to limit which environment variables are passed to the child process, the use of execve and handling of argv requires careful validation of arguments to avoid command injection vulnerabilities.
4. Privilege Escalation
The code attempts to set user and group IDs (setuid, setgid, initgroups), which suggests that it's running with elevated privileges. If an attacker is able to bypass the permission checks or control the arguments passed to these functions, it could lead to privilege escalation.
Specifically, the exec_child function drops privileges by changing the UID and GID to match the cred->uid, but if there’s a flaw in the safe_envp or command execution handling, an attacker could exploit this for privilege escalation.
5. Untrusted Client Input Handling
The socket connection (recv()) is used to receive data from a client, and the code doesn't seem to apply strong validation on the data received. An attacker could potentially send crafted input that could exploit issues like buffer overflows or injection attacks.
Ensure that the received data (buf) is correctly validated, and its length is checked before being used.
6. Signal Handling and Race Conditions
The code uses sigprocmask and sigwaitinfo to manage signals, but it could be vulnerable to signal races. Signals like SIGCHLD, SIGIO, or SIGTERM are handled asynchronously, and this could lead to timing vulnerabilities or inconsistent states if the signal handling is not synchronized properly.
Race conditions or improper signal handling can lead to unexpected behavior or exploitation.
7. File Permissions
The socket is created with chmod(sun.sun_path, 0766) permissions. This is very permissive (read/write for everyone), and if not carefully controlled, malicious clients may be able to connect to the socket and issue malicious commands.
8. Use of fork() and waitpid()
The use of fork() and waitpid() for process control is standard, but there’s a potential for denial of service if there’s a failure or race condition, especially if too many child processes are created without proper cleanup.
Recommendations:
Input Validation and Sanitization:

Apply strict input validation to all environment variables, socket data, and arguments passed to execve.
Ensure that buffer sizes are carefully managed, and use secure functions (e.g., strncpy, snprintf) to avoid overflows.
Secure Socket Permissions:

Restrict socket permissions to ensure that only trusted users or processes can interact with the daemon.
Privileged Operation Safety:

Carefully control any code that handles privilege escalation (e.g., setuid, setgid).
Ensure that the program cannot be tricked into executing arbitrary code with elevated privileges.
Signal Handling:

Improve signal handling to avoid race conditions and ensure that signals are properly synchronized.
Logging and Error Handling:

Ensure proper logging of suspicious activities, and ensure that errors (e.g., failed execve calls) are securely handled to avoid leaking information that could assist an attacker.
Conclusion:
This code has potential security risks, including issues with privilege escalation, input validation, and buffer overflow vulnerabilities. The areas above should be reviewed and tightened to reduce the risk of exploitation. It is essential to follow secure coding practices, especially when working with user-supplied input and running with elevated privileges.

and on pkexec.c the response was

Let's go through this code to identify potential security concerns:

Overview of the Code:
The code is a client application that connects to a Unix domain socket (/run/pkexecd.socket), sends environment variables and command arguments to a remote server, and receives a response. The primary security concerns here are related to input handling, socket communication, privilege escalation, and error management.

Key Security Risks and Concerns:
1. Unvalidated User Input
The code processes arguments passed via argv (e.g., --user and --version). While it seems to handle the --version and --user flags with specific actions, there’s no validation on the remaining command arguments. Any user-provided data could potentially be sent over the socket, and if the server-side daemon is not properly validating and sanitizing input, this could open the system to attacks like command injection.
Fix: Ensure that user-provided input (e.g., command-line arguments) is validated before being used in any socket communication or system commands.
2. Environment Variables Handling
The program sends all environment variables (environ) over the socket using the sendall() function. If the environment contains sensitive information (like passwords or private tokens), it could be intercepted by an attacker if the socket is not secured properly. Furthermore, there's no filtering or sanitization of the environment variables being sent.
Fix: Ensure that sensitive environment variables are not sent over the socket or that proper encryption is used to secure the data in transit. Consider sanitizing the environment variables before sending them.
3. Privilege Escalation (or Lack of Privileges)
The code checks whether the user is root (UID and GID are both 0). If the user is root, it directly executes the command (execvp(argv[0], argv)). This can be a security risk if the command arguments (argv) are not properly validated because an attacker could potentially exploit this to execute arbitrary commands with root privileges.
Fix: Always validate the arguments before passing them to execvp(). Additionally, avoid running the program as root unless absolutely necessary. Consider using a safer method to execute commands, such as using execvp with a predefined set of allowed commands.
4. Unsafe Use of recv()
The recv() function is used to read a single byte (recv(s, &i, 1, 0)) from the socket, but there’s no verification or error handling for the received data. The received byte is stored in the variable i, but it is unclear how this value is used. If the server sends malicious data or unexpected values, this could result in unintended behavior.
Fix: Ensure that the data received from the server is properly validated, and verify that the expected data is returned before proceeding.
5. Lack of Authentication and Encryption
The socket communication is done without any authentication or encryption, meaning that data sent between the client and the server can be intercepted, modified, or impersonated by an attacker. This is particularly concerning when sensitive environment variables or commands are being sent over the socket.
Fix: Use a secure transport method for socket communication (e.g., using TLS for Unix domain sockets) or implement an authentication mechanism between the client and the server to ensure that only trusted clients can communicate with the server.
6. Error Handling
The error handling is minimal, with EXIT_FAILURE being returned when things go wrong. While this is functional, there could be situations where it is important to log the exact error or provide more details to the user for debugging purposes. Additionally, failing silently or returning without proper logging could make it easier for attackers to exploit the program without being detected.
Fix: Improve error logging and handling. Provide more meaningful error messages and make sure that any security-relevant errors are logged for further investigation.
7. Potential for Socket Denial of Service (DoS)
The program sends data to the server using sendall(), but there’s no mention of rate-limiting, authentication, or validation of the socket connection. An attacker could potentially flood the server with requests or try to send a large amount of data to cause resource exhaustion.
Fix: Implement rate-limiting, proper access control (authentication), and input validation to prevent abuse of the socket communication.
Recommendations:
Input Validation:

Ensure that all user input (e.g., command-line arguments, environment variables) is properly validated and sanitized to avoid command injection or other types of malicious input.
Authentication and Encryption:

Secure the communication channel (e.g., using encrypted sockets or applying Unix socket authentication) to prevent unauthorized access and protect sensitive data in transit.
Privilege Management:

Avoid running the program as root unless necessary. If the program must run as root, ensure that all commands and arguments passed to execvp() are validated, and consider using restricted user privileges whenever possible.
Error Handling and Logging:

Improve error handling to log specific error messages for debugging purposes. Consider using secure logging practices to record potential security-relevant errors.
Memory Management and Buffer Overflow Prevention:

While this specific code doesn't seem to directly exhibit buffer overflows, be sure to manage memory carefully and avoid writing past buffer boundaries. You should ensure that sendall() handles the data appropriately and doesn't inadvertently cause buffer overflows or memory corruption.
Limit the Environment Variables Sent:

Only send environment variables that are necessary, and filter out any sensitive or irrelevant information (e.g., passwords, tokens). This minimizes the risk of leaking sensitive information.
Conclusion:
This code introduces several security risks, particularly related to untrusted input, privilege management, and lack of encryption/authentication. By addressing these concerns—specifically with input validation, secure communication, and careful privilege handling—you can make the application more secure and resistant to exploitation.

I hope this is helpful

[dimkr]

I hope this is helpful

Thanks for trying but this AI is not very helpful, it gives general programming advice (like "don't send sensitive data over an unencrypted and unauthenticated connection"), doesn't understand the context (a tool that asks another tool to securely display a yes/no prompt, and run something as root if yes) and says pretty random things (like using TLS on top of a Unix socket). It's no substitute for a real security review by somebody with pen testing experience.

[darksun]

testing out vanilla dpup 11.0.x, I do not like the spacefm root window's red theme as it is difficult to read, is it just me?

PS I do not know where to post it so I am asking it here: vanilla dpup 10.0.x automatic github builds has failed the latest action and it is a month since last ISO; I believe this is not the first time this happens. Just to alert the developer.

[darksun]

also vanilla dpup 10.0.72 failed to be built

https://github.com/vanilla-dpup/release ... 3350292919

https://github.blog/changelog/2024-04-1 ... t-actions/

[dimkr]

@darksun I'm aware of this and it's not the top priority in my life at the moment. Please be patient.

[darksun]

@darksun I'm aware of this and it's not the top priority in my life at the moment. Please be patient.

@dimkr thank you for your answer, I was confident you were already aware of the issue. I am patient. My message aimed to inform other forum members who, like me, are interested in vanilla dpup 10.x and its scheduled releases

[d-pupp]

@dimkr I just updated to 11.0.217. I had to add my printer, something I haven't done in awhile.
I noticed that there is no admin access to cups so there is no way to add a printer from the cups gui
So I did some searching and found ...
SystemGroup parameter in the /etc/cups/cups-files.conf has a lpadmin group
/etc/group has a lpadmin group
Add spot to the lpadmin group (As root)

Code: Select all

usermod -a -G lpadmin spot

I now have admin access to cups as spot (password required)
Can you make the same changes on your end and add spot to the lpadmin group please?

[dimkr]

The latest build (at the time of writing) replaces Firefox ESR with LibreWolf. It's slightly smaller, seems to consume slightly less RAM, has fewer annoyances (no Mozilla cloud services), includes uBlock Origin by default and has various privacy tweaks. (All previously applied default configuration overrides are still there, on top of LibreWolf's defaults.)

I don't know if LibreWolf's developers can be trusted (including their build pipeline) but Mozilla seems incapable of making good decisions, so more pairs of eyes that scan Firefox changelogs and default settings can't hurt. Lower resource consumption and smaller size are a nice bonus.

This build also has other unannounced changes like menu icons and other things I don't remember: all changes are documented in the git log.

[darksun]

I don't know if LibreWolf's developers can be trusted (including their build pipeline)

thank you @dimkr . Have you given a thought to Mullvad Browser?
It is made by trusted and capable devs (by The TOR Browser team, who merged with TAILS team, and Mullvad).

https://mullvad.net/en/download/browser/linux
https://github.com/mullvad/mullvad-browser

[d-pupp]

Thank you @dimkr. I installed it yesterday. I personally like the icons. I'm very visual and can find an icon quickly. I'm sorry to admit that sometime I have to read the menus several times to find what I wanted.
I also like LebreWolf so far so good. The dark mode by default is much easier on my eyes.

[dimkr]

Have you given a thought to Mullvad Browser?

It has one purpose, sell a particular VPN service, and I don't understand why it's not just a close fork of Firefox. LibreWolf is not developed by a company, it's open source, it doesn't talk to closed source servers, it has an automated and transparent build process on GitLab (correct me I'm wrong), it tracks Firefox closely and it doesn't try to sell anything.

[darksun]

I believe you are wrong.

It has one purpose, sell a particular VPN service

They are yes distributing the browser to encourage the sell of their VPN but the software is free and opensource https://github.com/mullvad/mullvad-browser/ and, as they state here in their website https://mullvad.net/en/download/browser/linux

Transparent business model
We have no intention in earning money from the Mullvad Browser. Our business model is to earn money from our VPN service. Our only ambition with the Mullvad Browser is to provide the best privacy-focused browser possible to Mullvad’s VPN users – and to everyone else, for that matter.

You say:

I don't understand why it's not just a close fork of Firefox.

Mullvad web browser is free to everyone and open source, see again https://github.com/mullvad/mullvad-browser/

LibreWolf is not developed by a company

Mullvad Browser is far much better. Mullvad has partnered with the TOR project (which also recently merged with TAILS ) and I know no people/team who care more and have the skills to make a better web browser for security and anonymity.

From this article https://blog.torproject.org/releasing-mullvad-browser/

Today we announced the launch of the Mullvad Browser, a browser built by the Tor Project team and distributed by Mullvad.

In fact the TOR Browser is regarded the gold standard for privacy, and Mullvad browser is "just" the TOR browser stripped out the TOR components.
Mullvad browser can be used without a VPN, like a normal web browser.
Key point: for one of its main scope which is fingerprinting protection people are discouraged to change any settings and/or installing any add-ons BUT this does NOT mean people cannot change them, if they wish to. Even with a fingerprinting protection impaired Mullvad browser offers, in my opinion, a solid & private & trusted hardened firefox-based browser, already optimized and configured by experts in the field. I use it as intended ( install it, do not change anything, use it as it is) but others are free to do otherwise.

You say

it doesn't talk to closed source servers

There is no evidence in my knowledge Mullvad does it.

You say

it tracks Firefox closely and it doesn't try to sell anything.

Mullvad (and TOR browser) tracks Firefox very very closely. So many people with very high threat models (eg journalists, dissidents, criminals, and so on) rely on TOR Browser (and/or TAILS) and, if you follow it, Mullvad/TOR_browser release updates almost the same day Firefox puts out an update. I do not believe Librewolf is able to do the same.

Example
https://github.com/mullvad/mullvad-brow ... tag/14.0.7 4th of March 2025, latest release of Mullvad browser based on FF 128.8 ESR
https://lists.debian.org/debian-securit ... 00036.html 5th of March 2025, Debian security bulletin about FF 128.8 ESR
-> even one day before Debian!

I believe if a person put aside their prejudgments about it being distributed by a VPN company and check it out, tries it out, tests it out, might and likely will love it.
A side note, to whom does not follow the privacy and security news feeds: Mullvad is regarded as one of the few (couples) companies in the VPN market who really cares and have no fishy behaviors.
They (Mullvad company) have commissioned and paid to be audited multiple times by 3rd party top companies (such as https://cure53.de) and are proactive with privacy campaigns, especially in their country (Sweden).

just a few
https://mullvad.net/en/blog/2024/12/11/ ... -available
https://x41-dsec.de/news/2024/12/11/mullvad/
https://cure53.de/pentest-report_mullvad_2024_v1.pdf
https://www.assured.se/publications/Ass ... t_2024.pdf

But mine are just empty words to people who are not enough interested in the matter, I guess.

@dimkr @fredx181 have you tried it?

[dimkr]

I believe you are wrong.

It has one purpose, sell a particular VPN service

They are yes distributing the browser to encourage the sell of their VPN but the software is free and opensource https://github.com/mullvad/mullvad-browser/ and, as they state here in their website https://mullvad.net/en/download/browser/linux

It's built by a company, not a non-profit. This company's #1 priority is to make profit. Anything else they do is some form of marketing.

I don't understand why it's not just a close fork of Firefox.

Mullvad web browser is free to everyone and open source, see again https://github.com/mullvad/mullvad-browser/

I'm not saying that Mullvad browser is closed source: many options (Chrome, Edge, ...) are. There aren't many options if you want an open source browser, especially if you want a browser that is not developed by a for-profit organization.

Mullvad Browser is far much better. Mullvad has partnered with the TOR project (which also recently merged with TAILS ) and I know no people/team who care more and have the skills to make a better web browser for security and anonymity.

Tor has its critics, and I prefer to stay away from forks of Firefox unless they're either
1. Fully independent (no longer pull Mozilla code) and built by a trustworthy team
2. Super close to Firefox (and pull Mozilla code), with an easy way to tell what's changed

AFAIK the Tor browser (and anything based on it) doesn't satisfy (1) because it tracks Firefox releases and it's not a hard fork, but at the same time, the differences between this browser and Firefox are unclear.

In fact the TOR Browser is regarded the gold standard for privacy, and Mullvad browser is "just" the TOR browser stripped out the TOR components.

Again, Tor has its problems (used by few people, making them highly fingerprintable) and it's unclear how this browser is different from Firefox when you take out the Tor integration.

it doesn't talk to closed source servers

There is no evidence in my knowledge Mullvad does it.

I didn't say Mullvad browser does this. What I said is, some browsers do: I don't want to include a browser that does.

Mullvad (and TOR browser) tracks Firefox very very closely. So many people with very high threat models (eg journalists, dissidents, criminals, and so on) rely on TOR Browser (and/or TAILS) and, if you follow it, Mullvad/TOR_browser release updates almost the same day Firefox puts out an update. I do not believe Librewolf is able to do the same.

IMO 0-3 days is good enough.

@dimkr @fredx181 have you tried it?

Nope, but
1. For now, I'm wearing my BDFL hat and LibreWolf is going to stay until I change my mind (I understand I can't make 100% of users happy 100% of the time - sometimes I need to make a quick but informed decision and move on)
2. I'm always open to feedback and maybe I'll change the default browser in the future, but it has to be a browser I'm willing to use myself

[d-pupp]

I just updated to 11.0.226
I just wanted note the last few times I updated to a new version I had to type startlabwc the first time I booted it. After that it boots straight into labwc.