Linux · Lesson 13
Startup, Shell Profiles & Persistence Review
Review shell startup files, environment configuration, PATH behavior, XDG desktop autostart entries, and system-wide profile scripts while preserving legitimate user workflows.
Startup persistence is broader than cron and systemd. Commands can execute when a user opens a shell, signs in, starts a desktop session, or loads environment configuration. The goal is to trace each startup action to its real purpose and owner.
Lesson Snapshot
Learning objectives
Trace what launches when users sign in or open shells
Explain the difference between shell startup files, desktop autostart, system-wide profile scripts, and other startup mechanisms.
Inspect user and system startup locations without immediately deleting unfamiliar files or commands.
Identify persistence clues in shell profiles, XDG autostart entries, environment files, and startup scripts.
Trace a startup command to its owner, executable, package, permissions, and purpose before taking action.
Distinguish legitimate customization from misconfiguration, unauthorized persistence, and unknown behavior.
Preserve evidence before disabling suspicious startup behavior and verify required user workflows afterward.
Core idea
Startup behavior depends on session type
A local terminal, SSH login, graphical desktop session, and non-interactive script can load different files. Inspect the actual execution context instead of assuming one profile controls everything.
Persistence risk
One small profile line can execute repeatedly
A command placed in a widely loaded shell or desktop startup file can run every login or terminal launch. Preserve the file and referenced executable before cleanup.
Startup fundamentals
Six concepts behind session startup
Login shell
A login shell may read one set of profile files when a user signs in through a console, terminal, or remote session.
Interactive shell
Interactive shells can read shell-specific files such as .bashrc. These files often customize aliases, prompts, environment variables, and commands.
System-wide profile
Files under /etc can affect many users at once. A small change in a global profile can alter every interactive session.
Desktop autostart
Graphical environments can launch applications automatically when a user signs in. These entries are separate from shell profile files.
Environment configuration
Environment variables influence application behavior, search paths, proxies, language, and tool execution.
Persistence
Any mechanism that repeatedly launches a command at login or startup can be legitimate automation or a persistence technique. Context decides which.
Important startup paths
Shell and desktop persistence live in different locations
~/.bashrcCommon Bash interactive-shell configuration for a user.
May contain aliases, functions, PATH changes, or commands that run every time an interactive shell starts.
~/.profileCommon per-user login profile read by compatible shells or display managers.
A command here can affect login sessions even when .bashrc looks normal.
~/.bash_profileOptional Bash login profile that may be preferred over ~/.profile when present.
Its presence can change which profile file Bash reads at login.
/etc/profileSystem-wide login profile for many shell environments.
Changes can affect every user. Preserve evidence and understand downstream impact before editing.
/etc/profile.d/System-wide shell profile fragments commonly used by packages and administrators.
Many files are package-managed. Check package ownership before removing anything.
/etc/bash.bashrcSystem-wide Bash interactive-shell configuration on Ubuntu-family systems.
A command here can affect every Bash user session.
~/.config/autostart/Per-user XDG desktop autostart entries.
A .desktop file here can launch a program automatically at graphical login.
/etc/xdg/autostart/System-wide desktop autostart entries used by many Linux desktop environments.
Package-managed desktop components often place legitimate entries here.
/etc/environmentSystem-wide environment variable configuration used by some login/session components.
Not a general shell script. Treat its syntax differently from Bash files.
Session behavior
Different sessions can read different startup files
Bash login shell
/etc/profile, then the first applicable user login file such as ~/.bash_profile or ~/.profile
Exact behavior depends on shell and invocation mode. Do not assume every terminal reads the same file.
Bash interactive non-login shell
/etc/bash.bashrc and ~/.bashrc on typical Ubuntu-family systems
Opening a new terminal window commonly falls into this category.
Graphical desktop login
Desktop session files plus XDG autostart entries
A graphical session can launch applications without any shell profile command.
SSH login
Depends on shell and SSH session type
A remote interactive shell may read different profile files than a local GUI terminal.
Non-interactive script
Usually does not load the full interactive shell profile set
Do not rely on aliases or interactive environment behavior inside scripts.
Inspection first
Inventory startup behavior before editing it
ls -la ~Inventory user profile files including hidden shell startup files.
sed -n '1,220p' ~/.bashrcReview the user's Bash interactive configuration without editing it.
sed -n '1,220p' ~/.profileReview common per-user login profile content.
sudo sed -n '1,220p' /etc/profileReview system-wide login profile content.
sudo ls -la /etc/profile.dInventory system-wide profile fragments.
sudo grep -RInE 'curl|wget|nc|ncat|python|perl|bash -c|sh -c|/tmp/|/dev/shm/' /etc/profile /etc/profile.d /etc/bash.bashrc 2>/dev/nullSearch common global shell startup locations for commands that deserve closer review.
find ~/.config/autostart -maxdepth 1 -type f -name '*.desktop' -ls 2>/dev/nullInventory per-user desktop autostart entries when the directory exists.
sudo find /etc/xdg/autostart -maxdepth 1 -type f -name '*.desktop' -ls 2>/dev/nullInventory system-wide desktop autostart entries.
env | sortReview the current shell environment for unexpected PATH, proxy, or other variables.
printf '%s\n' "$PATH"Inspect the current command-search path in order.
stat /path/to/fileReview ownership, permissions, size, and timestamps for a suspicious startup file or script.
dpkg -S /path/to/fileCheck whether a startup file belongs to an installed Debian package.
Desktop autostart
Read the Exec field, not just the display name
NameHuman-readable label for the application or startup item.
ExecCommand launched by the desktop environment.
HiddenCan be used to disable an autostart entry in some desktop environments.
OnlyShowIn / NotShowInControls which desktop environments should or should not launch the item.
X-GNOME-Autostart-enabledGNOME-family extension that may indicate whether the item is enabled.
TypeCommonly Application for executable desktop autostart entries.
Example review target
Exec=/usr/bin/example-app --backgroundInvestigate the executable path, package ownership, user context, and purpose. A harmless-looking Name field does not prove what the entry actually launches.
PATH security
Command lookup order can change what actually runs
Search order matters
When a command is run without an absolute path, the shell searches PATH from left to right. Earlier directories can override later ones.
Writable directories increase risk
If an untrusted user can place executables in an early PATH directory, command hijacking becomes more plausible.
Current directory should be treated carefully
Including . in PATH can cause commands in the current working directory to run unexpectedly.
Absolute paths reduce ambiguity
Security-sensitive startup scripts should use explicit executable paths when practical.
sudo has its own environment rules
Do not assume the user's PATH and root's secure_path are identical.
Aliases are not universal
Aliases and shell functions affect interactive shells but may not apply to scripts or other execution contexts.
Classification
Required, legitimate, misconfigured, suspicious, or unknown
Required
Evidence
Supports a scenario-required shell environment, application, desktop component, or user workflow.
Response
Preserve it and secure the referenced files, permissions, and command path.
Legitimate
Evidence
Expected shell customization, package-owned environment setup, or known desktop component.
Response
Leave intact unless there is a specific security or configuration issue.
Misconfigured
Evidence
Unsafe PATH ordering, broken command, world-writable script, duplicate startup item, insecure proxy value, or incorrect user context.
Response
Correct the narrow issue while preserving the intended function.
Suspicious
Evidence
Unexpected network download, hidden executable, /tmp or /dev/shm launch, encoded command, root-owned global profile entry, or unexplained autostart command.
Response
Preserve the file, command, metadata, package status, logs, and referenced executable before disabling it.
Unknown
Evidence
Purpose, package origin, user impact, or referenced executable is unclear.
Response
Investigate further instead of deleting the file because the name looks unfamiliar.
Persistence indicators
Patterns that deserve closer review
Startup command points to /tmp or /dev/shm
Temporary memory-backed or world-writable locations can be useful to attackers and deserve close review.
Encoded shell command
Encoding or obfuscation can hide intent and raises investigation priority.
Global profile launches a network client
A command that contacts a remote endpoint every user login can create wide-impact persistence.
Per-user autostart entry with misleading name
A friendly desktop label can hide an unexpected Exec command.
Startup script recreates a deleted process or file
Repeated recreation suggests the startup mechanism is the persistence source.
World-writable referenced script
A legitimate startup mechanism becomes dangerous if lower-privileged users can alter what it executes.
Evidence-based reasoning
Trace startup behavior before you remove it
A line in ~/.bashrc launches a script
Weak response
Delete the line because startup commands are suspicious.
Better reasoning
Inspect the script, owner, permissions, package/application role, and whether the user intentionally needs it before deciding.
PATH begins with a user-writable directory
Weak response
Remove the whole PATH customization.
Better reasoning
Determine why the directory is present and whether privileged workflows rely on it. Correct unsafe ordering or permissions without breaking required tools.
A .desktop file autostarts an unfamiliar program
Weak response
Delete the .desktop file immediately.
Better reasoning
Inspect Exec, file ownership, package origin, desktop purpose, and the launched executable before disabling it.
A profile script uses curl
Weak response
Any startup download is malicious.
Better reasoning
Treat it as high priority because network retrieval at login is risky, but inspect source, destination, integrity checks, package ownership, and scenario purpose before concluding.
A file exists in /etc/profile.d
Weak response
It affects all users, so remove it.
Better reasoning
Many legitimate packages use /etc/profile.d. Check package ownership and contents before changing global shell behavior.
A profile file was recently modified
Weak response
Recent timestamp proves compromise.
Better reasoning
Use timestamps as one clue and correlate them with package upgrades, administrator work, logs, file contents, and other evidence.
Evidence sources
Preserve startup context before cleanup
User shell profile
sed -n '1,220p' ~/.bashrcShows aliases, functions, environment changes, and commands executed for interactive Bash sessions.
Login profile
sed -n '1,220p' ~/.profileShows per-user login initialization that may affect graphical or shell sessions.
Global profile fragments
sudo ls -la /etc/profile.dShows files that can affect many users at login.
Desktop autostart
find ~/.config/autostart -maxdepth 1 -type f -name '*.desktop' -ls 2>/dev/nullShows user-level graphical startup entries.
Environment
env | sortShows current variables that may influence paths, proxies, tools, and applications.
File metadata
stat /path/to/fileShows ownership, permissions, timestamps, and other filesystem metadata.
Controlled actions
Preserve first, then disable narrowly
Edit a user's Bash configuration
nano ~/.bashrcPreserve the original line or file before removing startup behavior.
Edit a system profile fragment
sudoedit /etc/profile.d/example.shGlobal changes affect multiple users. Confirm package ownership and required behavior first.
Disable one per-user desktop autostart entry
mv ~/.config/autostart/example.desktop ~/.config/autostart/example.desktop.disabledPreserves the original file for review better than immediate deletion. Use only when the item is confirmed unnecessary or unauthorized.
Validate shell syntax
bash -n /path/to/scriptSyntax validation does not prove the script is safe or appropriate to execute.
Review script ownership
stat /path/to/scriptCheck the full directory path too, not only the final file.
Check package ownership
dpkg -S /path/to/filePackage ownership provides context but does not replace content review.
High-risk shortcuts
Startup cleanup that can break user sessions or erase evidence
Deleting every unfamiliar line from .bashrc
Can break development tools, aliases, required environment variables, and legitimate user workflows.
Removing /etc/profile.d files without package checks
Can break installed software that depends on system-wide environment initialization.
Running an unfamiliar startup command manually
Can trigger the exact suspicious behavior you are trying to investigate.
Deleting autostart files before preserving them
Removes evidence about the command, label, desktop targeting, and referenced executable.
Changing PATH without understanding search order
Can make required commands disappear or cause different executables to run.
Treating timestamps as proof
Package updates and legitimate administrator actions can also create recent timestamps.
Verification
Prove the user's required session still works
Shell startup
Open a new authorized shell and confirm required environment variables, commands, and prompt behavior still work.
Login session
Verify required login workflows remain functional after profile changes.
Desktop session
Confirm expected desktop applications start and unauthorized autostart behavior no longer occurs.
PATH
Confirm command-search order is intentional and required tools still resolve correctly.
Persistence
Confirm removed or disabled startup behavior does not recreate the suspicious process or file.
Evidence
Confirm suspicious files, commands, metadata, and package information were preserved before destructive cleanup.
Defensive lab
Investigate fictional desktop startup persistence
Read the fictional scenario: Morgan requires a custom development PATH entry; the desktop environment uses several package-owned autostart items; an unknown user-level autostart entry launches /tmp/update-helper.
Inventory Morgan's shell profiles, system profile fragments, current PATH, per-user autostart entries, and system-wide autostart files without changing anything.
Preserve the unknown .desktop file, Exec command, referenced executable, ownership, permissions, timestamps, and package lookup.
Inspect whether the referenced executable launches a process, opens a network connection, or recreates itself in the fictional lab.
Classify the development PATH entry as Required, package-owned desktop entries as Legitimate, and the unknown autostart item as Suspicious only after evidence supports that conclusion.
Disable the confirmed unauthorized startup entry while preserving the original file and leaving required shell and desktop configuration intact.
Verify shell startup, PATH, graphical login behavior, required applications, and absence of suspicious process recreation.
Lesson checklist
Before moving on
I understand the difference between login-shell files, interactive-shell files, and desktop autostart entries.
I inspect both user-level and system-wide startup locations.
I know /etc/profile.d files are often package-managed and should not be deleted blindly.
I inspect Exec fields in .desktop autostart files instead of trusting their display names.
I review PATH order and writable directories before deciding a customization is safe.
I trace startup commands to their referenced scripts, executables, owners, packages, and permissions.
I treat unusual network or encoded startup commands as high-priority evidence, not automatic proof.
I preserve suspicious startup files before disabling them.
I avoid running unfamiliar startup commands manually during investigation.
I verify required shell and desktop workflows after changes.
Reflection
Check your reasoning
Question 1
Why might ~/.bashrc and ~/.profile behave differently?
Question 2
Why should package ownership be checked before removing a file from /etc/profile.d?
Question 3
How can PATH order create a command-hijacking risk?
Question 4
Why is a .desktop file's Name field less important than its Exec field during investigation?
Question 5
What evidence should be preserved before disabling a suspicious startup entry?
Question 6
What should you verify after removing unauthorized startup persistence from a user's session?
Carry this forward
Startup persistence can hide in shell profiles, environment files, desktop autostart entries, and global configuration. Map the execution context, preserve the evidence, and disable only the behavior that is actually unauthorized.