From e005bb9dcf283a42617302540b6d4318181ba520 Mon Sep 17 00:00:00 2001 From: Gr3y-foX Date: Sat, 18 Apr 2026 23:44:35 +0200 Subject: [PATCH 1/4] v0.1 --- PR_Fox.md | 221 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 147 +++++++++++++++++++++++++++++++++++- 2 files changed, 365 insertions(+), 3 deletions(-) create mode 100644 PR_Fox.md diff --git a/PR_Fox.md b/PR_Fox.md new file mode 100644 index 0000000..9197ac4 --- /dev/null +++ b/PR_Fox.md @@ -0,0 +1,221 @@ +# macOS Hardening Helper (v0.16) for Apple Silicon + +> Opinionated, interactive macOS hardening helper inspired by +> [drduh/macOS-Security-and-Privacy-Guide](https://github.com/drduh/macOS-Security-and-Privacy-Guide).[] + +idea of possible adding features to project, base on own expirience in build own sec script + +The design goal is: + +- **No “magic one‑click hardening”** – the user is always asked before impactful changes. +- **Reproducibility** – changes are implemented as shell logic, not manual click-through steps. +- **Transparency** – clear logging, no hidden behavior, no automatic FileVault enablement. + +The intent of this PR is not to prescribe a specific tool, but to suggest a few concrete, automatable improvements that could be reflected in the guide itself, with this helper serving as one possible implementation reference.[] + +--- + +## Features Overview + +### Base System Hardening + +The helper implements and validates a number of recommendations that already exist in the guide (firewall, Gatekeeper, FileVault, privacy defaults), and may serve as a reference for adding more explicit, Apple Silicon–specific examples to the documentation. + +In particular, the script: + +- Enforces strict shell behavior for hardening-oriented scripts (`set -uo pipefail`, error traps, clear log levels). +- Bootstraps **Homebrew** without using root and with explicit `brew --prefix` handling. + +These patterns could be mirrored in the guide as “example shell snippets” for readers who prefer reproducible command-line steps over purely GUI instructions. + +--- + +### 1.1 Security Tooling Orchestration + +The script implements a lightweight “security tooling orchestrator” on top of Homebrew and pipx: + +1. **Homebrew formulas:** + + - `lynis` — system audit. + +2. **Homebrew casks (Objective-See & friends):** + + - `LuLu` (firewall) + - `BlockBlock` + - `KnockKnock` + - `DoNotDisturb` + - `OverSight` + - `pareto-security` (daily use regular user app) + - Mergen.app https://github.com/sametsazak/mergen (analog lynis with gui and CIS Benchmark) Note: verify the project is actively maintained before recommending it in a production hardening workflow. + + + +### 1.2 Vulnerability & Dependency Scanning + +The script encourages regular vulnerability scanning of packages and dependencies: + +- **Homebrew package CVEs:** + - Integrates `brew-vulns` tap and formula. + - Installs or updates `brew-vulns`. + - Warns if the binary is not in `PATH` and suggests how to fix it. +- **Python dependency CVEs:** + - Installs **pipx** when needed. + - Installs or upgrades **pip-audit** via pipx. + - Checks for outdated pip-audit versions and offers to upgrade. + - Encourages running `pip-audit` against Python environments + +### 1.3 CIS-Style pmset Baseline + +For mobile and desktop use (not hardened servers), the script: + +- Displays current `pmset -g` values for transparency. +- Offers to apply a CIS‑style baseline: + - `sleep` = 15 minutes + - `displaysleep` = 10 minutes + - `womp` = 0 (Wake on network disabled) + +The user can accept or decline this baseline. On hardened server/lab setups, it is explicitly marked as optional and potentially undesirable. + +## 2. Additional Hardening Suggestions for the Guide + +Beyond the existing content, there are a few small, targeted changes that would strengthen local security and auditability while remaining easy to explain and to automate. + +### 2.1 Disable interactive root login + +For single‑user laptops and workstations where interactive root is not required, the guide could recommend explicitly disabling the root account and its login shell. + +Example steps: + +```sh +# Disable the root account +sudo dsenableroot -d + +# Ensure the root user cannot obtain an interactive shell +sudo dscl . -create /Users/root UserShell /usr/bin/false +``` + +This keeps root available for privilege escalation via `sudo` while reducing the risk of an attacker obtaining a persistent, interactive root shell via local or remote login. + +### 2.2 Improve sudo audit logging + +The guide already emphasizes the importance of `sudo` hygiene; a small addition would be to demonstrate how to log successful `sudo` calls through a dedicated [file] in `/etc/sudoers.d`, instead of editing `/etc/sudoers` directly. + +For example: + +```sh +sudo visudo -f /etc/sudoers.d/cis_sudoconfig +# inside that : +Defaults log_allowed #write detailed log with timestamp each use of sudo command +Defaults timestamp_type=tty #request user write sudo password in each new terminal session +Defaults timestamp_timeout=0 #set default sudo timeout to 0 seconds, make request password each time for use sudo (by default its 15 minutes) +``` + +This pattern keeps local hardening aligned with common CIS-style recommendations, improves forensic visibility, and is easy to deploy in both manual and automated setups. + +### 2.3 Encourage Secure Keyboard Entry in Terminal + +Terminal sessions are often where secrets (passwords, API keys, passphrases) are typed, yet many users are unaware of **Secure Keyboard Entry** in Terminal.app, which prevents other processes from eavesdropping on keystrokes. + +The guide could: + +- Explicitly recommend enabling Secure Keyboard Entry: + - Manually via: `Terminal > Settings > Profiles > Keyboard > Use Secure Keyboard Entry` + + `Enable Secure Keyboard Entry in Terminal (unless you use YubiKey or applications such as TextExpander).` + +- And, for managed environments, mention that this can be enforced via MDM by shipping a profile with: + - `PayloadType` = `com.apple.Terminal` + - `SecureKeyboardEntry` = `true` + + > Already in the guide: *"Enable Secure Keyboard Entry in Terminal..."* + > Suggested addition: MDM enforcement note (`PayloadType: com.apple.Terminal`, `SecureKeyboardEntry: true`) for managed environments + +--- + +## 3. Idea of Separated Profiles for Web Browsing + +### 3.1 VPN Daily Profile Module (Concept) + +Goal: reasonable privacy and security for everyday use without breaking too many workflows. + +### Core Ideas + +- Require a trusted VPN client: + - Example: OpenVPN, WireGuard, or a reputable first‑party macOS client. +- Integrate with the rest of the hardening ecosystem: + - Ensure macOS Application Firewall is enabled. + - Leverage `dnscrypt-proxy` or provider’s DNS to avoid leaks. +- Provide simple checks: + - External IP/VPN status check (`curl` to a trusted endpoint). + - DNS leak test (opening well‑known test sites in the browser). + - Optional logging via Privoxy / proxy toggles. + +### Typical Workflow + +1. User starts the VPN Daily profile script. +2. Script checks: + - Is the VPN client installed? + - Is the connection up? (Basic IP + DNS checks) +3. Script optionally: + - Launches the VPN client if not running. + - Configures system DNS toward: + - Trusted resolver (e.g., Quad9), and/or + - Local `dnscrypt-proxy` if installed. +4. Script prints clear “safe to use / not safe to use” status and links to DNS/IP leak tests. + +No VPN provider is hardcoded; the module is meant to be adapted to the user’s provider of choice. + +### 3.2 Paranoid Tor Profile Module (Concept) + +**File:** `profile-paranoid-tor.sh` + +Goal: maximize network anonymity at the cost of convenience and performance. + +### Threat Model + +- Assumes the user is willing to: + - Accept slower connections. + - Compartmentalize activities into Tor‑only contexts. + - Respect strict “no direct clearnet from this profile” rules. + +### Core Ideas + +- Use Tor (or Tor Browser Bundle) as the primary egress: + - Optionally route traffic through local SOCKS proxy exposed by Tor. +- Integrate with Privoxy / dnscrypt‑proxy where appropriate: + - HTTP proxying via Privoxy → Tor. + - DNS handled by Tor / dnscrypt to minimize leaks. +- Tight firewall rules: + - Limit outbound traffic to Tor and local proxies. + - Optionally block all non‑Tor outbound connections from selected network interfaces or user contexts. + +### Typical Workflow + +1. User starts the Paranoid Tor profile script. +2. Script checks: + - Is Tor/Tor Browser installed? + - Is Privoxy installed (if using Privoxy + Tor chain)? +3. Script: + - Starts Tor/Privoxy if needed. + - Adjusts system / application proxy settings to route selected traffic via Tor. + - Optionally adds stricter PF rules or app‑level constraints (conceptual; exact rules depend on user’s environment and risk tolerance). +4. Script prints: + - Which interfaces/ports are restricted. + - Which applications are expected to use Tor‑only paths. + - How to revert back to a normal profile. + +The Tor profile is intentionally designed as an **opt‑in “mode”**, not something that silently rewires the entire system without the user’s consent. + +## 4. How this aligns with the guide + +The helper intentionally follows the same philosophy as the original guide: + +- All impactful changes are optional, explained, and logged. +- Defaults aim for a reasonable balance between security and usability for a single macOS client, not an enterprise fleet.[] +- Hardening steps are implemented as small, auditable shell functions that map directly to guide sections (firewall, privacy defaults, security tooling, power management).[] + +By incorporating the additional points above (root account lockdown, sudo logging via `/etc/sudoers.d`, and Secure Keyboard Entry / MDM hints), the guide would: + +- Cover a few important but currently under‑documented macOS knobs. +- Provide concrete command-line and configuration examples that are easy to automate. +- Stay consistent with the existing “teach, don’t blindly automate” philosophy while acknowledging that many users will script these steps as shown in this helper. \ No newline at end of file diff --git a/README.md b/README.md index cdf8e26..c88aab9 100644 --- a/README.md +++ b/README.md @@ -221,6 +221,22 @@ It is considered a best practice by [Apple](https://help.apple.com/machelp/mac/1 It is not strictly required to ever log into the admin account via the macOS login screen. When a Terminal command requires administrator privileges, the system will prompt for authentication and Terminal then continues using those privileges. To that end, Apple provides some [recommendations](https://support.apple.com/HT203998) for hiding the admin account and its home directory. This can be an elegant solution to avoid having a visible 'ghost' account. +For single-user laptops and workstations, consider explicitly disabling +the root account login shell to reduce the risk of persistent interactive +root access via local or remote login: + +```console +# Disable the root account +sudo dsenableroot -d + +# Prevent root from obtaining an interactive shell +sudo dscl . -create /Users/root UserShell /usr/bin/false +``` + +This keeps privilege escalation available via `sudo` while eliminating +a persistent interactive root shell as an attack surface. + + ## Caveats * Only administrators can install applications in `/Applications` (local directory). Finder and Installer will prompt a standard user with an authentication dialog. Many applications can be installed in `~/Applications` instead (the directory can be created). As a rule of thumb: applications that do not require admin access – or do not complain about not being installed in `/Applications` – should be installed in the user directory, the rest in the local directory. Mac App Store applications are still installed in `/Applications` and require no additional authentication. @@ -229,6 +245,8 @@ It is not strictly required to ever log into the admin account via the macOS log * There are third-party applications that will not work correctly because they assume that the user account is an admin. These programs may have to be executed by logging into the admin account, or by using the `open` utility. * See additional discussion in [issue 167](https://github.com/drduh/macOS-Security-and-Privacy-Guide/issues/167). + + ## Setup Accounts can be created and managed in System Preferences. On settled systems, it is generally easier to create a second admin account and then demote the first account. This avoids data migration. Newly installed systems can also just add a standard account. @@ -248,6 +266,20 @@ dscl . -read /Users/ GeneratedUID See also [this post](https://superuser.com/a/395738) for more information about how macOS determines group membership. +For single-user laptops and workstations, consider disabling the root +account's login shell to reduce the risk of an attacker obtaining a +persistent interactive root session via local or remote login: + +```console +sudo dsenableroot -d +sudo dscl . -create /Users/root UserShell /usr/bin/false +``` + +The first command disables the root account via Directory Services. +The second ensures that even if the account is re-enabled, it cannot +spawn an interactive shell. Privilege escalation via `sudo` remains +unaffected. + # Firmware You should check that firmware security settings are set to [Full Security](https://support.apple.com/guide/mac-help/mchl768f7291/mac) to prevent tampering with your OS. This is the default setting. @@ -452,6 +484,35 @@ If a program isn't available through the App Store, consider using [Homebrew](ht Remember to periodically run `brew upgrade` on trusted and secure networks to download and install software updates. To get information on a package before installation, run `brew info ` and check its formula online. You may also wish to enable [additional security options](https://github.com/drduh/macOS-Security-and-Privacy-Guide/issues/138), such as `HOMEBREW_NO_INSECURE_REDIRECT=1` +To check installed Homebrew packages for known CVEs, consider using +[brew-vulns](https://github.com/nicowillis/brew-vulns): + +```console +brew tap nicowillis/brew-vulns +brew install brew-vulns +brew vulns +``` + +If the `brew-vulns` binary is not found after installation, add +Homebrew's bin directory to your `PATH`: + +```console +export PATH="$(brew --prefix)/bin:$PATH" +``` + +For Python environments, consider auditing dependencies with +[pip-audit](https://github.com/pypa/pip-audit) via +[pipx](https://github.com/pypa/pipx): + +```console +brew install pipx +pipx install pip-audit +pip-audit +``` + +Run `pipx upgrade pip-audit` periodically to ensure the vulnerability +database is current. + According to [Homebrew's Anonymous Analytics](https://docs.brew.sh/Analytics), Homebrew gathers anonymous analytics and reports these to a self-hosted InfluxDB instance. To opt out of Homebrew's analytics, set `export HOMEBREW_NO_ANALYTICS=1` in the environment or shell rc file, or use `brew analytics off` @@ -1086,7 +1147,12 @@ To scan an application with multiple AV products and examine its behavior, uploa macOS comes with a built-in AV program called [XProtect](https://support.apple.com/guide/security/protecting-against-malware-sec469d47bd8). XProtect automatically runs in the background and updates its signatures that it uses to detect malware without you having to do anything. If it detects malware already running, it will work to remove and mitigate it just like any other AV program. -Applications such as [BlockBlock](https://objective-see.com/products/blockblock.html) or [maclaunch.sh](https://github.com/hazcod/maclaunch) might help prevent persistent malware. +Applications such as [BlockBlock](https://objective-see.com/products/blockblock.html), +[KnockKnock](https://objective-see.com/products/knockknock.html), +[OverSight](https://objective-see.com/products/oversight.html), +and [maclaunch.sh](https://github.com/hazcod/maclaunch) can help +detect and prevent persistent malware, unauthorized launch items, +and unexpected use of the camera or microphone. Locally installed **Anti-virus** programs are generally a double-edged sword: they may catch "garden variety" malware, but also may increase the attack surface for sophisticated adversaries due to their privileged operating mode. They also typically phone home to send samples in order to catch the newest malware. This can be a privacy concern. @@ -1453,7 +1519,7 @@ Keep your Mac physically secure at all times and do not leave it unattended in p A skilled attacker with unsupervised physical access could install a [hardware keylogger](https://trmm.net/Thunderstrike_31c3) to record all of your keystrokes. Using a Mac with a built-in keyboard or a bluetooth keyboard makes this more difficult as many off-the-shelf versions of this attack are designed to be plugged in between a USB keyboard and your computer. -To protect against physical theft during use, you can use an anti-forensic tool like [BusKill](https://github.com/buskill/buskill-app) or [swiftGuard](https://github.com/Lennolium/swiftGuard) (updated usbkill, with graphical user interface). All respond to USB events and can immediately shutdown your computer if your device is physically separated from you or an unauthorized device is connected. +To protect against physical theft during use, you can use an anti-forensic tool like [BusKill](https://github.com/buskill/buskill-app) or [swiftGuard](https://github.com/Lennolium/swiftGuard) (updated usbkill, with graphical user interface) (on 18.4.26 swiftguard doesnt lunch on m series macbook on macos 26 and higher). [DoNotDisturb](https://objective-see.com/products/donotdisturb.html) can alert when the lid of an unattended Mac is opened, providing an additional layer of physical access detection. All of these tools respond to USB events and can immediately shutdown your computer if your device is physically separated from you or an unauthorized device is connected. Consider purchasing a privacy screen/filter for use in public. @@ -1461,6 +1527,9 @@ Consider purchasing a privacy screen/filter for use in public. # System monitoring +For a higher-level view of the system's security posture, several +auditing tools can complement the low-level visibility of OpenBSM. + ## OpenBSM audit macOS has a powerful OpenBSM (Basic Security Module) auditing capability. You can use it to monitor process execution, network activity, and much more. @@ -1480,6 +1549,35 @@ Although `man audit` says the `-s` flag will synchronize the audit configuration See articles on [ilostmynotes.blogspot.com](https://ilostmynotes.blogspot.com/2013/10/openbsm-auditd-on-os-x-these-are-logs.html) and [derflounder.wordpress.com](https://derflounder.wordpress.com/2012/01/30/openbsm-auditing-on-mac-os-x/) for more information. +[Lynis](https://github.com/CISOfy/lynis) is an open source security +auditing tool that performs over 300 checks against the system and +produces a hardening index score with actionable findings: + +```console +brew install lynis +sudo lynis audit system +``` +Results are saved to `/var/log/lynis.log` and +`/var/log/lynis-report.dat`. The hardening index provides a +reproducible baseline — run periodically and compare scores over +time to track improvement. + +For users who find raw Lynis output difficult to interpret, +[Pareto Security](https://paretosecurity.com) provides a MenuBar +application that continuously audits the most impactful security +settings and surfaces failures in plain language — no terminal +required. + +[Mergen](https://github.com/sametsazak/mergen) is a GUI-based +auditing tool with CIS Benchmark checks, similar in scope to Lynis. +Verify the project is actively maintained before use in production +environments. (note - after Mergen audit resultats, dont blind click "fix all one button", look up what issue Mergen found, look up discribtion. If u feel profesional and accept resposobility and risks, u can open terminal and wrote command, unless u not sure - dont do anything, or ask for profesional guidness) + +To compare findings across tools, note that Lynis and Mergen surface +configuration weaknesses, while OpenBSM records runtime behavior. +They are complementary: auditors catch what is misconfigured, +OpenBSM catches what is happening. + ## DTrace [System Integrity Protection](https://github.com/drduh/macOS-Security-and-Privacy-Guide#system-integrity-protection) interferes with DTrace, so it is not possible to use it in recent macOS versions without disabling SIP. @@ -1555,6 +1653,30 @@ tshark -Y "ssl.handshake.certificate" -Tfields \ Disable [Diagnostics & Usage Data](https://support.apple.com/guide/mac-help/share-analytics-information-mac-apple-mh27990). +To improve auditability of privilege escalation without modifying +`/etc/sudoers` directly, create a dedicated drop-in file: + +`log_allowed` writes a timestamped entry for every successful `sudo` +invocation, improving forensic visibility. `timestamp_type=tty` ties +credential caching to the terminal session rather than the user +process, preventing credential reuse across concurrent sessions. +`timestamp_timeout=0` disables the 15-minute cache entirely — +every `sudo` call requires re-authentication. Adjust to taste +based on your threat model. + +```console +sudo visudo -f /etc/sudoers.d/audit_sudo +``` + +Add the following lines: + +# Log each successful sudo invocation with a timestamp +Defaults log_allowed +# Require password re-entry per TTY session, not per process +Defaults timestamp_type=tty +# Remove the default 15-minute credential cache +Defaults timestamp_timeout=0 + If you want to play **music** or watch **videos**, use QuickTime Player, the built-in media player in macOS. It uses the [App Sandbox](https://developer.apple.com/documentation/security/app_sandbox/protecting_user_data_with_app_sandbox), [Hardened Runtime](https://developer.apple.com/documentation/xcode/configuring-the-hardened-runtime), and benefits from the [Signed System Volume](https://support.apple.com/guide/security/signed-system-volume-security-secd698747c9/web) as part of the base system. If you want to use **torrents**, use [Transmission](https://transmissionbt.com/download/) which is free and open source (note: like all software, even open source projects, [malware may still find its way in](http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-ransomware-keranger-infected-transmission-bittorrent-client-installer/)). You may also wish to use a block list to avoid peering with known bad hosts - see [Which is the best blocklist for Transmission](https://giuliomac.wordpress.com/2014/02/19/best-blocklist-for-transmission/) and [johntyree/3331662](https://gist.github.com/johntyree/3331662). @@ -1637,9 +1759,28 @@ drwx------ 2 kevin staff 64 Dec 4 12:27 umask_testing_dir -rw-------@ 1 kevin staff 2026566 Dec 4 12:28 umask_testing_file ``` +For laptops and desktops, consider applying a CIS-style power +management baseline to reduce the window of an unattended unlocked +session: + +```console +sudo pmset -a sleep 15 +sudo pmset -a displaysleep 10 +sudo pmset -a womp 0 +``` + +`sleep` sets system idle sleep to 15 minutes, `displaysleep` dims +the display after 10 minutes, and `womp 0` disables Wake on LAN. +On server or lab setups this baseline may be undesirable — verify +with `pmset -g` before and after applying changes. + # Related software * [CISOfy/lynis](https://github.com/CISOfy/lynis) - Cross-platform security auditing tool and assists with compliance testing and system hardening. +* [sametsazak/mergen](https://github.com/sametsazak/mergen) - + A GUI-based system auditing tool with CIS Benchmark checks, + similar to Lynis. Verify the project is actively maintained + before use in production environments. * [Zentral](https://github.com/zentralopensource/zentral) - A log and configuration server for osquery. Run audit and probes on inventory, events, logfiles, combine with point-in-time alerting. A full Framework and Django web server build on top of the elastic stack (formerly known as ELK stack). * [osquery](https://github.com/osquery/osquery) - Can be used to retrieve low level system information. Users can write SQL queries to retrieve system information. * [Pareto Security](https://github.com/paretoSecurity/pareto-mac/) - A MenuBar app to automatically audit your Mac for basic security hygiene. @@ -1653,4 +1794,4 @@ drwx------ 2 kevin staff 64 Dec 4 12:27 umask_testing_dir * [Patrick Wardle's Objective-See blog](https://objective-see.com/blog.html) * [Reverse Engineering macOS blog](https://reverse.put.as/) * [Reverse Engineering Resources](http://samdmarshall.com/re.html) -* [iCloud security and privacy overview](https://support.apple.com/102651) +* [iCloud security and privacy overview](https://support.apple.com/102651) \ No newline at end of file From 0e07e2779633a69b9ee3504599608c7b44f4edcc Mon Sep 17 00:00:00 2001 From: Gr3y-foX Date: Sat, 18 Apr 2026 23:47:42 +0200 Subject: [PATCH 2/4] o.1 --- .gitignore | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..e69de29 From d0d00c4aa6660dc2200069c97b768a5dbafd8d7d Mon Sep 17 00:00:00 2001 From: Gr3y-foX Date: Sun, 19 Apr 2026 00:20:44 +0200 Subject: [PATCH 3/4] modified by Fox Division, Grey Fox --- .gitignore | 1 + README.md | 180 ++++++++++++++++++++++++++++++++++++++++++++++------- 2 files changed, 159 insertions(+), 22 deletions(-) diff --git a/.gitignore b/.gitignore index e69de29..45350ad 100644 --- a/.gitignore +++ b/.gitignore @@ -0,0 +1 @@ +PR_Fox.md diff --git a/README.md b/README.md index c88aab9..aad86ae 100644 --- a/README.md +++ b/README.md @@ -221,22 +221,6 @@ It is considered a best practice by [Apple](https://help.apple.com/machelp/mac/1 It is not strictly required to ever log into the admin account via the macOS login screen. When a Terminal command requires administrator privileges, the system will prompt for authentication and Terminal then continues using those privileges. To that end, Apple provides some [recommendations](https://support.apple.com/HT203998) for hiding the admin account and its home directory. This can be an elegant solution to avoid having a visible 'ghost' account. -For single-user laptops and workstations, consider explicitly disabling -the root account login shell to reduce the risk of persistent interactive -root access via local or remote login: - -```console -# Disable the root account -sudo dsenableroot -d - -# Prevent root from obtaining an interactive shell -sudo dscl . -create /Users/root UserShell /usr/bin/false -``` - -This keeps privilege escalation available via `sudo` while eliminating -a persistent interactive root shell as an attack surface. - - ## Caveats * Only administrators can install applications in `/Applications` (local directory). Finder and Installer will prompt a standard user with an authentication dialog. Many applications can be installed in `~/Applications` instead (the directory can be created). As a rule of thumb: applications that do not require admin access – or do not complain about not being installed in `/Applications` – should be installed in the user directory, the rest in the local directory. Mac App Store applications are still installed in `/Applications` and require no additional authentication. @@ -800,12 +784,18 @@ server: GitHub.com # Browser + The Web browser likely poses the largest security and privacy risk, as its fundamental job is to download and execute untrusted code from the Internet. An important property of modern browsers is the Same Origin Policy ([SOP](https://en.wikipedia.org/wiki/Same-origin_policy)) which prevents a malicious script on one page from obtaining access to sensitive data on another web page through the Document Object Model (DOM). If SOP is compromised, the security of the entire browser is compromised. Many browser exploits are based on social engineering as a means of gaining persistence. Always be mindful of opening untrusted sites and especially careful when downloading new software. +Regardless of browser choice, consider replacing the default search +engine. Google search queries are linked to your account and +browsing profile. See [Search engines](#search-engines) below for +alternatives suited to daily use. + Another important consideration about browser security is extensions. This is an issue affecting Firefox and [Chrome](https://courses.csail.mit.edu/6.857/2016/files/24.pdf) alike. The use of browser extensions should be limited to only critically necessary ones published by trustworthy developers. [Mozilla Firefox](https://www.mozilla.org/firefox/new), [Google Chrome](https://www.google.com/chrome), [Safari](https://www.apple.com/safari), and [Tor Browser](https://www.torproject.org/download) are all recommended browsers for their own unique and individual purposes. @@ -820,8 +810,17 @@ Firefox supports user-supplied configuration files. See [drduh/config/firefox.us Firefox [focuses on user privacy](https://www.mozilla.org/firefox/privacy). It supports [tracking protection](https://developer.mozilla.org/docs/Web/Privacy/Firefox_tracking_protection) in Private Browsing mode. The tracking protection can be enabled for the default account, although it may break the browsing experience on some websites. Firefox in Strict tracking protection mode will [randomize your fingerprint](https://support.mozilla.org/kb/firefox-protection-against-fingerprinting) to foil basic tracking scripts. Firefox offers separate user [profiles](https://support.mozilla.org/kb/profile-manager-create-remove-switch-firefox-profiles). You can separate your browsing inside a profile with [Multi-Account Containers](https://support.mozilla.org/kb/containers). + Firefox only supports Web Extensions through the [Web Extension Api](https://developer.mozilla.org/docs/Mozilla/Add-ons/WebExtensions), which is very similar to Chrome. Submission of Web Extensions in Firefox is free. Web Extensions in Firefox most of the time are open source, although certain Web Extensions are proprietary. +To change the default search engine: +*Settings → Search → Default Search Engine → choose from the list +or add a custom engine.* + +[DuckDuckGo](https://duckduckgo.com) is available by default. +[Brave Search](https://search.brave.com) can be added manually +via the search engine manager. + ## Chrome [Google Chrome](https://www.google.com/chrome) is based on the open source [Chromium project](https://www.chromium.org) with certain [proprietary components](https://fossbytes.com/difference-google-chrome-vs-chromium-browser): @@ -847,7 +846,16 @@ Read more about the benefits of disabling this [here](https://microsoftedge.gith You can block trackers with [uBlock Origin Lite](https://chromewebstore.google.com/detail/ublock-origin-lite/ddkjiahejlhfcafbddmgiahcphecmpfh). -Change the default search engine from Google to reduce additional tracking. +Change the default search engine from Google to reduce additional +tracking. Google search queries are linked to your Google Account +if signed in, and contribute to an advertising profile even in +Incognito mode. + +To change: *Settings → Search engine → Manage search engines → +Set as default.* + +See [Search engines](#search-engines) below for recommended +alternatives. Disable [DNS prefetching](https://www.chromium.org/developers/design-documents/dns-prefetching) (see also [DNS Prefetching and Its Privacy Implications](https://www.usenix.org/legacy/event/leet10/tech/full_papers/Krishnan.pdf) (pdf)). Note that Chrome [may attempt](https://github.com/drduh/macOS-Security-and-Privacy-Guide/issues/350) to resolve DNS using Google's `8.8.8.8` and `8.8.4.4` public nameservers. @@ -869,12 +877,83 @@ Safari follows a slower release cycle than Chrome and Firefox (3-4 minor release See also [el1t/uBlock-Safari](https://github.com/el1t/uBlock-Safari/wiki/Disable-hyperlink-auditing-beacon) to disable hyperlink auditing beacons. +To change the default search engine: +*Settings → Safari → Search → Search engine.* + +DuckDuckGo is available natively. Note that Safari still sends +search suggestions to Apple as you type — disable this in +*Settings → Safari → Search → Include Safari Suggestions* +if this is a concern. + ## Other browsers Many Chromium-derived browsers are not recommended. They are usually [closed source](https://yro.slashdot.org/comments.pl?sid=4176879&cid=44774943), [poorly maintained](https://plus.google.com/+JustinSchuh/posts/69qw9wZVH8z), and make dubious claims to protect privacy. +[Mullvad Browser](https://mullvad.net/en/browser) is developed in +collaboration between Mullvad VPN and the Tor Project. It applies +Tor Browser's anti-fingerprinting architecture without routing +traffic through the Tor network, making it suitable for use with +a VPN. + +The key design principle is crowd anonymity: all Mullvad Browser +users share an identical fingerprint. Rather than randomizing +parameters per-session (which itself becomes detectable), the +browser standardizes them across the entire user base — +`privacy.resistFingerprinting` is enabled by default, canvas +prompts are auto-declined, and hardware APIs that expose CPU +cores, memory, and keyboard layout are masked. + +JavaScript can be disabled or restricted per-site via the built-in +[uBlock Origin](https://github.com/gorhill/uBlock) extension in +advanced mode. This provides per-domain script control without +requiring additional configuration — enable it from the uBlock +Origin dashboard under *Filter lists*. + +Additional defaults include: +- Private browsing mode on by default — cookies, history, and cache + are deleted on exit +- First-party isolation (FPI) — trackers cannot correlate activity + across sites +- HTTPS-only mode enforced +- No telemetry collected + +!NOTE Mullvad Browser's fingerprint protection is strongest when +settings are left at their defaults. Modifying the configuration +can make your browser distinguishable from the crowd, reducing the +anonymity benefit. + +Mullvad Browser requires no Mullvad VPN subscription and is +[available for macOS](https://mullvad.net/en/download/browser). +When paired with any VPN, it provides a strong combination of +network-level and browser-level privacy. + Other miscellaneous browsers, such as [Brave](https://github.com/drduh/macOS-Security-and-Privacy-Guide/issues/94), are not evaluated in this guide, so are neither recommended nor actively discouraged from use. +## Search engines + +The default search engine in most browsers is Google, which +links queries to your account, IP address, and browsing history +to build an advertising profile. Changing the search engine is +one of the lowest-friction privacy improvements available. + +Recommended alternatives for daily use: + +- [DuckDuckGo](https://duckduckgo.com) — no search history stored, + no user profiling. Results sourced from Bing and its own crawler. + Supports `!bang` shortcuts (e.g., `!g query` to fall back to + Google for a single query without switching engines permanently). +- [Startpage](https://www.startpage.com) — proxies Google results + anonymously. Google index quality without Google seeing your IP + or identity. Useful when DuckDuckGo results are insufficient. +- [Brave Search](https://search.brave.com) — independent index, + no Google or Bing dependency, no tracking. + +!NOTE Changing the search engine reduces query-level tracking but +does not prevent browsers from sending data to their vendors through +other channels such as Safe Browsing, crash reports, or DNS +prefetching. Review each browser's section above for additional +mitigations. + ## Web browser privacy Web browsers reveal information in several ways, for example through the [Navigator](https://developer.mozilla.org/en-US/docs/Web/API/Navigator) interface, which may include information such as the browser version, operating system, site permissions, and the device's battery level. Many websites also use [canvas fingerprinting](https://en.wikipedia.org/wiki/Canvas_fingerprinting) to uniquely identify users across sessions. @@ -1036,6 +1115,19 @@ It may be worthwhile to consider the geographical location of the VPN provider. Also see this [technical overview](https://blog.timac.org/2018/0717-macos-vpn-architecture/) of the macOS built-in VPN L2TP/IPSec and IKEv2 client. +For checking your VPN on leaks u can use resources such: + #check for VPN DNS leaks + - https://ipleak.net/ + #check for DNS leaks + - https://www.dnsleaktest.com/ + #check for DNS leaks + - https://www.comparitech.com/privacy-security-tools/dns-leak-test/ + #VPN Test: IP, DNS & WebRTC + - https://vpntesting.com +Make sure: + - IP and geolocation → match the VPN, not your ISP + - DNS servers → belong to the VPN (or a neutral provider), but not your local ISP + # PGP/GPG PGP is a standard for signing and encrypting data (especially email) end-to-end, so only the sender and recipient can access it. @@ -1060,6 +1152,54 @@ Read [online](https://alexcabal.com/creating-the-perfect-gpg-keypair/) [guides]( # Messengers +## Notification Center privacy + +macOS stores all received notifications in a persistent SQLite +database at `/private/var/folders/`. This database retains +notification content — including message previews from Signal, +iMessage, and other messengers — in a recoverable form until +manually cleared, regardless of the encryption used by the +messenger itself. + +An attacker with physical or local access to the machine can +extract plaintext message content from this database without +breaking any cryptographic primitives. This was [demonstrated +by Patrick Wardle](https://objective-see.org/blog/blog_0x2E.html) +against Signal notifications on macOS. + +To reduce this exposure: + +**Disable message previews system-wide:** +*System Settings → Notifications → Show Previews → +set to "When Unlocked" or "Never"* + +**Per-app, disable notification persistence in each messenger:** + +- *Signal:* Settings → Notifications → Show → + set to "No Name or Message" +- *Telegram:* Settings → Notifications → Message Preview → + disable +- *iMessage:* System Settings → Notifications → Messages → + disable "Show Previews" +- *WhatsApp:* Settings → Notifications → disable + "Show Message Preview" + +**Clear the existing notification database manually:** + +```console +# View current notification database location +sudo find /private/var/folders -name "*.db" \ + -path "*notificationcenter*" 2>/dev/null + +# Restart Notification Center to flush in-memory state +killall NotificationCenter +``` + +> NOTE: macOS Sequoia moved the database location and added +> additional access restrictions. However, content is still +> stored until cleared. The mitigations above apply to all +> supported macOS versions. + ## XMPP XMPP is an [open standard](https://xmpp.org/extensions) developed by the [IETF](https://www.ietf.org) that allows for cross-platform federated messaging. There are many options for [clients](https://xmpp.org/getting-started). Consider using one of the browser-based clients to take advantage of the browser's sandbox. @@ -1147,11 +1287,7 @@ To scan an application with multiple AV products and examine its behavior, uploa macOS comes with a built-in AV program called [XProtect](https://support.apple.com/guide/security/protecting-against-malware-sec469d47bd8). XProtect automatically runs in the background and updates its signatures that it uses to detect malware without you having to do anything. If it detects malware already running, it will work to remove and mitigate it just like any other AV program. -Applications such as [BlockBlock](https://objective-see.com/products/blockblock.html), -[KnockKnock](https://objective-see.com/products/knockknock.html), -[OverSight](https://objective-see.com/products/oversight.html), -and [maclaunch.sh](https://github.com/hazcod/maclaunch) can help -detect and prevent persistent malware, unauthorized launch items, +Applications such as [BlockBlock](https://objective-see.com/products/blockblock.html), [KnockKnock](https://objective-see.com/products/knockknock.html), [OverSight](https://objective-see.com/products/oversight.html), and [maclaunch.sh](https://github.com/hazcod/maclaunch) can help detect and prevent persistent malware, unauthorized launch items, and unexpected use of the camera or microphone. Locally installed **Anti-virus** programs are generally a double-edged sword: they may catch "garden variety" malware, but also may increase the attack surface for sophisticated adversaries due to their privileged operating mode. They also typically phone home to send samples in order to catch the newest malware. This can be a privacy concern. From ff97e283dff0be4435f77bee4f7a8a6fba2d683f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Vik=20=E2=80=9CFox=E2=80=9D?= Date: Sun, 19 Apr 2026 00:34:22 +0200 Subject: [PATCH 4/4] Deleted temp --- PR_Fox.md | 221 ------------------------------------------------------ 1 file changed, 221 deletions(-) delete mode 100644 PR_Fox.md diff --git a/PR_Fox.md b/PR_Fox.md deleted file mode 100644 index 9197ac4..0000000 --- a/PR_Fox.md +++ /dev/null @@ -1,221 +0,0 @@ -# macOS Hardening Helper (v0.16) for Apple Silicon - -> Opinionated, interactive macOS hardening helper inspired by -> [drduh/macOS-Security-and-Privacy-Guide](https://github.com/drduh/macOS-Security-and-Privacy-Guide).[] - -idea of possible adding features to project, base on own expirience in build own sec script - -The design goal is: - -- **No “magic one‑click hardening”** – the user is always asked before impactful changes. -- **Reproducibility** – changes are implemented as shell logic, not manual click-through steps. -- **Transparency** – clear logging, no hidden behavior, no automatic FileVault enablement. - -The intent of this PR is not to prescribe a specific tool, but to suggest a few concrete, automatable improvements that could be reflected in the guide itself, with this helper serving as one possible implementation reference.[] - ---- - -## Features Overview - -### Base System Hardening - -The helper implements and validates a number of recommendations that already exist in the guide (firewall, Gatekeeper, FileVault, privacy defaults), and may serve as a reference for adding more explicit, Apple Silicon–specific examples to the documentation. - -In particular, the script: - -- Enforces strict shell behavior for hardening-oriented scripts (`set -uo pipefail`, error traps, clear log levels). -- Bootstraps **Homebrew** without using root and with explicit `brew --prefix` handling. - -These patterns could be mirrored in the guide as “example shell snippets” for readers who prefer reproducible command-line steps over purely GUI instructions. - ---- - -### 1.1 Security Tooling Orchestration - -The script implements a lightweight “security tooling orchestrator” on top of Homebrew and pipx: - -1. **Homebrew formulas:** - - - `lynis` — system audit. - -2. **Homebrew casks (Objective-See & friends):** - - - `LuLu` (firewall) - - `BlockBlock` - - `KnockKnock` - - `DoNotDisturb` - - `OverSight` - - `pareto-security` (daily use regular user app) - - Mergen.app https://github.com/sametsazak/mergen (analog lynis with gui and CIS Benchmark) Note: verify the project is actively maintained before recommending it in a production hardening workflow. - - - -### 1.2 Vulnerability & Dependency Scanning - -The script encourages regular vulnerability scanning of packages and dependencies: - -- **Homebrew package CVEs:** - - Integrates `brew-vulns` tap and formula. - - Installs or updates `brew-vulns`. - - Warns if the binary is not in `PATH` and suggests how to fix it. -- **Python dependency CVEs:** - - Installs **pipx** when needed. - - Installs or upgrades **pip-audit** via pipx. - - Checks for outdated pip-audit versions and offers to upgrade. - - Encourages running `pip-audit` against Python environments - -### 1.3 CIS-Style pmset Baseline - -For mobile and desktop use (not hardened servers), the script: - -- Displays current `pmset -g` values for transparency. -- Offers to apply a CIS‑style baseline: - - `sleep` = 15 minutes - - `displaysleep` = 10 minutes - - `womp` = 0 (Wake on network disabled) - -The user can accept or decline this baseline. On hardened server/lab setups, it is explicitly marked as optional and potentially undesirable. - -## 2. Additional Hardening Suggestions for the Guide - -Beyond the existing content, there are a few small, targeted changes that would strengthen local security and auditability while remaining easy to explain and to automate. - -### 2.1 Disable interactive root login - -For single‑user laptops and workstations where interactive root is not required, the guide could recommend explicitly disabling the root account and its login shell. - -Example steps: - -```sh -# Disable the root account -sudo dsenableroot -d - -# Ensure the root user cannot obtain an interactive shell -sudo dscl . -create /Users/root UserShell /usr/bin/false -``` - -This keeps root available for privilege escalation via `sudo` while reducing the risk of an attacker obtaining a persistent, interactive root shell via local or remote login. - -### 2.2 Improve sudo audit logging - -The guide already emphasizes the importance of `sudo` hygiene; a small addition would be to demonstrate how to log successful `sudo` calls through a dedicated [file] in `/etc/sudoers.d`, instead of editing `/etc/sudoers` directly. - -For example: - -```sh -sudo visudo -f /etc/sudoers.d/cis_sudoconfig -# inside that : -Defaults log_allowed #write detailed log with timestamp each use of sudo command -Defaults timestamp_type=tty #request user write sudo password in each new terminal session -Defaults timestamp_timeout=0 #set default sudo timeout to 0 seconds, make request password each time for use sudo (by default its 15 minutes) -``` - -This pattern keeps local hardening aligned with common CIS-style recommendations, improves forensic visibility, and is easy to deploy in both manual and automated setups. - -### 2.3 Encourage Secure Keyboard Entry in Terminal - -Terminal sessions are often where secrets (passwords, API keys, passphrases) are typed, yet many users are unaware of **Secure Keyboard Entry** in Terminal.app, which prevents other processes from eavesdropping on keystrokes. - -The guide could: - -- Explicitly recommend enabling Secure Keyboard Entry: - - Manually via: `Terminal > Settings > Profiles > Keyboard > Use Secure Keyboard Entry` - - `Enable Secure Keyboard Entry in Terminal (unless you use YubiKey or applications such as TextExpander).` - -- And, for managed environments, mention that this can be enforced via MDM by shipping a profile with: - - `PayloadType` = `com.apple.Terminal` - - `SecureKeyboardEntry` = `true` - - > Already in the guide: *"Enable Secure Keyboard Entry in Terminal..."* - > Suggested addition: MDM enforcement note (`PayloadType: com.apple.Terminal`, `SecureKeyboardEntry: true`) for managed environments - ---- - -## 3. Idea of Separated Profiles for Web Browsing - -### 3.1 VPN Daily Profile Module (Concept) - -Goal: reasonable privacy and security for everyday use without breaking too many workflows. - -### Core Ideas - -- Require a trusted VPN client: - - Example: OpenVPN, WireGuard, or a reputable first‑party macOS client. -- Integrate with the rest of the hardening ecosystem: - - Ensure macOS Application Firewall is enabled. - - Leverage `dnscrypt-proxy` or provider’s DNS to avoid leaks. -- Provide simple checks: - - External IP/VPN status check (`curl` to a trusted endpoint). - - DNS leak test (opening well‑known test sites in the browser). - - Optional logging via Privoxy / proxy toggles. - -### Typical Workflow - -1. User starts the VPN Daily profile script. -2. Script checks: - - Is the VPN client installed? - - Is the connection up? (Basic IP + DNS checks) -3. Script optionally: - - Launches the VPN client if not running. - - Configures system DNS toward: - - Trusted resolver (e.g., Quad9), and/or - - Local `dnscrypt-proxy` if installed. -4. Script prints clear “safe to use / not safe to use” status and links to DNS/IP leak tests. - -No VPN provider is hardcoded; the module is meant to be adapted to the user’s provider of choice. - -### 3.2 Paranoid Tor Profile Module (Concept) - -**File:** `profile-paranoid-tor.sh` - -Goal: maximize network anonymity at the cost of convenience and performance. - -### Threat Model - -- Assumes the user is willing to: - - Accept slower connections. - - Compartmentalize activities into Tor‑only contexts. - - Respect strict “no direct clearnet from this profile” rules. - -### Core Ideas - -- Use Tor (or Tor Browser Bundle) as the primary egress: - - Optionally route traffic through local SOCKS proxy exposed by Tor. -- Integrate with Privoxy / dnscrypt‑proxy where appropriate: - - HTTP proxying via Privoxy → Tor. - - DNS handled by Tor / dnscrypt to minimize leaks. -- Tight firewall rules: - - Limit outbound traffic to Tor and local proxies. - - Optionally block all non‑Tor outbound connections from selected network interfaces or user contexts. - -### Typical Workflow - -1. User starts the Paranoid Tor profile script. -2. Script checks: - - Is Tor/Tor Browser installed? - - Is Privoxy installed (if using Privoxy + Tor chain)? -3. Script: - - Starts Tor/Privoxy if needed. - - Adjusts system / application proxy settings to route selected traffic via Tor. - - Optionally adds stricter PF rules or app‑level constraints (conceptual; exact rules depend on user’s environment and risk tolerance). -4. Script prints: - - Which interfaces/ports are restricted. - - Which applications are expected to use Tor‑only paths. - - How to revert back to a normal profile. - -The Tor profile is intentionally designed as an **opt‑in “mode”**, not something that silently rewires the entire system without the user’s consent. - -## 4. How this aligns with the guide - -The helper intentionally follows the same philosophy as the original guide: - -- All impactful changes are optional, explained, and logged. -- Defaults aim for a reasonable balance between security and usability for a single macOS client, not an enterprise fleet.[] -- Hardening steps are implemented as small, auditable shell functions that map directly to guide sections (firewall, privacy defaults, security tooling, power management).[] - -By incorporating the additional points above (root account lockdown, sudo logging via `/etc/sudoers.d`, and Secure Keyboard Entry / MDM hints), the guide would: - -- Cover a few important but currently under‑documented macOS knobs. -- Provide concrete command-line and configuration examples that are easy to automate. -- Stay consistent with the existing “teach, don’t blindly automate” philosophy while acknowledging that many users will script these steps as shown in this helper. \ No newline at end of file