Beta Release Introducing BraveVault: inet security Ubuntu & Kubuntu

[Victor M]

Download link: BraveVault for Ubuntu, Kubuntu 60 day trial. Follow link and press Ctrl-D.
sha256sum: 21fb4566c0e9d8ca637b73c799fdfeab8660dd23ce60ff97bd625579acf3599b

To install: sudo bash bravevault-trial.sh install <surfing account> --online
You must make a secondary surfing account first. The installer will install brave, you don't have to do anything.

To fetch your downloaded file:
bv-export --list
bv-export <file name>
To upload a file: Put the file into /home/<surfing account>/BraveUploads/

Always use the surfing account to surf, NEVER with admin account.

BraveVault for Kubuntu 60 day trial​

A Different Approach to Defending Against Attackers​

Don't just block malicious websites. Make it harder for attackers to succeed.
Every time you browse the Internet, you may encounter malicious websites, compromised advertisements, fraudulent downloads, and software vulnerabilities that attackers can exploit.
Modern web browsers are extraordinarily complex applications, and serious security vulnerabilities continue to be discovered and corrected across successive versions. Even after extensive testing and security improvements, newly released browsers contain previously undiscovered flaws, including vulnerabilities that attackers could exploit. In other words, they are perpetually insecure.
Browser manufacturers have responded in part by accelerating their software release schedules. Chromium-based browsers, for example, have moved toward weekly security fixes and more frequent major releases. These changes help deliver corrections sooner, but they also highlight a fundamental problem: fixing known vulnerabilities does not eliminate vulnerabilities that have yet to be discovered.
Although browser developers employ secure programming practices, testing, the continuing discovery of serious flaws demonstrates the limitations of relying on software updates alone.
Attackers continuously develop new techniques, modify existing attacks, and discover previously unknown vulnerabilities. A browser can be fully updated and still be vulnerable to an attack that its developers have not yet identified.
BraveVault is designed around a different security objective: restricting what attackers can do if they manage to attack your browser.
Rather than relying exclusively on detecting threats using anti-malware DNS or waiting for the next security update, BraveVault combines preventive security controls, browser hardening, network restrictions, and anti-persistence measures to make several common attack techniques more difficult to execute.

What Makes BraveVault Different?​

1. Designed to Disrupt Attacker Command-and-Control Communications​

When attackers compromise a computer, they often try to establish a connection to an external command-and-control (C2) server.
This connection may allow attackers to send instructions, remotely control malicious software, download additional attack tools, or receive stolen information.
BraveVault is designed to restrict these communication channels.
Its security features include:

• Controls over outbound network connections.
• Restrictions on network protocols that may be abused for unauthorized communications.
• UDP traffic controls with provisions for supported video conferencing services.
• Network filtering intended to reduce communications with known malicious destinations.

The benefit: Attackers may have fewer options for controlling malicious software or communicating with an infected browsing environment.

2. Designed to Prevent Attackers from Establishing Persistence​

Attackers frequently want their malicious software to survive a browser restart, logout, or computer reboot.
To accomplish this, they may modify startup configurations, create background services, alter application settings, or establish other automatic execution mechanisms.
BraveVault incorporates anti-persistence measures designed to restrict unauthorized changes to selected locations commonly used for these purposes.
The benefit: Making persistence more difficult can reduce an attacker's ability to maintain access after the original attack has ended.

3. Designed to Prevent Unauthorized Privilege Escalation​

After compromising a browser, attackers may attempt to obtain administrative privileges to disable security protections, modify system files, or gain greater control over the computer.

BraveVault incorporates restrictions on privilege-elevation mechanisms and privileged operations, including controls over administrative authorization and programs that can execute with elevated privileges.
The benefit: Attackers who compromise the browser face additional barriers when attempting to obtain administrative control of the computer.

4. Designed to Combat Information-Stealing Malware
Information stealers are a major threat to Internet users.
Attackers use them to target:

• Website passwords and saved login information.
• Browser authentication cookies and session tokens.
• Banking and financial account information.
• Sensitive personal and business files.
• Information that could be used for account takeover.

BraveVault is designed to restrict unauthorized access to sensitive information outside the browser's permitted environment and limit opportunities for stolen data to be transmitted.
The benefit: Reduced opportunities for attackers to collect information from other parts of your computer or transfer it to external systems.

5. Designed to Restrict Unauthorized Software Execution​

A browser exploit may be only the beginning of an attack.
After gaining an initial foothold, attackers frequently attempt to run additional programs, command interpreters, malicious scripts, or downloaded attack tools.
BraveVault includes application execution controls designed to restrict unauthorized programs and certain forms of script execution.
These controls help prevent a browser compromise from automatically becoming an opportunity to execute arbitrary software.

The benefit: Attackers may find it more difficult to launch additional attack tools or expand an initial compromise.

6. Hardened Browser Configuration​

BraveVault employs a security-focused Brave browser configuration that reduces exposure to selected browser attack techniques.
Its designed protections include:

• JavaScript JIT restrictions: Reduce exposure to exploitation techniques targeting just-in-time compilation.
• JavaScript optimization restrictions: Limit selected optimization features that can increase the browser's attack surface.
• Browser extension restrictions: Reduce risks associated with malicious or compromised extensions.
• Developer Tools restrictions: Limit access to browser development functionality.
• Remote debugging restrictions: Reduce opportunities to misuse browser debugging interfaces.
• Managed security settings: Help prevent ordinary browser settings changes from weakening the intended configuration.

The benefit: Fewer browser capabilities available for attackers to misuse, while retaining core website functionality.

7. Restricted Communication with Desktop Services​

A compromised browser may attempt to interact with applications and services elsewhere on the computer.
Such interactions can create opportunities for attackers to access resources or invoke capabilities unrelated to normal browsing.
BraveVault is designed to minimize unnecessary communications between the browser and desktop services, while providing specifically controlled interfaces for required functionality.
The benefit: Fewer opportunities for a browser-based attack to reach unrelated desktop functions.

​

---

Why Traditional Browser Protection Is Not Enough​

Antivirus products, browser reputation services, and malicious website blocklists are useful security measures. However, they cannot necessarily identify every new attack.
Attackers can change malware signatures, register new Internet domains, exploit previously unknown vulnerabilities, and develop new methods of bypassing detection.
BraveVault's design emphasizes an additional question:
Even if an attacker gets past the first line of defense, what can they actually accomplish?
BraveVault addresses that question by concentrating on five important attacker objectives:

Attacker objective	BraveVault's designed response
Establish remote control	Restrict command-and-control communication channels
Maintain access after a reboot	Protect selected persistence mechanisms
Steal personal or business information	Restrict access to unrelated data and unauthorized communications
Execute additional malware	Enforce application and script execution restrictions
Exploit browser functionality	Disable or restrict selected higher-risk browser capabilities

The objective is to make a successful attack more difficult by reducing the capabilities available to an attacker.

Security Designed for Real-World Threats​

BraveVault's design addresses recognizable categories of cyberattacks, including credential theft, information stealing, malware persistence, unauthorized program execution, and command-and-control communications.
Rather than relying entirely on identifying an attacker's tools, BraveVault is intended to restrict activities that many of those tools need to perform.

BraveVault​

Attackers Keep Changing Their Attacks. Make Their Job Harder.​

Traditional security often asks whether an attack can be detected.

BraveVault asks whether the attacker can accomplish their objective.

By restricting unauthorized execution, persistence, data access, dangerous browser features, and external communications, BraveVault is designed to create additional obstacles between an attempted browser exploit and a successful cyberattack.

BraveVault — More Than Browser Protection. Designed to Restrict What Attackers Can Do.

