LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 11-07-2009, 11:26 AM   #1
kornelix
Member
 
Registered: Oct 2005
Location: Germany
Distribution: Ubuntu
Posts: 57

Rep: Reputation: 24
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?
 
Old 11-07-2009, 12:16 PM   #2
ammorais
Member
 
Registered: Nov 2009
Location: Lisbon, Portugal
Distribution: Gentoo, CentOs, Ubuntu, Debian
Posts: 182

Rep: Reputation: 49
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.
 
Old 11-07-2009, 02:17 PM   #3
tredegar
LQ 5k Club
 
Registered: May 2003
Location: London, UK
Distribution: Debian "Jessie"
Posts: 6,036

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
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.
 
Old 11-07-2009, 02:23 PM   #4
pcunix
Member
 
Registered: Dec 2004
Location: MA
Distribution: Various
Posts: 149

Rep: Reputation: 23
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.
 
Old 11-07-2009, 02:28 PM   #5
tredegar
LQ 5k Club
 
Registered: May 2003
Location: London, UK
Distribution: Debian "Jessie"
Posts: 6,036

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
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?
 
Old 11-07-2009, 02:33 PM   #6
kornelix
Member
 
Registered: Oct 2005
Location: Germany
Distribution: Ubuntu
Posts: 57

Original Poster
Rep: Reputation: 24
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.
 
Old 11-07-2009, 02:42 PM   #7
tredegar
LQ 5k Club
 
Registered: May 2003
Location: London, UK
Distribution: Debian "Jessie"
Posts: 6,036

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
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).
 
Old 11-07-2009, 03:24 PM   #8
pcunix
Member
 
Registered: Dec 2004
Location: MA
Distribution: Various
Posts: 149

Rep: Reputation: 23
Quote:
Originally Posted by kornelix View Post
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.
 
Old 11-07-2009, 08:49 PM   #9
GrapefruiTgirl
Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

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

Sasha
 
Old 11-08-2009, 12:01 AM   #10
kornelix
Member
 
Registered: Oct 2005
Location: Germany
Distribution: Ubuntu
Posts: 57

Original Poster
Rep: Reputation: 24
Quote:
Originally Posted by tredegar View Post
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.
 
Old 11-08-2009, 03:28 AM   #11
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,666
Blog Entries: 54

Rep: Reputation: 2952Reputation: 2952Reputation: 2952Reputation: 2952Reputation: 2952Reputation: 2952Reputation: 2952Reputation: 2952Reputation: 2952Reputation: 2952Reputation: 2952
Quote:
Originally Posted by kornelix View Post
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 View Post
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.
 
  


Reply

Tags
sync


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
check the security hole ust Linux - Security 6 09-10-2004 06:42 PM
panther security hole??? feetyouwell General 5 04-19-2004 11:03 AM
security hole or convenience? carboncopy Slackware 3 08-13-2003 04:07 AM
Security Hole -Samba dvong3 Linux - Security 1 03-21-2003 03:38 PM
Security Hole in PHP 4.3.0 Crashed_Again Linux - Security 1 03-01-2003 04:29 PM


All times are GMT -5. The time now is 11:40 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration