How to prevent the execution of malicious commands?

sulekha · 10-16-2010, 10:22 AM

Hi all,

how to prevent the execution of the following commands or how to set a policy
or rule that prevents the execution of the following malicious commands

dd if=/dev/zero of=/dev/sda
rm -rf /

Guillermo Reisch · 10-16-2010, 12:15 PM

Already linux suport the prevention of that

You need to be root (or root level) to do " rm -rf / "
because: ls -la /
drwxr-xr-x 26 root root 4096 ago 21 19:04 .
only root (or sudoers) have r(Read)w(Write)x(eXecute) acces to "/"
Check who are in the sodoers group and a good pasword for root will prevent that malisios code

about: "dd if=/dev/zero of=/dev/sda"

ls -l /dev/sd*
brw-rw---- 1 root disk 8, 0 oct 16 14:53 /dev/sda
brw-rw---- 1 root disk 8, 1 oct 16 14:53 /dev/sda1
brw-rw---- 1 root disk 8, 2 oct 16 14:53 /dev/sda2
brw-rw---- 1 root disk 8, 3 oct 16 14:59 /dev/sda3
Only root (or sudoers) or people in "disk" group can kill your disk
So check who are in group "disk" and remove malicious users from that group

Saludos Guille

unSpawn · 10-16-2010, 12:40 PM

Quote:

Originally Posted by sulekha

how to prevent the execution of the following commands or how to set a policy or rule that prevents the execution of

Like in some of your previous threads you've posted nothing to show you've tried anything. Please make an effort next time. As said before, running 'rm -rf' or 'dd if=/dev/zero of=/dev/sda' as unprivileged user will result in a long stream of errors since the user is not allowed to delete files owned by others. Also note that moving these binaries to a custom location, changing access permissions or replacing these binaries with scripts are kludges in general require more maintenance than would be worth the effort (standards, updates). Asking for a policy or a rule requires knowing what MAC one uses (and you have given no information at all). GRSecurity has RBAC, there's SELinux and there's TOMOYO to name just a few.

With GRSecurity, given a first rule of

Code:

/ {
    / r
}

, this AFAIK should already keep '/bin/rm' from recursing into root and deleting anything. The 'dd' rule might look something like

Code:

/bin/dd {
    /dev/zero r
    /dev/sda r
}

Applying it to a specific user you could "bind" it to a role:

Code:

role unpriv u
    subject /
         / r
         /bin/dd rx
         /dev/zero r
         /dev/sda r
}

In addition GRSecurity includes Trusted Path Execution (TPE) meaning an unprivileged user introducing foreign binaries in the system (compiled elsewhere) will find he can not execute them when TPE is enabled. For more see http://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System.

Using TOMOYO, which has a path-based view of the system, a rule of

Code:

<kernel> /sbin/mingetty /bin/login /bin/bash /bin/rm
use_profile 3
allow_read /
allow_read/write /home

should deny a user to write to / (no "allow_write" rule) but allow it to read and write in /home. A rule for your 'dd' question then might look something like:

Code:

<kernel> /sbin/mingetty /bin/login /bin/bash /bin/dd
use_profile 3
allow_read /
allow_read /dev
allow_read /dev/sda

For more see http://tomoyo.sourceforge.jp/2.3/.

SELinux works on top of the "common" (discretionary ) access rights. So if a binary is owned by root user and group with octal access mode 0500 then SELinux will not allow a user with a different context to execute the binary. The following rule

Code:

module deny 1.0.0;

require {
  type unconfined_t;
  type fixed_disk_device_t;
}

allow unconfined_t fixed_disk_device_t:file read;

will allow unprivileged users ("unconfined" context) to read files in /dev. Since there's no "write" rule writing to a device is denied. With SELinux you do not apply rules to a resource directly but to roles and contexts so this looks a bit different then the others. For more see http://fedoraproject.org/wiki/Docs/D...e/Introduction, http://mdious.fedorapeople.org/drafts/html/index.html and Dan Walsh excellent web log at http://danwalsh.livejournal.com/.

* If anyone spots any errors in the rules above please tell me.

zhaozhou · 10-16-2010, 05:15 PM

Just a note, you should be fine using the DAC which Linux has built-in. No need for advanced access control lists such as unSpawn is suggesting, however, I would recommend you try them out.
They're great.