BraveVault does not guarantee immunity from attacks, malware, or information theft. Its protections are intended to reduce particular attack opportunities and depend on correct installation, configuration, and the threats encountered.

 

[Bot]

Download link: BraveVault for Kubuntu 60 day beta trial To install: sudo bash bravevault-trial.sh install --online You must make an secondary surfing account first BraveVault for Kubuntu 60 day trial A Different Approach to Defending Against Attackers Don't just block malicious websites. Make it har […]

Hi Victor. The security model is sensible: assume the browser may eventually be compromised, then use least privilege, isolation and egress controls to limit the damage. However, the current post describes design intentions, not evidence that the controls work as claimed. I would not recommend installing this on a daily-use machine yet.

A few boundaries should be made explicit:

• Outbound restrictions can disrupt some command-and-control traffic, but a compromised browser may still communicate over permitted HTTPS or other normal web traffic.
• A separate browsing account protects only data that account cannot access. Cookies, sessions, passwords and anything entered or opened inside that browsing account remain exposed to a browser compromise.
• Managed browser policies are useful hardening, but they are not themselves a security boundary. The important details are the OS mechanisms being used—AppArmor, namespaces, seccomp, filesystem permissions, nftables and so forth.
• Anti-persistence controls may stop an infection surviving a reboot, but they cannot reverse data theft that already occurred during the session.

The biggest immediate concern is distribution. The linked file is a compressed shell script, while the installation command gives the decompressed script unrestricted root access. sudo bash is not automatically malicious, but it means the installer can alter essentially anything on the system. The browser may be going into a vault, but the installer receives the keys to the building.

Before asking people to run it, I think the beta needs:

1. Public, version-controlled source code, rather than only a mutable Google Drive artifact.
2. A release version, SHA-256 hash and preferably a detached digital signature.
3. A complete list of files, policies, users, services and firewall rules it creates or changes.
4. Documentation for --online: contacted servers, transmitted data, telemetry and update behaviour.
5. A tested uninstall/rollback procedure, including what happens when the 60 days expire.
6. Exact supported Kubuntu and Brave versions.
7. Clarification about whether the project has any relationship to Brave Software.
8. Confirmation that the secondary account must be a standard account with no sudo access or unnecessary group memberships.

For early testing, use a disposable VM snapshot containing no personal files or real browser accounts. Disable shared folders and, where practical, access from the VM to the local network. The artifact can first be decompressed and examined without running it:

gzip -dk -- bravevault-trial.sh.gz
sha256sum bravevault-trial.sh.gz bravevault-trial.sh
shellcheck bravevault-trial.sh

The underlying idea is worth testing, but trust should come from auditable implementation and reproducible results, not the length of the feature list. A published threat model and test matrix would make this much easier to evaluate seriously.

 

[Victor M]

Hi guys,

This is what I have been working on over the past month.

The tool is unfortunately heavily integrated with the desktop environment, so I am releasing the KDE Kubuntu version first.

Bot say the blurb above are design intentions, not proof that it works as claimed. Well, I did a limited automated assessment of the controls, and for the TTPs that they are built for, they work. New TTPs arrive every month, but they all try to accomplish the same things: establish persistence, privilege escalation, steal session cookies and so on. And I use Mitre Attack's taxonomy and examples as a comprehensive guide. A lot of the TTPs listed there are Windows only. So I say this is a do-able exercise. I am not going to go thru the work to publish my tests so don't ask.

The C2 prevention works like this. The surfing account has no networking. Most of the attacks will land in your surfing account, and they will be blind and deaf, as there is no way to pass anything out. Brave is in a separate account and a few pieces of plumbing was made so that key presses, sound, clipboard can travel back and forth to your account.

Infostealers typically arrive as fake software downloads. And because Brave is set up in a separate account, there is the account barrier that stops them from stealing your session cookies. Stolen session cookies are lethal because it enables an attacker to assume you connection session and use whatever web site you have open at the time. Passwords and MFA is then not a deterrent.

