LinuxQuestions.org - How to prevent the execution of malicious commands?

Quote:

Originally Posted by sulekha (Post 4129566)

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.