LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   Could sync be a security hole? (https://www.linuxquestions.org/questions/linux-security-4/could-sync-be-a-security-hole-767535/)

kornelix 11-07-2009 11:26 AM

Could sync be a security hole?
 
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?

ammorais 11-07-2009 12:16 PM

Once the sync command flushes the cache on to the disk there's nothing more to do so subsequent calls to sync command don't do anything unless any change happen on a file that needs to be flushed.

Quote:

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.
You can run any program as non root in a loop and it will consume CPU so you already have that option without root privileges.

Also by the reason I gave you it will not have significant impact on performance.

Try that yourself
Code:

while(true); do sync; done
Quote:

It requires no privileges by default (at least on my Ubuntu system)
Sync is a program that uses the sync system call. The sync system call like the write and read system calls doesn't require root privileges.

tredegar 11-07-2009 02:17 PM

Plenty of non-root commands can easily bring a PC to its knees.

Try giving yourself a fork bomb.

It's a good idea to look up how to recover from one before you try it.

And I suggest that you don't try it on your server.

pcunix 11-07-2009 02:23 PM

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.

tredegar 11-07-2009 02:28 PM

Quote:

Paradoxically enough, regularly flushing buffers can be a performance gain.
Warning: Off topic: OK, but sync may not be the best way to do it:
Try starting a (large) file download.
In a terminal issue sync
What happened to your download?

kornelix 11-07-2009 02:33 PM

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?

CPU-bound loops: yes it harms performance, especially if a vandal starts many looping processes. Intelligent scheduling and CPU quotas would help.

tredegar 11-07-2009 02:42 PM

Quote:

If sync is running in a loop then disk caching is effectively turned off. Is this not a performance problem?
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).

pcunix 11-07-2009 03:24 PM

Quote:

Originally Posted by kornelix (Post 3748437)
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.

GrapefruiTgirl 11-07-2009 08:49 PM

As this thread is security-related in nature, I have moved it to "Security" so that it may get better exposure.

Sasha

kornelix 11-08-2009 12:01 AM

Quote:

Originally Posted by tredegar (Post 3748441)
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.

unSpawn 11-08-2009 03:28 AM

Quote:

Originally Posted by kornelix (Post 3748794)
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.


Quote:

Originally Posted by kornelix (Post 3748794)
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.


All times are GMT -5. The time now is 06:41 PM.