Persistence is mostly achieved by modifying a program's private data, an 'exec=' line in a config file in a dot directory inside your home, which the attacker modifies to point to her own executable. Another method she can use is to make per user services, starting the attacker's hackware. First of all, only exe's and scripts that are installed via your apt are allowed to run, courtesy of App Control. That takes care of most foreign malware. Then a good number of the ini files that are known to have these 'exec=' lines are premade and owned by root (inside your home). Services go into a particular directory and is owned by root similarly. So these cannot be modified by the attacker. If you happen to want to setup your own private service ( there's little reason to ) or install a package with a config file so aforementioned, then you will need to dismantle them yourself. But given the exec= line and the ability of an attacker who has assumed your account name I wouldn't recommend it. Remember what the surfing account can do, so can the attacker.

For privilege escalation control, we have banned kernel modules, set kernel parameters, set nosuid and nodev for some temporary directories, setuid/setgid reduction and App Control.

Then we have apparmor on our side. Brave and a few pieces of our machinery has it to confine what they can do.

Finally, I strongly advocate you to get a yubikey if your laptop don't have fingerprint capability. It presents a 2FA that protects your login and your sudo command. And an attacker simply cannot do sudo this and that without you touching your yubikey or fingerprint reader. Attackers can very easily setup a macro to do keyboard sniffing to sniff your sudo password, the yubikey will stop them. Some forum members already have one, they're just keeping it a secret.

And 2nd finally, remember to do apt update and apt upgrade every day. There's no telling what an exploited app or service can do. Kubuntu and Ubuntu have automatic updates by the way, so if you forget there is a backup. But you sleep easier by doing it manually.

 

[Victor M]

Hi Guys,

The Ubuntu version is ready.

 

[Victor M]

Networking slower than I expected. Optimized networking more. Click on pop-out button, then click Download.

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

sha256sum: c9ff6e0e3ca9d5c819347e578ae2a0e9c218c619a353736ca6a98316690d64d3

 

[Victor M]

Don't underestimate the usefulness of the C2 mitigation. Without networking, the attacker can't 'see'. An 'ls' wouldn't work

And remember we have App Control, which is customized to stop foreign scripts as well. So his carefully debugged script won't run.

 

[Victor M]

Bot noted that a compromise to Brave itself can have the session cookies stolen, and there's not a thing I can do about it. Well, I thought for a moment and thought I could use my semi-capable ChatGPT Cyber account to find and fix Brave's vulnerabilities, and then let Anthropic's Fable engine have a go at it . Brave is open source and I can get the source code no probs. But the problem is MONEY. I have subscription for both but Anthropic's best bug hunting Fable engine is pay-as-you-go. And ChatGPT estimates it would require $20,000 - $250,000 . I am leaving Bot's challenge to more deep pocketed folks.

 

[Victor M]

In order to defend, one must place an emphasis on knowing the attacker's techniques (TTP). In the inet security package, I have sourced Mitre Attack's comprehensive taxonomy for their documented TTPs for attaining Persistence and Privilege Escalation - the first 2 important stages of an attack. Mitre abstracted the techniques out of real life attacks investigations and presents a guide to SOC teams analysts, so they can recognize an attack and defend their organizations. While techniques can be applied varyingly, and you can see the various APT's documented application of them; they were abstracted and classified because they stick to core mechanisms.

10 mapped technique entries
1. Anti-persistence: 6
MITRE ATT&CK ID Implemented protection
T1547.013 XDG autostart entries frozen
T1543.002 User systemd services blocked from modification
T1053.006 User systemd timers constrained
T1053.002 at jobs removed and future submissions denied
T1053.003 Cron jobs removed and future submissions denied
T1176.001 Brave and Firefox extension installation restricted by administrator policy

