3 ms·
i think this is useful in that against unsophisticated attackers and people who don't know it is there the protection will trigger. however, it sounds like it o
by benmmurphy 10y ago
i think this is useful in that against unsophisticated attackers and people who don't know it is there the protection will trigger. however, it sounds like it only is going to be triggering when a process forks. so if you have some exploit that raises your creds then just don't fork and you don't trigger the detection. you can do everything evil in the system you want to do without forking. and if you want the convenience of a shell you can just chmod suid a binary and exec that. anyway, i think this generally idea is interesting because you can do a lot with it and if you keep what you are doing a secret (because you are running a public cloud platform for example) then you can have quite effective protection against attackers that don't have insider information. but if you are running a public cloud probably one of your biggest threats are insiders. so meh.
- Matt3o12_ 10y agoWell, I don't think your idea is very good either. You are basically doing security through obscurity by not reveling your mitigation methods. Sure they can throw off many attackers but any dedicated one will eventually find vulnerabilities (especially if they are state actors). If you have some mitigation techniques available, you will be able to block many attacks while providing a good guideline what your software does not do and encourage "white hacks" to come up with better mitigations.
- mjg59 10y agoIt validates on every syscall that has a permission check. If you modify your process status without forking and then make a syscall, it'll still trigger. (disclaimer: author of this feature)
- benmmurphy 10y agoSorry. I completely misread the original post. That seems a lot more sound :)