headers
Jeremy C. Reed | 1 Nov 2003 02:11

tmp issues: trap before making safe tmp and not defining directory

This isn't NetBSD specific (but does involve software in pkgsrc).

I have some questions I'd like comments on.

I have seen many scripts that set up tmp files with a trap before. This
sets up a trap to delete the directory before the directory is even
created. In a very rare condition, if signal 1 2 3 7 13 or 15 hits it then
the directory will be removed before even checked.

For example (not my code):

  cleanup()
  {
    rc=$?
    $needsCleanup && test -n "$tmpdir" && test -d "$tmpdir" \
      && { rm -f "$tmpdir"/*; cd /; rmdir "$tmpdir"; }
    exit $rc
  }
  setupTmpDir()
  {
    $needsCleanup && return

    trap 'cleanup' 1 2 3 7 13 15
    needsCleanup=true

*** what if signal hits here, so trap does cleanup on tmpdir which was
symlinked to your important files ***

    (umask 077; mkdir "$tmpdir") \
      || abort "could not create directory \`$tmpdir'"
(Continue reading)

Permalink | Reply | 1 comment |
headers
Curt Sampson | 1 Nov 2003 10:00
Gravatar

Re: tmp issues: trap before making safe tmp and not defining directory

On Fri, 31 Oct 2003, Jeremy C. Reed wrote:

> This isn't NetBSD specific (but does involve software in pkgsrc).

Maybe we need a "safe script functions" package that would contain
functions to do this stuff properly, and just write scripts and patch
packages to use that. In fact, it might even be worth making it part of
the OS distribution.

Doing stuff securely is often hard, and if we're constantly
re-implementing these sorts of things, we're pretty much guaranteed to
get it wrong some of the time.

cjs
--

-- 
Curt Sampson  <cjs <at> cynic.net>   +81 90 7737 2974   http://www.NetBSD.org
    Don't you know, in this new Dark Age, we're all light.  --XTC
Permalink | Reply | 0 comments |
headers
Hubert Feyrer | 2 Nov 2003 21:06
Picon

Re: interfacing with cisco vpn

On Thu, 30 Oct 2003, Hubert Feyrer wrote:
> I've read your post to tech-security at
> http://news.gw.com/netbsd.tech.security/2509. Being absolute
> IPsec-clueless, I wonder if you can help me and give me a idiot-proof way
> to set things up to connect to a Cisco VPN concentrator from NetBSD?
> I'm willing to to document this on the NetBSD web pages then.

Following upto myself, I found this:
http://www.unix-ag.uni-kl.de/~massar/vpnc/

I haven't played with it yet, but if it works i'll dump it into pkgsrc
(after that freeze is over... doh)

 - Hubert

--

-- 
  ___ _ _  _   _        * Harddisk Image Cloning *
 / __| | || | | |           www.feyrer.de/g4u/
| (_ |_  _| |_| |
 \___| |_| \___/          v1.12 out now, including partition support!
Permalink | Reply | 1 comment |
headers
Hubert Feyrer | 7 Nov 2003 10:55
Picon

Re: interfacing with cisco vpn

On Sun, 2 Nov 2003, Hubert Feyrer wrote:
> Following upto myself, I found this:
> http://www.unix-ag.uni-kl.de/~massar/vpnc/
>
> I haven't played with it yet, but if it works i'll dump it into pkgsrc
> (after that freeze is over... doh)

I've played with vpnc now, and it works fine. I've written some "german
language, sorry) documentation if anyone cares:

	http://www.feyrer.de/NetBSD/netbsd-vpn-howto.html

 - Hubert

--

-- 
  ___ _ _  _   _        * Harddisk Image Cloning *
 / __| | || | | |           www.feyrer.de/g4u/
| (_ |_  _| |_| |
 \___| |_| \___/          v1.12 out now, including partition support!
Permalink | Reply | 0 comments |
headers
Steve Bellovin | 7 Nov 2003 17:44
Picon

attempt to plant a back door in the Linux kernel

http://www.securityfocus.com/news/7388

		--Steve Bellovin, http://www.research.att.com/~smb
Permalink | Reply | 8 comments |
headers
David Maxwell | 7 Nov 2003 19:28

Re: attempt to plant a back door in the Linux kernel

On Fri, Nov 07, 2003 at 11:44:31AM -0500, Steve Bellovin wrote:
> http://www.securityfocus.com/news/7388

Every note about this that I'd seen up until now had not mentioned
anything about how the server was compromised.

	"by Thursday an investigation into how the development site was
	compromised was underway, headed by Linux chief Linus Torvalds,
	according to McVoy. "

Too often, in the open source world, people fail to understand the
importance of transparency. When something goes wrong like this, there
needs to be an announcement of any results this investigation can
conclude.

Failure to discuss the hack should cause people to ask "How do we know
it hasn't happened more often, or why it won't happen again?"

--

-- 
David Maxwell, david <at> vex.net|david <at> maxwell.net --> Unless you have a solution
when you tell them things like that, most people collapse into a gibbering, 
unthinking mass.  This is the same reason why you probably don't tell your 
boss about everything you read on BugTraq!    - Signal 11
Permalink | Reply | 7 comments |
headers
Steven M. Bellovin | 7 Nov 2003 19:41
Picon

Re: attempt to plant a back door in the Linux kernel

In message <20031107182855.GE9816 <at> mail>, David Maxwell writes:
>On Fri, Nov 07, 2003 at 11:44:31AM -0500, Steve Bellovin wrote:
>> http://www.securityfocus.com/news/7388
>
>Every note about this that I'd seen up until now had not mentioned
>anything about how the server was compromised.
>
>	"by Thursday an investigation into how the development site was
>	compromised was underway, headed by Linux chief Linus Torvalds,
>	according to McVoy. "
>
>Too often, in the open source world, people fail to understand the
>importance of transparency. When something goes wrong like this, there
>needs to be an announcement of any results this investigation can
>conclude.
>
>Failure to discuss the hack should cause people to ask "How do we know
>it hasn't happened more often, or why it won't happen again?"
>

The MSNBC story ( http://www.msnbc.com/news/990343.asp?0si=- )
noted that there was a security problem in CVS.

		--Steve Bellovin, http://www.research.att.com/~smb
Permalink | Reply | 6 comments |
headers
Thor Lancelot Simon | 8 Nov 2003 07:46

Re: disklabel(8) and machdep on-disk structures issues

On Sat, Nov 08, 2003 at 04:11:20PM +1100, Luke Mewburn wrote:
> I still think we should change DIOCWDINFO to write the raw label,
> even if there is no raw label.  Currently DIOCWDINFO will fail
> if the raw label doesn't exist.  (See disklabel(5)).
> 
> Each port can then ensure that it updates its NetBSD disklabel, and
> if necessary update the "vendor"/"PROM" label (e.g, on Sun boxes).
> 
> disklabel(8) would have all "write to the actual sectors of the raw label"
> support removed.
> (For that matter, it should have the '-B' (bootblock) stuff removed as well.)
> 
> This all should be ok if the securelevel is enforced appropriately
> by DIOCWDINFO.

I agree -- I like encapsulating this code in one place, and only one place;
and we can then prohibit user writes of the disklabel sectors all the time,
no matter what, which also gives me a warm fuzzy feeling (and will make it
easier to validate that each port's disksubr.c DTRT).

--

-- 
 Thor Lancelot Simon	                                      tls <at> rek.tjls.com
   But as he knew no bad language, he had called him all the names of common
 objects that he could think of, and had screamed: "You lamp!  You towel!  You
 plate!" and so on.              --Sigmund Freud
Permalink | Reply | 0 comments |
headers
der Mouse | 8 Nov 2003 07:53
Picon

Re: disklabel(8) and machdep on-disk structures issues

>> I still think we should change DIOCWDINFO to write the raw label,
>> even if there is no raw label.  [...]
> I agree -- I like encapsulating this code in one place, and only one
> place; and we can then prohibit user writes of the disklabel sectors
> all the time, no matter what,

I would find this last significantly annoying if it were to ever make
it into any version I use; I regularly clone whole disks with (the
moral equivalent of) dd if=/dev/rsd0c of=/dev/rsd1c.  Forcing
special-casing of the label sectors would be a right pain in the butt.

"Significantly annoying" as in a private patch to dike the code out
would instantly go into my private patches.  (Arguably making it a
sysctl would be a better reaction, but I'm disinclined to put effort
into a better implementation of something I think is a bad idea to
start with.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse <at> rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
Permalink | Reply | 0 comments |
headers
Thor Lancelot Simon | 8 Nov 2003 08:04

Re: disklabel(8) and machdep on-disk structures issues

On Sat, Nov 08, 2003 at 01:53:09AM -0500, der Mouse wrote:
> >> I still think we should change DIOCWDINFO to write the raw label,
> >> even if there is no raw label.  [...]
> > I agree -- I like encapsulating this code in one place, and only one
> > place; and we can then prohibit user writes of the disklabel sectors
> > all the time, no matter what,
> 
> I would find this last significantly annoying if it were to ever make
> it into any version I use; I regularly clone whole disks with (the

It's already there, and has been for years.  See the discussion of 
securelevel in the init manual page.
Permalink | Reply | 0 comments |

Gmane