Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
AFAIK the sync command flushes the cache for all mounted disks. It requires no privileges by default (at least on my Ubuntu system). If this were the case on a server, it seems anyone could run a script with sync in a loop, causing a debilitating performance hit.
Or is this program suid root on a server? Does every admin remember to do this?
Paradoxically enough, regularly flushing buffers can be a performance gain.
If you have a system where large amounts of disk blocks are being changed and you don't flush often, when the system does get around to it, there can be slowness while massive amounts of data are written.
I still have a problem. If sync is running in a loop then disk caching is effectively turned off. Is this not a performance problem?
Disk performance is a very complex issue. In addition to the OS flushing its disk cache buffers on whatever schedule it has been tuned for, many moderb disks have their own caching schemes which the OS driver may or may not have complete control of.
You are worried about sync but you didn't try my suggestion at post #3 ? Be prepared for a surprising "performance problem". (No lasting damage done though).
I have no doubt that a fork bomb, or a simple loop calling system(), would effectively kill a server. I did not need to try it.
In most server cases, where only vetted programs are being run, I guess this is no issue. It would be an issue in a time-sharing environment, such as a research supercomputer being used by many developers.
Where is the concept of quotas (CPU, pending I/Os, real memory, swap space, hard page faults, process count ...) whereby an OS can protect itself against vandals or buggy programs? I just now googled "linux quotas" and found nothing but disk quotas. The concepts go back about 40 years to Multics, and were implemented in VMS also.
In most server cases, where only vetted programs are being run, I guess this is no issue.
(...and guessing is what get people into trouble most of the time. "I guess I can enable this test account for now." "I guess this kernel upgrade can be postponed one more month." "I guess using [insert vulnerable application name] is OK." "I guess nobody will use this.") DoS, as in resource exhaustion, doesn't apply to only exotic scenarios like a research supercomputer but to any machine that is used to provide services in a stable, reliant and continuous way from SOHO machine to shell server to LAN NAS to Google. Proper basic machine configuration, not even extensive hardening, could help.
Originally Posted by kornelix
Where is the concept of quotas (CPU, pending I/Os, real memory, swap space, hard page faults, process count ...) whereby an OS can protect itself against vandals or buggy programs? I just now googled "linux quotas" and found nothing but disk quotas.
Apart from setting quota, nice, ionice, basic resource limiting can be done, albeit on a per account name or group basis: see 'man ulimit'. More extensive hardening can be done using for instance the GRSecurity kernel patch which should provide access to capabilities ('man capabilities') and features like trusted path execution (TPE) meaning users may only execute applications residing in a certain $PATH. The latter is an example of "doing things the right way" as preventing something is better than having to cure slash fix something.