Bug 80907 - tmpmfs default change
Summary: tmpmfs default change
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: Yar Tikhiy
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-11 18:40 UTC by Caitlen
Modified: 2007-07-12 21:00 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Caitlen 2005-05-11 18:40:02 UTC
by default
tmpmfs_flags="-S"
When in reality
 tmpmfs_flags="-S -o nosymfollow,nosuid"

would be much safer

Fix: 

tmpmfs_flags="-S -o nosymfollow,nosuid"
Comment 1 Giorgos Keramidas freebsd_committer freebsd_triage 2005-05-12 13:59:12 UTC
On 2005-05-11 17:38, Caitlen <aeonflux@aeonflux.no-ip.com> wrote:
> by default
> tmpmfs_flags="-S"
> When in reality
> tmpmfs_flags="-S -o nosymfollow,nosuid"
>
> would be much safer

I don't think this is really a bug, but anyway.  It would probably be
safer to use:

	tmpmfs_flags="-S -o noatime,noexec,nosuid,nosymfollow"

The ability to actually *use* whatever options are best for your system
is exactly why I made the original change to rc.d/tmp, but I'm not sure
if it would be good to enforce so strict permissions to everyone :-/
Comment 2 Caitlen 2005-05-12 18:03:28 UTC
On May 12, 2005 09:59 am, Giorgos Keramidas wrote:
> On 2005-05-11 17:38, Caitlen <aeonflux@aeonflux.no-ip.com> wrote:
> > by default
> > tmpmfs_flags="-S"
> > When in reality
> > tmpmfs_flags="-S -o nosymfollow,nosuid"
> >
> > would be much safer
>
> I don't think this is really a bug, but anyway.  It would probably be
> safer to use:
>
> 	tmpmfs_flags="-S -o noatime,noexec,nosuid,nosymfollow"
>
> The ability to actually *use* whatever options are best for your system
> is exactly why I made the original change to rc.d/tmp, but I'm not sure
> if it would be good to enforce so strict permissions to everyone :-/
Good point, but I do think a nosymfollow is a good default.  There's really no 
reason to allow /tmp symlink race conditions to happen.  SInce it's a memory 
fs, disabling atime doesn't really make a big difference.

Anyways just a suggestion, I'll be definitely setting nosymfollow on my 
machine here.
Comment 3 Giorgos Keramidas freebsd_committer freebsd_triage 2005-05-13 12:55:59 UTC
On 2005-05-12 17:10, aeonflux <aeonflux@aeonflux.no-ip.com> wrote:
>On May 12, 2005 09:59 am, Giorgos Keramidas wrote:
>> On 2005-05-11 17:38, Caitlen <aeonflux@aeonflux.no-ip.com> wrote:
>> > by default
>> > tmpmfs_flags="-S"
>> > When in reality
>> > tmpmfs_flags="-S -o nosymfollow,nosuid"
>> >
>> > would be much safer
>>
>> I don't think this is really a bug, but anyway.  It would probably be
>> safer to use:
>>
>> 	tmpmfs_flags="-S -o noatime,noexec,nosuid,nosymfollow"
>>
>> The ability to actually *use* whatever options are best for your system
>> is exactly why I made the original change to rc.d/tmp, but I'm not sure
>> if it would be good to enforce so strict permissions to everyone :-/
>
> Good point, but I do think a nosymfollow is a good default.  There's really no
> reason to allow /tmp symlink race conditions to happen.  SInce it's a memory
> fs, disabling atime doesn't really make a big difference.
>
> Anyways just a suggestion, I'll be definitely setting nosymfollow on my
> machine here.

I'm a bit worried about giving a false sense of "secure default setup",
by having /tmp mounted as "nosymfollow".  Users who are determined to
attempt symlink race hacks may also set TMPDIR=/var/tmp or even
TMPDIR=/home/smartass/tmp and try their luck there.

Mounting both /tmp and /var as nosymfollow runs the risk of crippling
everyone's use of the file systems without actually being a 100%
bulletproof solution.

- Giorgos
Comment 4 Yar Tikhiy freebsd_committer freebsd_triage 2007-03-04 07:19:13 UTC
State Changed
From-To: open->feedback

The conclusion of the discussion was that changing tmpmfs 
defaults doesn't buy much security, but will break existing 
setups.  This would violate POLA.  Therefore I suggest this 
PR be closed. 


Comment 5 Yar Tikhiy freebsd_committer freebsd_triage 2007-03-04 07:19:13 UTC
Responsible Changed
From-To: freebsd-bugs->yar

Taking this...
Comment 6 Yar Tikhiy freebsd_committer freebsd_triage 2007-07-12 20:58:30 UTC
State Changed
From-To: feedback->closed

The conclusion of the discussion was that changing tmpmfs 
defaults doesn't buy much security, but will break existing 
setups.  That would violate POLA.  Therefore this PR is being 
closed.