26.6 Defending Against Privilege Escalation
He sagla shiklyacha khara faayda – system asalamat thevne:
| Defence | What it stops |
|---|---|
| Least privilege | Give users/services only what they need; a foothold stays limited |
Careful sudo rules |
Never give broad NOPASSWD or editors/shells via sudo |
| Remove unnecessary SUID bits | Fewer SUID binaries = fewer escalation paths |
| Correct file/dir permissions | No world-writable scripts that root runs |
| Patch the kernel and packages | Closes local exploits (sudo yum update) |
| Separate service accounts | A hacked web app runs as www-data, not root |
| Auditing and monitoring | Detect enumeration and unexpected root shells (Part 11 SOC) |
For your own reels app and servers: run the web server and PHP as a low-privilege user, keep the OS updated with sudo yum update, and never store passwords or AWS keys in world-readable files.
Why this matters for security
A single low-privilege foothold is limited; privilege escalation is what turns a small breach into a full compromise. Enforcing least privilege and patching removes most escalation paths, so even a successful intrusion causes far less damage.
Ravindra Bagale's Tip
Sarvat mothi chuk: web app la root ne chalavne "mhanun sagla kaam sopa hoto". Asa kadhihi karu naka – to app hack zala tar attacker la thet root milto. Nehmi kami adhikaracha (least privilege) user ne service chalava. Hach ek niyam khup breaches thambavto.
Lab
On your own EC2 server, list SUID binaries and confirm your web app runs as a non-root user (ps aux | grep -E 'apache|nginx|php'). Then run sudo yum update and, in your notes, write two least-privilege changes you made or would make.