Fedora Linux Support Community & Resources Center

Go Back   FedoraForum.org > Fedora 19/20 > Security and Privacy
FedoraForum Search

Forgot Password? Join Us!

Security and Privacy Sadly, malware, spyware, hackers and privacy threats abound in today's world. Let's be paranoid and secure our penguins, and slam the doors on privacy exploits.

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old 22nd October 2009, 06:03 AM
Zeitus42 Offline
Registered User
 
Join Date: Oct 2009
Posts: 53
linuxopera
Folder /tmp permissions

Hello all, I was just wondering why /tmp allows others to read and write out of the box. And whether programs depend on that functionality to run properly?

Isn't that the easiest way to compromise a OS? To modify tmp files and stuff?
Reply With Quote
  #2  
Old 22nd October 2009, 06:15 AM
kyryder
Guest
 
Posts: n/a
linuxmozilla
I don't really have a answer to your questions but I know that many make a script to delete everything in the /tmp and /var/tmp folders on shut down to help solve the problem.
Reply With Quote
  #3  
Old 22nd October 2009, 11:14 PM
unSpawn
Guest
 
Posts: n/a
linuxopera
Quote:
Originally Posted by Zeitus42 View Post
I was just wondering why /tmp allows others to read and write out of the box.
Because it's by default set up with 1777 access rights (writable by all, except for root only owner may delete own files).


Quote:
Originally Posted by Zeitus42 View Post
And whether programs depend on that functionality to run properly?
As it's the default $TMPDIR variable a lot of commandline applications and graphical subsystem components rely on it: for instance ssh-agent sets up sockets there as does xfs, hald and the X server.


Quote:
Originally Posted by Zeitus42 View Post
Isn't that the easiest way to compromise a OS? To modify tmp files and stuff?
Modifying temp files (as in say link race attacks) may still be possible with homebrewn or lesser audited applications but most have been weeded out (see 'mktemp'). Filling /tmp (as part of a resource exhaustion ploy) should be mitigated by running 'tmpwatch' regularly and configuring and mounting /tmp with "grpquota,usrquota". If you mean "modify tmp files and stuff" as in files dropped in /tmp by say a PHP-based application or setuid-root shells then those simply are collateral: not the source of the attack but a symptom. To see what I mean you have to know that in the olden days it was promoted to mount /tmp with "noexec,nodev,nosuid" but if you drop a Perl backdoor script in /tmp you "noexec" would prohibit it from executing it directly. Calling it from the web application or prefixing the interpreter you can still run it.

Compromising an OS can be done many ways depending on what's running and in what ways a cracker can get and abuse access. (More than) half of securing /tmp means preventing events from taking place by not disabling SELinux, by properly hardening the machine, regularly auditing it and reading those reports. This reply is in no way complete but I hope it gives you some food for thought (to ask more questions).
Reply With Quote
  #4  
Old 23rd October 2009, 04:24 AM
Zeitus42 Offline
Registered User
 
Join Date: Oct 2009
Posts: 53
linuxfedorafirefox
Quote:
Because it's by default set up with 1777 access rights (writable by all, except for root only owner may delete own files).
Thanks for the info.

My problem:
Ok so if I used chmod to modify "other" access to none then gave back rw access which gave me an error of /usr/libexec/gconf-sanity-check-2 exit with status 256 at boot time even after the re-modification, would that keep the 1777 access in place still? (Currently using live-cd)

Learnt the hard way...... on that one. My /tmp is symoblicly linked to a separate partition so permission modification through the live-cd is vague as it could be determined through the folder in / or the partition.

Quote:
Filling /tmp (as part of a resource exhaustion ploy) should be mitigated by running 'tmpwatch' regularly and configuring and mounting /tmp with "grpquota,usrquota".
Which file gives "quota" get configuration? Also wouldn't the enforce options be better? (gqnoenforce, uqnoenforce)
Reply With Quote
  #5  
Old 23rd October 2009, 11:05 PM
unSpawn
Guest
 
