Hello, I've been playing a bit with the "noexec" flag for filesystems. It can represent a substantial obstacle against the exploitation of security holes. However, I think it's not perfect yet. First thing, an attempt to execute a program from a noexec-mounted filesystem should be logged. It is either a very significant security event, or it can drive nuts an administrator trying to install software. (I like to mount with noexec filesystems such as /var, /var/ www, /var/spool, /var/tmp, /tmp, /home whenever the users are not supposed to install software...). I opened a PR (a change request, actually) years ago about this, and it was closed with a reasonable answer. http://www.FreeBSD.org/cgi/ query-pr.cgi?pr=15435 However, as far as I know there is no such general logging facility. Wouldn't it be possible for especially sensible events to be logged? The patch I submitted is ugly, but it's better than nothing. There is another change about which I would like to read some opinions. Right now, the "noexec" flag is an all-or-nothing, which greatly reduces its usefulness. Packages and ports use to run programs from /var/tmp or /tmp, and the noexec flags applied to those filesystems won't allow software to be installed. Of course, you can upgrade the status of the filesystems with a mount -u, but that opens a window of opportunity; while the noexec flag has been removed, it is possible for any user to run programs from those directories. I think that it would be useful to have a man point here. What about allowing root, and only root, to run programs from a noexec mounted fs? Its behavior could be changed (for example) with a sysctl variable. My point here is this: I want to prevent a privilege escalation, so I want to prevent a user from executing a file he/she has just written. If it's not possible to execute programs from a directory where a normal user can write, either a public-write directory (/tmp et al) or a directory owned by him (take, for example, a directory with temporary files written by a PHP program or a CGI) it will be very difficult to achieve a privilege escalation. And, anyway, if the intruder found a way to achieve it, he could remove the noexec restriction with a mount -u. I know, both situations have their own caveats (and I can imagine an intruder leaving a periodic process trying to run a program from /var/ tmp), but imho this new behavior can make the noexec feature much more useful. Borja.
On Thursday, September 22, 2005 12:12 PM, Borja Marcos <> unleashed the infinite monkeys and produced:> First thing, an attempt to execute a program from a noexec-mounted > filesystem should be logged. It is either a very significant security > event, or it can drive nuts an administrator trying to install > software. (I like to mount with noexec filesystems such as /var, /var/ > www, /var/spool, /var/tmp, /tmp, /home whenever the users are not > supposed to install software...).As long as you can disable/limit the logging. One very nasty "attack" would be to loop trying to run a binary. Blow your logging partition. Somebody could then use that to do other things that would normally be logged, safe in the knowledge that their activities wouldn't be logged. I've seen systems brought to their knees by similar well intentioned logging activities. It's not pretty :) -- Rob | Oh my God! They killed init! You bastards!
[ oops, ommitted the CC line to freebsd-security@ ] May I throw in my two euros? security.noexec.log_bin: /sbin/trusted_logging_prog security.noexec.log_maxrate: N security.noexec.log_enabled: 0 security.noexec.log_enabled refuses to enable itself unless security.noexec.log_bin exists and has the correct permissions, etc. security.noexec.log_maxrate is the maximum allowed number of logs per second. If this rate is exceeded, wait for a preset grace period and then if logs are still pouring in, stop accepting logs and periodically write a loud WARNING line to the log (this would be watched by something like logcheck to alert the administrator). This would prevent the flood of logging taking out the machine and the grace period should allow enough logging to make sure we know who the culprit was. Of course, this is all theoretical. There's most likely a glaring error or omission... M PS: could this be implemented with the MAC framework somehow? Isn't this sort of thing exactly what it was meant for? -- pgp: http://www.darklogik.org/pub/pgp/pgp.txt 0160 A46A 9A48 D3B0 C92F B690 17FB 4B72 0207 ED43 ----- End forwarded message ----- -- pgp: http://www.darklogik.org/pub/pgp/pgp.txt 0160 A46A 9A48 D3B0 C92F B690 17FB 4B72 0207 ED43 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20050922/2eb30f46/attachment.bin
On 2005.09.22 13:11:43 +0200, Borja Marcos wrote:> I've been playing a bit with the "noexec" flag for filesystems. It > can represent a substantial obstacle against the exploitation of > security holes.Please note the following from the mount(8) manual page: noexec Do not allow execution of any binaries on the mounted file system. This option is useful for a server that has file systems containing binaries for architectures other than its own. Note: This option was not designed as a security feature and no guarantee is made that it will prevent malicious code execution; for example, it is still possible to execute scripts which reside on a noexec mounted partition. I don't know if it makes sense to log noexec failures, but at least it's important that people don't completely rely on noexec for security. -- Simon L. Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20050922/a0b90f58/attachment.bin
Borja Marcos wrote:> > Hello, > > I've been playing a bit with the "noexec" flag for filesystems. It can > represent a substantial obstacle against the exploitation of security > holes. >I think TPE (trusted path execution) would be the prefered solution to this problem. As others have pointed out, circumventing the 'noexec' attribute is pretty easy. That said, i don't think it is a bad idea to use this, but one should be aware of how this defense might be defeated. Instead of running "./script.sh" or "./script.pl" you just have to type /bin/sh script.sh or /usr/bin/perl script.pl which gives pretty much everything you need when it comes to using exploits. In linux you could also circumvent it by using /lib/ld.so exploit, but i'm not sure if that is "fixed" now or not. TPE requires all the binaries and subpaths to be owned by root. ie /home/ /home/user and /home/user/file need to be owned by root to allow execution. GRSec for linux provides this functionality aswell as Stephanie does for OpenBSD. Both solves the problems with interperters aswell, but i havent looked into how, just used system that uses TPE. If there are problems with TPE that people know about, please tell. Obvious things are mounted filesystems from other machines, like nfs. /andreas
>> Borja Marcos wrote: >> >> Hello, >> >> I've been playing a bit with the "noexec" flag for filesystems. It can >> represent a substantial obstacle against the exploitation of security >> holes. >> > > I think TPE (trusted path execution) would be the prefered solution to > this problem. As others have pointed out, circumventing the 'noexec' > attribute is pretty easy. That said, i don't think it is a bad idea to > use this, but one should be aware of how this defense might be defeated. > > Instead of running "./script.sh" or "./script.pl" you just have to type > /bin/sh script.sh or /usr/bin/perl script.pl which gives pretty much > everything you need when it comes to using exploits. In linux you could > also circumvent it by using /lib/ld.so exploit, but i'm not sure if that > is "fixed" now or not. > > TPE requires all the binaries and subpaths to be owned by root. ie > /home/ > /home/user and /home/user/file need to be owned by root to allow > execution. GRSec for linux provides this functionality aswell as > Stephanie does for OpenBSD. > > Both solves the problems with interperters aswell, but i havent looked > into how, just used system that uses TPE. If there are problems with > TPE that people know about, please tell. Obvious things are mounted > filesystems from other machines, like nfs. > > /andreasIMHO, It can be used as a security layer, if the noexec partition is used by a chroot'ed aplication. chroot'ing on the noexec partition would increase the eficiency of noexec. I think at least the intruder won't feel in a confortable enviroment when exploiting the chrooted aplication... --Aristeu
On 2005.09.23 22:55:56 +0100, markzero wrote:> With all that has been said so far, what is the actual point of > the noexec flag?From mount(8) (yes I like quoting the docs. when we have them ;) ): This option is useful for a server that has file systems containing binaries for architectures other than its own. -- Simon L. Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20050924/668d3e25/attachment.bin
> > On 2005.09.23 22:55:56 +0100, markzero wrote: > > With all that has been said so far, what is the actual point of > > the noexec flag? > > > >From mount(8) (yes I like quoting the docs. when we have them ;);) ): > > ????????This option is useful for a server that has file systems > ????????containing binaries for architectures other than its own.Sorry Simon and others, Where the least privilege principle gone? If there isn't any necessity to have normal or suid binaries on a partition, why enable it? Using it on a data-only partition with a chrooted application does not limit any possible damage? Like file upload and execution using an application security flaw could be stopped at some point. Saying one can easily do privilege escalation (like ppl are saying) doesn't eliminate the need of file permissions and other access policies. Regards, --aristeu