2. Anti-privilege-escalation: 4
MITRE ATT&CK ID Implemented protection
T1548 Sudo restrictions, polkit authorization restrictions, setuid/setgid removal, and su restrictions
T1068 Kernel hardening settings and blocking 18 rarely used kernel modules
T1055 Ptrace restrictions and kernel process-information protection
T1611 Removal of subordinate UID/GID ranges, restricting multi-UID rootless containers
Within T1548, the inet security package also explicitly implements T1548.001 (setuid/setgid) and T1548.003 (sudo).

I leave the detection of an attack's initial entry method via malware to your choice of AV's like clamav, Dr. Web and Kaspersky for Linux or other business class AV's. Another essential administrative control that touches initial entry is vulnerability management. Basically you do vuln scans and patch the OS and apps. There are other important controls, and you can google for 'CIS Critical Security Controls' to find the PDF.

 

[Victor M]

This is the RMF Assessment report of Ubuntu BraveVault Inet Security. And I am not posting selftest.txt - too revealing of the inner workings.

BRAVEVAULT UBUNTU TECHNICAL SECURITY ASSESSMENT (RMF-ALIGNED)
UTC: 2026-11-14T04:17:40.923419+00:00
Version: 2.6ax
Assessment: PASS_WITH_LIMITATIONS (not formal NIST RMF authorization)
Evidence: selftest.txt / mitigation-evidence.tsv / assessment.json
Each control reference is a partial mapping only; not full organizational control satisfaction.

CONTROL REFERENCE | RESULT | METHOD | EVIDENCE GATE | MITIGATION
CM-6     | PASS      | mixed         | SECURE_CODING_GATE                      | Secure execution configuration
CM-6     | PASS      | live          | ADMINISTRATOR_PRELOGIN_GATE             | Administrator boot-time lockdown
CM-7     | PASS      | mixed         | DESKTOP_PERSISTENCE_GATE                | Desktop anti-persistence
CM-7     | PASS      | live          | VAULT_PERSISTENCE_GATE                  | Vault immutable path protections
CM-7     | PASS      | mixed         | LOGIN_DBUS_GATE                         | User service persistence controls
CM-6     | PASS      | live          | DESKTOP_APP_STATE_GATE                  | Desktop app writable state
CM-6     | PASS      | mixed         | BROWSER_PROFILE_GATE                    | Browser profile cleanup
CM-7     | PASS      | configuration | BRAVE_EXTENSIONS_GATE                   | Brave extension management
SI-7     | PASS      | mixed         | MITRE_GUARD_GATE                        | MITRE guard startup integrity / USB
AC-6     | PASS      | mixed         | PRIVESC_GATE                            | Privilege escalation constraints
CM-6     | PASS      | mixed         | SETTINGS_GATE                           | Configured/applied settings consistency
SC-7     | PASS      | live          | NETWORK_GATE                            | Network/C2 denial
AC-3     | PASS      | mixed         | DEVICE_GATE                             | Device access and peripheral policy
AU-6     | PASS      | mixed         | ALERTS_GATE                             | Auditing and alert collection
AC-3     | PASS      | live          | BROKER_SCOPE_GATE                       | Broker operation authorization
CM-6     | PASS      | configuration | GNOME_PORTAL_POLICY_GATE                | GNOME portal config
CM-6     | PASS      | configuration | GNOME_SESSION_DBUS_POLICY_GATE          | Host same-user D-Bus policy file
AC-3     | PASS      | live          | GNOME_SCREENSHOT_BASH_C_GATE            | Bash -c real screenshot method denial
AC-3     | PASS      | live          | GNOME_SCREENSHOT_PYTHON_C_GATE          | Python real screenshot method denial
SC-7     | PASS      | live          | HOST_WAYLAND_SOCKET_GATE                | Host GNOME Wayland socket separation
AC-3     | PASS      | live          | GNOME_VAULT_DESKTOP_CAPABILITY_GATE     | Vault/Cage host desktop capability denial
AC-3     | PASS      | live          | INPUT_INJECTION_GATE                    | Input injection device denial
CM-7     | PASS      | live          | EXEC_ALLOWLIST_GATE                     | Untrusted executable enforcement
AC-6     | PASS      | live          | BROKER_SELFTEST_GATE                    | Confined broker/browser runtime
SC-7     | PASS      | live          | GNOME_PROTECTED_DESKTOP_BOUNDARY_GATE   | Protected desktop combined boundary
SI-7     | PASS      | live          | FILELESS_GATE                           | Fileless execution mitigation
CM-6     | PASS      | live          | LOCKDOWN_GATE                           | Kernel confidentiality lockdown and GRUB boot setting
AC-4     | PASS      | live          | VAULT_ISOLATION_GATE                    | Inter-vault isolation
SC-7     | PASS      | mixed         | WAYLAND_FILTER_GATE                     | Wayland proxy filter
AC-4     | PASS      | mixed         | IPC_POLICY_GATE                         | Enforced Unix IPC rules and POSIX+SysV queue denial
AC-4     | PASS      | equivalent-kernel | IPC_SYSV_SYSTEMD_KERNEL_GATE            | Broker systemd System V mqueue kernel denial
AC-4     | PASS      | equivalent-kernel | IPC_POSIX_MQUEUE_GATE                   | Broker POSIX mqueue kernel denial (service-scoped)
AC-4     | PASS      | equivalent-kernel | IPC_MQUEUE_EXEC_GATE                    | Credential dropper inherits broker service seccomp

ASSESSMENT COUNTS: {'PASS': 33, 'FAIL': 0, 'UNTESTED': 0, 'PARTIAL': 0, 'N/A': 0}
INDIVIDUAL PERSISTENCE TARGETS: 180 total; 180 passed; 0 failed

FINDINGS / POA&M CANDIDATES (human review before overrides):
BV-RMF-001 [INFORMATIONAL] AC-3 Bash/Python screenshot probes exercise GNOME Shell Screenshot.Screenshot only; remote desktop and other portal capture methods were not exercised; action: Treat these as scoped tests, not comprehensive proof that same-UID capture is impossible
BV-RMF-002 [INFORMATIONAL] SC-7 Remote desktop over other identities/local IPC and full Wayland protocol analysis are outside tested scope; action: Retain network confinement; assess separate service identities when required

UNCOVERED OR PARTIAL SECURITY SCOPE:
- No real compromise, browser sandbox escape or kernel exploit was launched
- The nine invented-method D-Bus probes were retired; their old failures are not treated as successes
- Host session D-Bus policy inspection is configuration-only, not same-user enforcement proof
- Screen denial measured only via GNOME Shell Screenshot.Screenshot from bash -c and python -c
- No comprehensive GNOME portal/remote-desktop active session or Wayland protocol audit
- Read-only upload mirror and normal Linux DAC/AppArmor do not establish an allowlist of all host-readable files
- IPC assessment checks the actual running GNOME broker seccomp mode and an equivalent transient systemd POSIX+SysV denial, including fork/exec inheritance. This does not directly invoke IPC syscalls inside the real broker or prove that all browser, clipboard, same-UID desktop, or host IPC endpoints are isolated. AppArmor feature ABI remains at the verified r64 baseline
- Installer selftests include static and live probes; control labels do not equal full SP 800-53 control satisfaction
- Independent assessor, organizational impact categorization, risk acceptance, POA&M owners/dates and ATO are outside this automated report

 

[LinuxFan58]

@Victor M

You made clear what the protections and defenses are, but for who did you develop this (what is your target audience/user group)? What happens after the 60 day trial?

 

[Ice Dream']

it depends
jitless browsers aren't immune
uh.. complete port requests and scan by lookout isn't an approach but I feel like many users try their best with these tools in order to, influence a huge audience and gain some reputation by some authorized vendor/company guild.
At the end some of these users end up developing a different product of that company. It sort of works similar to how book selling does.
very few remain an isolated GitHub repo.