Posts: n/a
linuxopera
Quote:
Originally Posted by Zeitus42 View Post
Ok so if I used chmod to modify "other" access to none then gave back rw access which gave me an error of /usr/libexec/gconf-sanity-check-2 exit with status 256 at boot time even after the re-modification, would that keep the 1777 access in place still? (Currently using live-cd)
With a Live CD you don't usually save any modifications unless you have persistent storage (kind of defeating the purpose of using a Live CD IMO) so rebooting it removes all changes you made.


Quote:
Originally Posted by Zeitus42 View Post
Which file gives "quota" get configuration? Also wouldn't the enforce options be better? (gqnoenforce, uqnoenforce)
I don't know. Looking at the quota package contents may yield more information.
Reply With Quote
  #6  
Old 24th October 2009, 11:52 AM
Zeitus42 Offline
Registered User
 
Join Date: Oct 2009
Posts: 53
linuxfedorafirefox
Quote:
With a Live CD you don't usually save any modifications unless you have persistent storage (kind of defeating the purpose of using a Live CD IMO) so rebooting it removes all changes you made.
Huh? Using the live cd you can pretty much modify any text based configuration.
You just have to cd to the / drive.


Hmmm.........

Well I fixed the problem using chmod 1777 on both possible options, the folder and the partition, so that saved my install pretty much.

I have even modified the booleans on a live cd too.

Last edited by Zeitus42; 24th October 2009 at 12:03 PM.
Reply With Quote
  #7  
Old 24th October 2009, 12:23 PM
jpollard Online
Registered User
 
Join Date: Aug 2009
Location: Waldorf, Maryland
Posts: 6,865
linuxfedorafirefox
You can modify booleans --- but as soon as you reboot the live CD they are gone again.

One issue with /tmp (live CD) is that it is memory resident. I have even seen solaris systems
that are configured to always put /tmp in memory. This is both good and bad, the good is
that tmp always gets cleaned out on the next boot. The bad is that it becomes trivial to
cause out of memory failures.

On most multi-user systems it is much better to have /tmp be a partition that is mounted
during boot. The advantage is that it is impossible to OOM the system, second, it is
possible to put quotas on the filesystem, third, it is possible to disable setuid/setgid
programs on the mount. It is even possible to disable execute - though that can cause
problems for some strange applications - those that dynamically create/compile/execute
programs based on user configuration or direction.

The security on /tmp comes from the sticky bit (1000 - the 1 in 1777). It prevents users
from renaming or deleting files that they don't own. SELinux reinforces that with
mandatory permissions.

Using a symbolic link for /tmp is not a good idea. When the system first boots /tmp must
be available for workspace for various utilities used during the boot. It is the designated
workspace when the root is truly read only (as in CD/DVD live systems, or routers,...)
when memory is used for /tmp. Another problem with a symbolic link is that the directory
tree containing the linked to directory must at a minimum be x (executable, though in
this case x means searchable). It also bypasses the SELinux enforcement, and the
linked to directory must be 1777.
Reply With Quote
Reply

Tags
folder, or tmp, permissions

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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 On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
permissions on a folder. xptweakerntn Using Fedora 1 30th December 2006 07:33 PM
Folder Permissions byw Using Fedora 3 16th June 2005 03:27 PM
Folder Permissions? carlwill Using Fedora 2 31st March 2005 03:15 AM


Current GMT-time: 16:46 (Tuesday, 21-10-2014)

TopSubscribe to XML RSS for all Threads in all ForumsFedoraForumDotOrg Archive
logo

All trademarks, and forum posts in this site are property of their respective owner(s).
FedoraForum.org is privately owned and is not directly sponsored by the Fedora Project or Red Hat, Inc.

Privacy Policy | Term of Use | Posting Guidelines | Archive | Contact Us | Founding Members

Powered by vBulletin® Copyright ©2000 - 2012, vBulletin Solutions, Inc.

FedoraForum is Powered by RedHat
Wunstorf Travel Photos on Instagram - Lalmanirhat Photos on Instagram - Heilbronn Photos