[9fans] grap retarded??

[9fans] grap retarded??

[Pietro Gagliardi]

Hello.

I am writing a simple awk script powered by a shell script. It is  
called eg, which stands for equation grapher, and it graphs  
mathematical equations like on a graphing calculator. It works  
perfectly on Mac OS X (Google "grap" and you'll find an open-source  
version).

So I decided to send it to Plan 9 for testing, since Plan 9 already  
has grap. It doesn't work. What gives?

grap was giving me this funky error message saying that its "new"  
statement was followed by a newline, and that it didn't like that.  
The documentation allows "new" to have no arguments. Huh?

Here is some sample input:
.EG
y = x
.EE
.EG
# The letters x and y must each be one word for correct scanning
x < 2 * sin( y )
.EE
.EG
polar
r = sin( t / 180 )
.EE

== begin eg ==
# eg:  equation grapher
# by pietro gagliardi
# started october 24, 2007
# completed ?
# usage: eg files...
# produces grap output, so use as so:
#    eg file | grap | pic | troff

awk '
BEGIN {
	in_it = 0
	xmin = xmax = ymin = ymax = 0
	fwid = fht = lower = upper = step = 0
	showxaxis = showyaxis = showxticks = showyticks = 0
	showxlabel = showylabel = showgrid = 0
	complex = polar = start_drawing = i = 0
	pi    = "3.14159265358979323846264338327950288"
	negpi = "-" pi
	twopi = "6.28318530717958647692528676655900576"
# The value of 2*pi was calculated with GNU bc version 1.06
# running on Mac OS X 10.4.10 on a Core 2 Duo iMac. At the time,
# my C double type did not have the precision to get a value to
# check my hand-calculated values, so I used bc instead of PG hoc.
# I do not  know how it gets such values! One day I will find a
# machine where double can hold more than 15 digits. Thanks,
# scale variable of bc!
}

# .EG - begin graph
$1  == ".EG" || ($1 == "." && $2 == "EG") {
	in_it = 1
	set_defaults()
	printf ".G1"
	for (x = 2; x <= NF; x++)
		printf " %s", $x
	printf "\n"
	next
}

# .EE - end graph
# only counts while in graph
in_it && ($1 == ".EE" || ($1 == "." && $2 == "EG")) {
	finish_it()
	printf ".G2\n"
	in_it = 0
	next
}

# not in it - print
!in_it { print; next }

# From here on in, we assume we are in it

# # stuff - comment
$1 ~ /^\#/ { next }

# . followed by whatever is copied verbatim
$1 ~ /^\./ {
	start_drawing = 1
	code[i] = "literal"
	eqn[i] = $0
	i++
	next
}

# grap <stuff> - print verbatim, without grap
$1 == "grap" {
	start_drawing = 1
	s = ""
	for (x = 2; x <= NF; x++)
		s = s " " $x
	mode[i] = "literal"
	eqn[i] = s
	i++
	next
}

# pic <stuff> - print verbatim too (also sent to grap)
$1 == "pic" {
	start_drawing = 1
	mode[i] = "literal"
	eqn[i] = $0
	i++
	next
}

# frame <height> <width> - set frame size
$1 == "frame" {
	if (start_drawing) {
		err("eg: control command cannot be used after draw")
		next
	}
	fht  = $2
	fwid = $3
	next
}

# window <xmin> <xmax> <ymin> <ymin> - set coordinates
$1 == "window" {
	if (start_drawing) {
		err("eg: control command cannot be used after draw")
		next
	}
	xmin = lower = $2
	xmax = upper = $3
	ymin = lower = $4
	ymax = upper = $5
	next
}

# step (<lower> <upper>|[-]polar) [<step>] - control drawing
$1 == "step" {
	if (start_drawing) {
		err("eg: control command cannot be used after draw")
		next
	}
	if ($2 == "polar") {
		lower = 0
		upper = twopi
		if (NF > 2)
			step = $3
		else
			step = .01
	} else if ($2 == "-polar") {
		lower = negpi
		upper = pi
		if (NF > 2)
			step = $3
		else
			step = .01
	} else {
		lower = $2
		upper = $3
		if (NF >= 4)
			step = $4
		else
			step = .01
	}
	next
}

# grid (on|off) - control grid
$1 == "grid" {
	if (start_drawing) {
		err("eg: control command cannot be used after draw")
		next
	}
	showgrid = ($2 == "on") || (NF == 1)
	next
}

# axes ([xXyYrRtT]|on|off) - control axes
$1 == "axes" {
	if (start_drawing) {
		err("eg: control command cannot be used after draw")
		next
	}
	if (($2 == "on") || (NF == 1))
		showxaxis = showyaxis = showxlabel = showylabel = showxticks =  
showyticks = 1
	else if ($2 == "off")
		showxaxis = showyaxis = showxlabel = showylabel = showxticks =  
showyticks = 0
	else {
		showxaxis = showxlabel = showxticks = ($2 ~ /[xXrR]/)
		showyaxis = showylabel = showyticks = ($2 ~ /[yYtT]/)
	}
	next
}

# ticks ([xXyYrRtT]|on|off) - control ticks
$1 == "ticks" {
	if (start_drawing) {
		err("eg: control command cannot be used after draw")
		next
	}
	if (($2 == "on") || (NF == 1))
		showxticks = showyticks = 1
	else if ($2 == "off")
		showxticks = showyticks = 0
	else {
		showxticks = ($2 ~ /[xXrR]/)
		showyticks = ($2 ~ /[yYtT]/)
	}
	next
}

# axislabel ([xXyYrRtT]|on|off) - control labels on axes
$1 == "axislabel" {
	if (start_drawing) {
		err("eg: control command cannot be used after draw")
		next
	}
	if (($2 == "on") || (NF == 1))
		showxlabel = showylabel = 1
	else if ($2 == "off")
		showxlabel = showylabel = 0
	else {
		showxlabel = ($2 ~ /[xXrRtT]/)
		showylabel = ($2 ~ /[yYrRtT]/)
	}
	next
}

# rect - set rectangular coordinates
$1 == "rect" {
	if (start_drawing) {
		err("eg: control command cannot be used after draw")
		next
	}
	polar = 0
	next
}

# polar - set polar coordinates
$1 == "polar" {
	if (start_drawing) {
		err("eg: control command cannot be used after draw")
		next
	}
	polar = 1
	next
}

# real - set real coordinates
$1 == "real" {
	if (start_drawing) {
		err("eg: control command cannot be used after draw")
		next
	}
	complex = 0
	next
}

# complex - set complex coordinates
$1 == "complex" {
	if (start_drawing) {
		err("eg: control command cannot be used after draw")
		next
	}
	complex = 1
	next
}

# [xXyYrRtT] [(=|<|<=|>|>=)] equation - draw on given axis
$1 ~ /^[xXyYrRtT]$/ {
	start_drawing = 1
	mode[i] = tolower($1)
	s = ""
	start = 2
	if ($2 ~ /^(=|<|>|<=|>=)$/)
		start = 3
	for (x = start; x <= NF; x++)
		if (polar) {
			if ($x ~ /^[rR]$/)
				s = s " rcoord"
			else if ($x ~ /^[tT]$/)
				s = s " tcoord"
			else
				s = s " " $x
		} else {
			if ($x ~ /^[xXyY]$/)
				s = s " xpos"
			else
				s = s " " $x
		}
	eqn[i] = s
	if (start == 2)
		type[i] = "="
	else
		type[i] = $2
	i++
	next
}

# empty line or line with whitespace only - ignore
NF == 0 { next }

# else error
{ err("eg: bad line: " $0) }

END {
	if (in_it)
		err("eg: unclosed graph at end of file")
}

# set_defaults:  reset environment
function set_defaults() {
	xmin = ymin = lower = -10
	xmax = ymax = upper = 10
	fwid = fht = 4
	complex = i = 0
	showxaxis = showyaxis = showxticks = showyticks = showxlabel =  
showylabel = showgrid = 1
	step = .01
}

# finish_it:  draw the graph
function finish_it() {
	printf "xmin = %s\n", xmin
	printf "xmax = %s\n", xmax
	printf "ymin = %s\n", ymin
	printf "ymax = %s\n", ymax
	printf "frame invis ht %s wid %s\n", fht, fwid
	printf "coord x xmin,xmax y ymin,ymax\n"
	if (showgrid) {
		printf "grid bot  ticks off from xmin to xmax by 1\n"
		printf "grid left ticks off from ymin to ymax by 1\n"
	}
	if (showxaxis) {
		printf "arrow solid from xmin,0 to xmax,0\n"
		printf "arrow solid from xmax,0 to xmin,0\n"
	}
	if (showyaxis) {
		printf "arrow solid from 0,ymin to 0,ymax\n"
		printf "arrow solid from 0,ymax to 0,ymin\n"
	}
	if (showxlabel) {
		xstr = "x"
		if (polar)
			xstr = "r"
		printf "\" \\fI%s\\fP\" ljust at xmax,0\n", xstr
	}
	if (showylabel) {
		ystr = "y"
		if (polar)
			ystr = "\\(*h"
		if (complex)
			ystr = ystr "i"
		printf "\"\\fI%s\\fP\"  above at 0,ymax\n", ystr
	}
	if (showxticks) {
		printf "for xticks from (xmin + 1) to (xmax - 1) by 1 do {\n"
		printf "if xticks != 0 then {\n"
		printf "line solid from xticks,0 to xticks,.25\n"
		printf "sprintf(\"%%g\", xticks) above at xticks,.25\n"
		printf "}\n"
		printf "}\n"
	}
	if (showyticks) {
		printf "for yticks from (ymin + 1) to (ymax - 1) by 1 do {\n"
		printf "if yticks != 0 then {\n"
		printf "line solid from 0,yticks to .25,yticks\n"
		printf "sprintf(\" %%g\",  yticks) ljust at .25,yticks\n"
		printf "}\n"
		printf "}\n"
	}
	for (x = 0; x < i; x++) {
		if (mode[x] == "literal")
			printf "%s\n", eqn[x]
		else {
			if (type[x] ~ /=/)
				drawmode = "solid"
			else
				drawmode = "dashed"
			printf "new\ndraw %s\n", drawmode
			printf "for xpos from %s to %s by %s do {\n", lower, upper, step
			if (!polar) {
				if (mode[x] == "y") {
					printf "next at xpos, (%s)\n", eqn[x]
					if (type[x] ~ /</)
						printf "line from (xpos, (%s)) to (xpos, ymin)\n", eqn[x]
					else if (type[x] ~ />/)
						printf "line from (xpos, (%s)) to (xpos, ymax)\n", eqn[x]
				} else
					printf "next at (%s), xpos\n", eqn[x]
			} else {
				if (mode[x] == "r")
					printf "tcoord = xpos\nrcoord = %s\n", eqn[x]
				else
					printf "rcoord = xpos\ntcoord = %s\n", eqn[x]
				printf "xpoint = rcoord * cos(tcoord)\n"
				printf "ypoint = rcoord * sin(tcoord)\n"
				printf "next at xpoint, ypoint\n"
			}
			printf "}\n"
		}
	}
}

# err:  print error
function err(s) {
	print s | "cat 1>&2"
}

' $*
== end of eg ==

I could attach it if necessary. 

Re: [9fans] grap retarded??

[geoff]

What's "The documentation" you're citing?  Both grap(1) and the grap
paper of December, 1984 by Bentley and Kernighan seem to require at
least a linedesc after the keyword "new", as does
/sys/src/cmd/grap/grap.y.

Re: [9fans] grap retarded??

[Pietro Gagliardi]

The open source version at http://www.lunabase.org/~faber/Vault/ 
software/grap/, which I use on my Mac, says otherwise, but thanks!

If I use

	new solid

do I also need

	draw solid

?

On Oct 26, 2007, at 7:17 PM, geoff@plan9.bell-labs.com wrote:

> What's "The documentation" you're citing?  Both grap(1) and the grap
> paper of December, 1984 by Bentley and Kernighan seem to require at
> least a linedesc after the keyword "new", as does
> /sys/src/cmd/grap/grap.y.
>

[9fans] detecting spam

[arisawa]

Hello,

I receive many SPAMS everyday.
Most of them are from IP based dynamic FQDN.
Therefore detecting SPAM from FQDN is effective.
Almost all mails from IP based dynamic FQDN are SPAM.
However there are few important exceptions:
we have needs to send mails to users of our smtp host from somewhere  
using DHCP.

Plan 9 smtp server supports SMTP-AUTH so that legitimate users are  
allowed to transfer their mails to other smtp server.

We can also send mails to users of our smtp host using SMTP-AUTH.
However the information(the fact the mail is authenticated) is  
discarded in delivering mails to mbox. Therefore these mails are  
confused with SPAM.

I think it is worthwhile to put a tag something like:
X-Authenticated-User: alice
following "Received: from ..."
in case that the mail is authenticated by alice.

Kenji Arisawa

Re: [9fans] detecting spam

[Pietro Gagliardi]

And you are using the standard Plan 9 mail system, I presume? I  
don't, since I don't have an internet connection to Plan 9 at the  
moment (my emails are sent via Mac OS X).

A few days with Plan 9 and I've seen other security problems not  
related to email:
1) rc: the value of $path is (. /bin). It is a classic case not to  
have . as the first directory when searching for programs - it allows  
Trojan horses to form.
2) auth server: why do we need one for passwords anyways if we run on  
a desktop computer? I don't know how to set one up, but I'd just like  
to set a password without an error spitting back at me when I type  
"passwd".

On Oct 26, 2007, at 10:51 PM, arisawa@ar.aichi-u.ac.jp wrote:

> Hello,
>
> I receive many SPAMS everyday.
> Most of them are from IP based dynamic FQDN.
> Therefore detecting SPAM from FQDN is effective.
> Almost all mails from IP based dynamic FQDN are SPAM.
> However there are few important exceptions:
> we have needs to send mails to users of our smtp host from  
> somewhere using DHCP.
>
> Plan 9 smtp server supports SMTP-AUTH so that legitimate users are  
> allowed to transfer their mails to other smtp server.
>
> We can also send mails to users of our smtp host using SMTP-AUTH.
> However the information(the fact the mail is authenticated) is  
> discarded in delivering mails to mbox. Therefore these mails are  
> confused with SPAM.
>
> I think it is worthwhile to put a tag something like:
> X-Authenticated-User: alice
> following "Received: from ..."
> in case that the mail is authenticated by alice.
>
> Kenji Arisawa
>

Re: [9fans] security

[erik quanstrom]

> 1) rc: the value of $path is (. /bin). It is a classic case not to  
> have . as the first directory when searching for programs - it allows  
> Trojan horses to form.

if you're the only one using your system, how could this be a problem?

but assuming you have multiple users on your system, how do you
propose that a target be tricked into cd'ing into a trojaned directory
and attempt to execute the magic command.  what would this trojaned
command do?  without setuid (or a superuser), the options are more
constrained.

perhaps there are systems where the mutal distrust between users is
that great.

> 2) auth server: why do we need one for passwords anyways if we run on  
> a desktop computer? I don't know how to set one up, but I'd just like  
> to set a password without an error spitting back at me when I type  
> "passwd".

this command should get you started
	man 8 authsrv

- erik

Re: [9fans] security

[roger peppe]

> > 1) rc: the value of $path is (. /bin). It is a classic case not to
> > have . as the first directory when searching for programs - it allows
> > Trojan horses to form.
>
> if you're the only one using your system, how could this be a problem?

to be fair, if i'd put a file in /n/sources/contrib/rog/ls:

#!/bin/rc
rm -rf $home &
ls $* |* | grep -v ls

then i'm sure there'd be one or two unhappy people around...

Re: [9fans] security

[arisawa]

Hello,

Removing files is not worth doing.
The victim will immediately find what happened and will recover his  
files
and then will consider what made the trouble.

I don't say (. /bin) is safe in untrusted environment.
Someone might steal my private info using some trick.

Security is tradeoff with convenience.
I guess we (member of 9fans) are happy enough working in trusted  
environment.

Kenji Arisawa

On 2007/10/27, at 18:03, roger peppe wrote:

>>> 1) rc: the value of $path is (. /bin). It is a classic case not to
>>> have . as the first directory when searching for programs - it  
>>> allows
>>> Trojan horses to form.
>>
>> if you're the only one using your system, how could this be a  
>> problem?
>
> to be fair, if i'd put a file in /n/sources/contrib/rog/ls:
>
> #!/bin/rc
> rm -rf $home &
> ls $* |* | grep -v ls
>
> then i'm sure there'd be one or two unhappy people around...

Re: [9fans] security

[Uriel]

The main reason I like to change path to (/bin .) is that when in a
remote directory (like /n/sources) having (. /bin) as path makes
running scripts *SLOW*.

And I really can't think of any reason why having . would be a good
idea, because after all if you call ls, 99.9% of the time you want
/bin/ls, and the remaining 0.1% it doesn't hurt to be explicit and run
./ls

But this has been discussed before, and 'the powers that be' didn't
agree, I only wish I could understand why, but that is probably my
fault.

uriel

On 10/27/07, arisawa@ar.aichi-u.ac.jp <arisawa@ar.aichi-u.ac.jp> wrote:
> Hello,
>
> Removing files is not worth doing.
> The victim will immediately find what happened and will recover his
> files
> and then will consider what made the trouble.
>
> I don't say (. /bin) is safe in untrusted environment.
> Someone might steal my private info using some trick.
>
> Security is tradeoff with convenience.
> I guess we (member of 9fans) are happy enough working in trusted
> environment.
>
> Kenji Arisawa
>
> On 2007/10/27, at 18:03, roger peppe wrote:
>
> >>> 1) rc: the value of $path is (. /bin). It is a classic case not to
> >>> have . as the first directory when searching for programs - it
> >>> allows
> >>> Trojan horses to form.
> >>
> >> if you're the only one using your system, how could this be a
> >> problem?
> >
> > to be fair, if i'd put a file in /n/sources/contrib/rog/ls:
> >
> > #!/bin/rc
> > rm -rf $home &
> > ls $* |* | grep -v ls
> >
> > then i'm sure there'd be one or two unhappy people around...
>
>

Re: [9fans] security

[erik quanstrom]

and one fewer account on sources.  there's a check on that
sort of behavior.

- erik

> > > 1) rc: the value of $path is (. /bin). It is a classic case not to
> > > have . as the first directory when searching for programs - it allows
> > > Trojan horses to form.
> >
> > if you're the only one using your system, how could this be a problem?
> 
> to be fair, if i'd put a file in /n/sources/contrib/rog/ls:
> 
> #!/bin/rc
> rm -rf $home &
> ls $* |* | grep -v ls
> 
> then i'm sure there'd be one or two unhappy people around...

Re: [9fans] security

[Tim Newsham]

> but assuming you have multiple users on your system, how do you
> propose that a target be tricked into cd'ing into a trojaned directory
> and attempt to execute the magic command.  what would this trojaned
> command do?  without setuid (or a superuser), the options are more
> constrained.

How about forking off a server process that lets me execute arbitrary 
commands as you?

How about placing trojan processes in your person bin directory?

How about subtly corrupting all of the writable data in your filesystem?

How about setting up a spam bot on your machine?  Using your machine as 
part of a distributed denial-of-service attack against some other 
networked machines?

How about replacing your compiler with one that introduces errors 
nondeterministically?  Changing your acme to occasionally not save your 
data?

If you sit down and think of it for a little bit you'll notice this is 
just the tip of the iceburg.  There are lots of irritating things that can 
happen even without setuid or a super user.

> - erik

Tim Newsham
http://www.thenewsh.com/~newsham/

Re: [9fans] security

[erik quanstrom]

> How about forking off a server process that lets me execute arbitrary 
> commands as you?
> 
> How about placing trojan processes in your person bin directory?
> 
> How about subtly corrupting all of the writable data in your filesystem?
> 
> How about setting up a spam bot on your machine?  Using your machine as 
> part of a distributed denial-of-service attack against some other 
> networked machines?
> 
> How about replacing your compiler with one that introduces errors 
> nondeterministically?  Changing your acme to occasionally not save your 
> data?
> 
> If you sit down and think of it for a little bit you'll notice this is 
> just the tip of the iceburg.  There are lots of irritating things that can 
> happen even without setuid or a super user.

clearly, you're not getting an account on my machine.

- erik

Re: [9fans] security

[don bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> clearly, you're not getting an account on my machine.
> 

This goes back to the typical MacOSX argument:
	"If I have MacOSX laptop and you compromise my local
	 account, it doesn't matter because you haven't
	 gotten root, right?"

Of course, this isn't true because all your data is owned
by your user credentials. If someone compromises a single
user laptop they don't need root or any other super user
semantic. Being you compromises all the information
necessary to hurt you: banking information, SSN, credit
card info, e-mail logins, locally stored files, etc...

I'd say that's enough of a problem. Even Plan 9's well
designed authentication domains don't properly mitigate
the issue of the local account being compromised.

D

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHI7mryWX0NBMJYAcRAmSjAKCWXuQeAO7mTXKlwChpRYb1BDV0eQCeJn2t
1gCP7bJWlAofxI4Ta4oZeig=
=f3q/
-----END PGP SIGNATURE-----

Re: [9fans] security

[Pietro Gagliardi]

OS X has root:

$ ls -ld /var
lrwxr-xr-x   1 root  admin  11 Aug 11  2006 /var -> private/var
$ ls -l /private
total 0
drwxr-xr-x   107 root  wheel  3638 Oct  2 21:25 etc
drwxr-xr-x     3 root  wheel   102 Aug  1  2006 tftpboot
drwxrwxrwt    22 root  wheel   748 Oct 27 18:23 tmp
drwxrwxrwt     4 root  wheel   136 Mar 12  2007 tmp 2
drwxr-xr-x    26 root  wheel   884 Oct 27 10:03 var
$ # run from Tiger

Oh and here's nice security: boot a Mac and hit Command+S while  
booting (before the Apple logo/Happy Mac) and you're root. No  
password required.

On Oct 27, 2007, at 6:20 PM, don bailey wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> clearly, you're not getting an account on my machine.
>>
>
> This goes back to the typical MacOSX argument:
> 	"If I have MacOSX laptop and you compromise my local
> 	 account, it doesn't matter because you haven't
> 	 gotten root, right?"
>
> Of course, this isn't true because all your data is owned
> by your user credentials. If someone compromises a single
> user laptop they don't need root or any other super user
> semantic. Being you compromises all the information
> necessary to hurt you: banking information, SSN, credit
> card info, e-mail logins, locally stored files, etc...
>
> I'd say that's enough of a problem. Even Plan 9's well
> designed authentication domains don't properly mitigate
> the issue of the local account being compromised.
>
> D
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHI7mryWX0NBMJYAcRAmSjAKCWXuQeAO7mTXKlwChpRYb1BDV0eQCeJn2t
> 1gCP7bJWlAofxI4Ta4oZeig=
> =f3q/
> -----END PGP SIGNATURE-----

Re: [9fans] security

[don bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> OS X has root:
> 

Yes, I understand that MacOSX has root.

Say I own a laptop and noone else uses said laptop.
Am I going to suid and store all my private files
as root or another user? No, most likely not. I'll
store all my files as myself because it's convenient.

Therefore, someone does not have to compromise root
to compromise the entire box, since the assets on
the entire box are really limited to my account.

Make sense? :-)

D


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHI7y/yWX0NBMJYAcRAk2QAJ9Sgx6pQfwGJf7JwKk516lW5NgH4wCgjwdQ
puXIgYoJOTnTZsCUaplwI8w=
=Fj1T
-----END PGP SIGNATURE-----

Re: [9fans] security

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 2289 bytes --]

On 10/27/07, Pietro Gagliardi <pietro10@mac.com> wrote:
>
> OS X has root:
>
> $ ls -ld /var
> lrwxr-xr-x   1 root  admin  11 Aug 11  2006 /var -> private/var
> $ ls -l /private
> total 0
> drwxr-xr-x   107 root  wheel  3638 Oct  2 21:25 etc
> drwxr-xr-x     3 root  wheel   102 Aug  1  2006 tftpboot
> drwxrwxrwt    22 root  wheel   748 Oct 27 18:23 tmp
> drwxrwxrwt     4 root  wheel   136 Mar 12  2007 tmp 2
> drwxr-xr-x    26 root  wheel   884 Oct 27 10:03 var
> $ # run from Tiger
>
> Oh and here's nice security: boot a Mac and hit Command+S while
> booting (before the Apple logo/Happy Mac) and you're root. No
> password required.



Yeah most operating systems have single user mode.  If you can remotely boot
my mac and hold Command-S, I'll start worrying about that one.

Find any linux box and boot with S on the kernel option line.

Solaris can have this done too.

By the way if you're that close to a mac why not boot it in target disk mode
and just read all the data off the disk with a firewire cable?

Physical access == no security pretty much.


On Oct 27, 2007, at 6:20 PM, don bailey wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >> clearly, you're not getting an account on my machine.
> >>
> >
> > This goes back to the typical MacOSX argument:
> >       "If I have MacOSX laptop and you compromise my local
> >        account, it doesn't matter because you haven't
> >        gotten root, right?"
> >
> > Of course, this isn't true because all your data is owned
> > by your user credentials. If someone compromises a single
> > user laptop they don't need root or any other super user
> > semantic. Being you compromises all the information
> > necessary to hurt you: banking information, SSN, credit
> > card info, e-mail logins, locally stored files, etc...
> >
> > I'd say that's enough of a problem. Even Plan 9's well
> > designed authentication domains don't properly mitigate
> > the issue of the local account being compromised.
> >
> > D
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (GNU/Linux)
> >
> > iD8DBQFHI7mryWX0NBMJYAcRAmSjAKCWXuQeAO7mTXKlwChpRYb1BDV0eQCeJn2t
> > 1gCP7bJWlAofxI4Ta4oZeig=
> > =f3q/
> > -----END PGP SIGNATURE-----
>
>

[-- Attachment #2: Type: text/html, Size: 3572 bytes --]

Re: [9fans] security

[Skip Tavakkolian]

> Physical access == no security pretty much.

that's exactly why we employ a dedicated guard to physically secure
our authsrv.

http://www.9netics.com/who/fst/authsrv_security.jpg

Re: [9fans] security

[john]

>> Physical access == no security pretty much.
> 
> that's exactly why we employ a dedicated guard to physically secure
> our authsrv.
> 
> http://www.9netics.com/who/fst/authsrv_security.jpg

Factotum cat does not approve of your keys.

Re: [9fans] security

[Joel C. Salomon]

On 10/28/07, Skip Tavakkolian <9nut@9netics.com> wrote:
> that's exactly why we employ a dedicated guard to physically secure
> our authsrv.
>
> http://www.9netics.com/who/fst/authsrv_security.jpg

Looking for the manual page for this access control system… cat(1) has
nothing apropos.  In-house development, perhaps?

On second thought, some genome sequencing lab has probably copyrighted
the source code anyway.

--Joel

Re: [9fans] security

[Charles Forsyth]

>I'd say that's enough of a problem. Even Plan 9's well
>designed authentication domains don't properly mitigate
>the issue of the local account being compromised.

in practice, no, not the way they are used.
most processes start with most possible things in their
name spaces, whereas if we were really worried we'd
arrange that the other way round, so that most things
had just what they needed and no more.

that much could be done by constructing name spaces,
but it still wouldn't cover various classes of resource exhaustion.

also, given that we don't do use the system that way
that often, we might not build the environments correctly the first
few times.  still there's much less to check than with some other
approaches.  i wonder how you'd prove its properties.

Re: [9fans] security

[Skip Tavakkolian]

>> How about forking off a server process that lets me execute arbitrary 
>> commands as you?
>> 
>> How about placing trojan processes in your person bin directory?
>> 
>> How about subtly corrupting all of the writable data in your filesystem?
>> 
>> How about setting up a spam bot on your machine?  Using your machine as 
>> part of a distributed denial-of-service attack against some other 
>> networked machines?
>> 
>> How about replacing your compiler with one that introduces errors 
>> nondeterministically?  Changing your acme to occasionally not save your 
>> data?
>> 
>> If you sit down and think of it for a little bit you'll notice this is 
>> just the tip of the iceburg.  There are lots of irritating things that can 
>> happen even without setuid or a super user.

you are stating truisms.  you might as well add "how about poisoning
your friends that you invited for dinner." at that point you're
betraying an implicit trust.

if you don't trust your users, you can create a temporary namespace to
house a copy of system binaries and narrow the / for that user to
his/her ns.

Re: [9fans] security

[don bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> you are stating truisms.  you might as well add "how about poisoning
> your friends that you invited for dinner." at that point you're
> betraying an implicit trust.
> 

"Implicit trust" is a ridiculous thing to allow in a computer network
or host.

> if you don't trust your users, you can create a temporary namespace to
> house a copy of system binaries and narrow the / for that user to
> his/her ns.
>

So you're never going to 9fs a remote system and cd
/n/somebox/some/path? :-)

D


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHJCgAyWX0NBMJYAcRAtH9AKCdP1rXP4yX8zaCD+2bn8v8xkOUWgCeOWkg
r1djDagfEhS31Kpf/vBlqqw=
=Jl3q
-----END PGP SIGNATURE-----

Re: [9fans] security

[Skip Tavakkolian]

>> you are stating truisms.  you might as well add "how about poisoning
>> your friends that you invited for dinner." at that point you're
>> betraying an implicit trust.
>> 
> 
> "Implicit trust" is a ridiculous thing to allow in a computer network
> or host.
> 
>> if you don't trust your users, you can create a temporary namespace to
>> house a copy of system binaries and narrow the / for that user to
>> his/her ns.
>>
> 
> So you're never going to 9fs a remote system and cd
> /n/somebox/some/path? :-)

your comments seem contradictory to me.  on the one hand you imply
that there is trust - presumably to collaborate, hence the reason
you'd want to import a foreign fs and be allowed to do so by the foreign
fs owner to start - and then you say trust is ridiculous.

Re: [9fans] security

[don bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> your comments seem contradictory to me.  on the one hand you imply
> that there is trust - presumably to collaborate, hence the reason
> you'd want to import a foreign fs and be allowed to do so by the foreign
> fs owner to start - and then you say trust is ridiculous.
> 

There's nothing wrong with importing a remote file system. And
you're assuming that you actually need credentials to mount the
remote file system. It is ridiculous to implicitly trust, yes.
The mitigation of the threat (in this case) is to disallow "."
from your path. If you want to go deeper you can discuss auditing
your kernel and the relevant user land source code.

So there is a balance between the unknown and the known and
that balance is what security is all about. You isolate the
problems you can as best you can. Implicitly trusting is just
as dangerous as not trusting anything.

D

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHJC9syWX0NBMJYAcRAqyKAKCm9gId4hO1oKYMV3Ke6EpTqeNxCQCgvGRl
HXFzFwvt1R7CDX1AjUjzxIg=
=WOs0
-----END PGP SIGNATURE-----

Re: [9fans] security

[Skip Tavakkolian]

> There's nothing wrong with importing a remote file system. And
> you're assuming that you actually need credentials to mount the
> remote file system. It is ridiculous to implicitly trust, yes.
> The mitigation of the threat (in this case) is to disallow "."
> from your path. If you want to go deeper you can discuss auditing
> your kernel and the relevant user land source code.

in that case, one should build a sandbox, climb into it and import the
fs.  the potential damage is contained.  maybe 9fs should have an
option to do that.

> So there is a balance between the unknown and the known and
> that balance is what security is all about. You isolate the
> problems you can as best you can. Implicitly trusting is just
> as dangerous as not trusting anything.

i didn't say implicitly trust everything, but if you decided to be
part of a group, you're implicitly trusting them.  it would be as
if you asked every coworker to walk through a metal detector
before they could approach you. if you don't, then you're implicitly
trusting they wont harm you.

Re: [9fans] security

[Pietro Gagliardi]

user nobody

On Oct 28, 2007, at 3:28 AM, Skip Tavakkolian wrote:

>> There's nothing wrong with importing a remote file system. And
>> you're assuming that you actually need credentials to mount the
>> remote file system. It is ridiculous to implicitly trust, yes.
>> The mitigation of the threat (in this case) is to disallow "."
>> from your path. If you want to go deeper you can discuss auditing
>> your kernel and the relevant user land source code.
>
> in that case, one should build a sandbox, climb into it and import the
> fs.  the potential damage is contained.  maybe 9fs should have an
> option to do that.
>
>> So there is a balance between the unknown and the known and
>> that balance is what security is all about. You isolate the
>> problems you can as best you can. Implicitly trusting is just
>> as dangerous as not trusting anything.
>
> i didn't say implicitly trust everything, but if you decided to be
> part of a group, you're implicitly trusting them.  it would be as
> if you asked every coworker to walk through a metal detector
> before they could approach you. if you don't, then you're implicitly
> trusting they wont harm you.
>

Re: [9fans] security

[don bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pietro Gagliardi wrote:
> user nobody
> 

Loss of functionality.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHJLA4yWX0NBMJYAcRAimmAJsFWSJFsKJTOWPLxUoQQ3wnMxIaiACfWztZ
J5WyG7zuudAYys2YthwOb6k=
=bSoy
-----END PGP SIGNATURE-----

Re: [9fans] security

[don bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> in that case, one should build a sandbox, climb into it and import the
> fs.  the potential damage is contained.  maybe 9fs should have an
> option to do that.
> 

What if the trojan broke out of that sandbox? Or knows how to
import other parts of the namespace into its process? Namespaces
on Plan 9 are nice, but they absolutely do not constitute a safe
sandbox. Boo easy answers.

> i didn't say implicitly trust everything, but if you decided to be
> part of a group, you're implicitly trusting them.  it would be as
> if you asked every coworker to walk through a metal detector
> before they could approach you. if you don't, then you're implicitly
> trusting they wont harm you.
> 

Making a parallel between your workplace environment and a network
security environment is a dangerous thing. Have you ever seen a
little green blob with one eye stuck to the top of your coworker's
head, controlling your coworker's thoughts and actions? Get back
to me when you do :-)

D


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHJLAFyWX0NBMJYAcRAh/yAKCtO43h0CDQNNIgHa61cScvZsyrtQCghkeH
YWX7Av8QNVBExdlX5JK8voY=
=lkC4
-----END PGP SIGNATURE-----

Re: [9fans] security

[Iruata Souza]

On 10/28/07, don bailey <don.bailey@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > in that case, one should build a sandbox, climb into it and import the
> > fs.  the potential damage is contained.  maybe 9fs should have an
> > option to do that.
> >
>
> What if the trojan broke out of that sandbox? Or knows how to
> import other parts of the namespace into its process? Namespaces
> on Plan 9 are nice, but they absolutely do not constitute a safe
> sandbox. Boo easy answers.
>

ok, so can I suppose you know how to do that? if so, do you have a
better idea for sandboxing? if not, maybe it should be good for you to
think in terms of what you or someone else already got working instead
of saying every little thing that comes on your mind.
for example, could you argument (preferably with source code) why
namespaces aren't safe sandboxing? if it is that easy as you say it
is, I guess you already got ways of bypassing it.

iru

Re: [9fans] security

[don bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> ok, so can I suppose you know how to do that? if so, do you have a
> better idea for sandboxing? if not, maybe it should be good for you to
> think in terms of what you or someone else already got working instead
> of saying every little thing that comes on your mind.
>

Sigh. Thanks for assuming I'm just making random comments.

I guess my last exploit didn't teach anyone anything.
"OHMYGODZ A KERNEL 0DAY FOR PLAN 9??!?!!?!"

You can't segment the Plan 9 kernel. You can only make it
harder to use.

As I stated in my last e-mail, apparently noone here is
interested in listening, so I'm done trying to prove a
point for now. Next time it'll come in binary form.

Cheers,
D



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHJLkPyWX0NBMJYAcRAkTnAJ9h7uaml9QPfmRBHD5qw8TJ6bbRXgCfWRH5
Q7f1kGhBrb+FaLWC8yGXfjE=
=2BYc
-----END PGP SIGNATURE-----

Re: [9fans] security

[Iruata Souza]

On 10/28/07, don bailey <don.bailey@gmail.com> wrote:
> Sigh. Thanks for assuming I'm just making random comments.
>

you haven't showed much proof in this thread, so I assumed that.

> I guess my last exploit didn't teach anyone anything.
> "OHMYGODZ A KERNEL 0DAY FOR PLAN 9??!?!!?!"
>
I saw your exploit when it was mentioned. The bug was fixed, doesn't it?

> You can't segment the Plan 9 kernel. You can only make it
> harder to use.
>
> As I stated in my last e-mail, apparently noone here is
> interested in listening, so I'm done trying to prove a
> point for now.
>
I don't know if people are interested in listening... but if you want
people to listen I guess you better try to use better arguments (maybe
exploiting, as you already did, is a good one).

> Next time it'll come in binary form.
that is the kind of thing that makes people stop treating you seriously.

> Cheers,
> D
>

in the end, writing the exploit seemed a good approach. you showed it,
people discussed, the thing was fixed.

best,
iru

Re: [9fans] security

[Gabriel Diaz]

hello

I think having someone thinking the way Don and Tim do could help in
general (actually it already helped isn't it?)

If from those thoughts a bug or security hole is fixed, great, may be
those thoughts sounds too paranoid, but i can't see why that's bad.

Of course that do not means everybody should think the same way, I
suppose Erik's point was to relax that paranoid, and return to the
path issue :-?

Change the path default value to (bin .)  looks like a painless change
(improvement :-?) and it will not broke anything, isn't it?

Discussing security on 9fans is funnier when related to plan9 more
directly than when trying to address "unsolvable" problems like the
user education :-)

slds.

gabi




On 10/28/07, don bailey <don.bailey@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > ok, so can I suppose you know how to do that? if so, do you have a
> > better idea for sandboxing? if not, maybe it should be good for you to
> > think in terms of what you or someone else already got working instead
> > of saying every little thing that comes on your mind.
> >
>
> Sigh. Thanks for assuming I'm just making random comments.
>
> I guess my last exploit didn't teach anyone anything.
> "OHMYGODZ A KERNEL 0DAY FOR PLAN 9??!?!!?!"
>
> You can't segment the Plan 9 kernel. You can only make it
> harder to use.
>
> As I stated in my last e-mail, apparently noone here is
> interested in listening, so I'm done trying to prove a
> point for now. Next time it'll come in binary form.
>
> Cheers,
> D
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHJLkPyWX0NBMJYAcRAkTnAJ9h7uaml9QPfmRBHD5qw8TJ6bbRXgCfWRH5
> Q7f1kGhBrb+FaLWC8yGXfjE=
> =2BYc
> -----END PGP SIGNATURE-----
>

Re: [9fans] security

[Pietro Gagliardi]

Read everything before you reply.

On Oct 28, 2007, at 1:22 PM, Gabriel Diaz wrote:

> hello
>
> I think having someone thinking the way Don and Tim do could help in
> general (actually it already helped isn't it?)
>
> If from those thoughts a bug or security hole is fixed, great, may be
> those thoughts sounds too paranoid, but i can't see why that's bad.
>
> Of course that do not means everybody should think the same way, I
> suppose Erik's point was to relax that paranoid, and return to the
> path issue :-?

Maybe Pike should write "On the Security of Plan 9" like Ritchie did  
with UNIX; maybe then everyone will stop being paranoid. I don't run  
a server, so I don't usually worry about this stuff :-)

>
> Change the path default value to (bin .)  looks like a painless change
> (improvement :-?) and it will not broke anything, isn't it?
>

And it's painless - anyone can do it; it's something with either /usr/ 
$user/lib/profile or rc.

> Discussing security on 9fans is funnier when related to plan9 more
> directly than when trying to address "unsolvable" problems like the
> user education :-)
>
> slds.
>
> gabi
>
>
>
>
> On 10/28/07, don bailey <don.bailey@gmail.com> wrote:
>>> ok, so can I suppose you know how to do that? if so, do you have a
>>> better idea for sandboxing? if not, maybe it should be good for  
>>> you to
>>> think in terms of what you or someone else already got working  
>>> instead
>>> of saying every little thing that comes on your mind.
>>>
>>
>> Sigh. Thanks for assuming I'm just making random comments.
>>
>> I guess my last exploit didn't teach anyone anything.
>> "OHMYGODZ A KERNEL 0DAY FOR PLAN 9??!?!!?!"
>>
>> You can't segment the Plan 9 kernel. You can only make it
>> harder to use.

I don't know what his last exploit was (I'm new here) but obviously  
he's speaking with a point.

>>
>> As I stated in my last e-mail, apparently noone here is
>> interested in listening, so I'm done trying to prove a
>> point for now. Next time it'll come in binary form.
>>

That's because no one outside the Windows world wants to acknowledge  
security. Apple's various ads could be considered naive as well.

>> Cheers,
>> D




On Oct 28, 2007, at 11:52 AM, don bailey wrote:
>
> Pietro Gagliardi wrote:
>> user nobody
>>
>
> Loss of functionality.
>

OK, I'm probably thinking of another system. What I meant was the  
group noworld, which programs like ftpfs use. Why not also the system?



On Oct 28, 2007, at 11:59 AM, Iruata Souza wrote:
> for example, could you argument (preferably with source code) why
> namespaces aren't safe sandboxing? if it is that easy as you say it
> is, I guess you already got ways of bypassing it.
>
> iru

Let's focus on that. That's a good question. Instead of reprimanding  
him on the statement before it, why not see if his question is possible?

I don't understand namespaces - I didn't understand it in XML and I  
don't understand them here. I don't know if I will. :-) I can't solve  
that problem, then. The most I know how to do with Plan 9 is  
programming graphics.



On Oct 28, 2007, at 2:11 AM, don bailey wrote:
>
>> you are stating truisms.  you might as well add "how about poisoning
>> your friends that you invited for dinner." at that point you're
>> betraying an implicit trust.
>>
>
> "Implicit trust" is a ridiculous thing to allow in a computer network
> or host.

Unfortunately, it happens every day. That's why they have/had root  
and user activity logging.

> So you're never going to 9fs a remote system and cd
> /n/somebox/some/path? :-)
>
> D
>
>

Same thing. How do you get third-party programs like i/mothra?



On Oct 27, 2007, at 1:19 PM, Tim Newsham wrote:
>> but assuming you have multiple users on your system, how do you
>> propose that a target be tricked into cd'ing into a trojaned  
>> directory
>> and attempt to execute the magic command.  what would this trojaned
>> command do?  without setuid (or a superuser), the options are more
>> constrained.
>
> How about forking off a server process that lets me execute  
> arbitrary commands as you?

Is that even possible?

>
> How about placing trojan processes in your person bin directory?
>

That's my point on path=(. /bin)

> How about subtly corrupting all of the writable data in your  
> filesystem?
>

Nice one. Especially since users have write access to most of the  
sublevels of /sys (how do you add fonts or macro sets to troff?  
change source code? improve documentation? add man pages?).

> How about setting up a spam bot on your machine?  Using your  
> machine as part of a distributed denial-of-service attack against  
> some other networked machines?

Especially since SMTP is not in Plan 9 at the moment, that is  
unlikely. But we should get ready.

>
> How about replacing your compiler with one that introduces errors  
> nondeterministically?  Changing your acme to occasionally not save  
> your data?
>

Easy source code change that could go unnoticed.

> If you sit down and think of it for a little bit you'll notice this  
> is just the tip of the iceburg.  There are lots of irritating  
> things that can happen even without setuid or a super user.
>
>> - erik
>
> Tim Newsham
> http://www.thenewsh.com/~newsham/

Good point. Let's look at all of the above as well.

IN CONCLUSION
I'm not reprimanding anyone. I'm saying we should reevaluate our  
stance on this and try to improve security instead of arguing about it.

Re: [9fans] security

[Charles Forsyth]

>Or knows how to
> import other parts of the namespace into its process?

that can itself only be done through the name space,
so the program can only do that if the means are provided in the name space
it was given.  the existence of `name spaces' by itself does nothing
for security (which is one reason adding them to linux does nothing very
much that way), but because in plan 9 most (but not all) system services
are ultimately accessed and controlled using names in a name space,
controlling the name space goes a long way to avoiding having to
deal with each thing separately (let alone having to worry about combinations of them).

name spaces don't stop all irregular behaviour (rfork would need
to be controlled, for instance if you were to run arbitrary programs),
but it's possible to make statements about what a program can or cannot
do based on what it's given in its name space.

Re: [9fans] security

[erik quanstrom]

>> in that case, one should build a sandbox, climb into it and import the
>> fs.  the potential damage is contained.  maybe 9fs should have an
>> option to do that.
>> 
> 
> What if the trojan broke out of that sandbox? Or knows how to
> import other parts of the namespace into its process? Namespaces
> on Plan 9 are nice, but they absolutely do not constitute a safe
> sandbox. Boo easy answers.

deadhorse.

i'll risk repeating skip because you seem to have missed his point.

	sharing REQUIRES trust!

if you use plan 9, linux, windows, osx, vms or whatever you
trust that the authors haven't trojaned the os.  if you use a 
pc, a mac, a vax 11/780, an ipaq or whatever, you trust that
the hardware guys don't have something in there working
against your interest.  (if you've seen what intel's put in their
"desktop" proe/1000 chips lately, ironicly in the name of
security, you'd have an inkling of how this might happen.)
you trust your network provider not to send 20KV down the
wire, etc.

i don't think anyone here advocates sharing needles.
on the other hand, wearing a full-body condom to sleep
by oneself is a bit silly.

but suppose you do.  then watch out for the junkies.  they might just
poke you in the butt right through that full-body condom.

- erik

Re: [9fans] security

[don bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> deadhorse.
> 
> i'll risk repeating skip because you seem to have missed his point.
> 
> 	sharing REQUIRES trust!
> 

Thanks for all the sarcasm and condescending remarks.
Obviously you guys aren't interested in learning anything.
Have fun playing with an OS you don't understand.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHJLhPyWX0NBMJYAcRAgpnAJ90OHEBimEEaWzvn4tw9qoBDAJeZgCcDQuZ
mQeyLBvB+J7JVG43Y9ihpbA=
=HEbe
-----END PGP SIGNATURE-----

Re: [9fans] security

[Skip Tavakkolian]

> What if the trojan broke out of that sandbox? Or knows how to
> import other parts of the namespace into its process? Namespaces
> on Plan 9 are nice, but they absolutely do not constitute a safe
> sandbox. Boo easy answers.

i know that you know about RFNOMNT; but sure there could be a kernel
bug or more likely a bug in the sanxbox code.  that would be a flaw,
not a malicious trojan horse put in - presumably by the author of the
sandbox?! - for that purpose.  any scheme has its holes which are
usually exposed by random events.

what's the cost of security and what's the worth of the data?  i have
decided that my data security doesn't have to be the best, just better
than what the smartest cracker can crack.  if, for example, the nsa or
the cia is interested in my data then i have to assume they already
have it.

> Making a parallel between your workplace environment and a network
> security environment is a dangerous thing. Have you ever seen a
> little green blob with one eye stuck to the top of your coworker's
> head, controlling your coworker's thoughts and actions? Get back
> to me when you do :-)

do you really know the mental state of each of your coworkers at all
time?  it doesn't have to be a green blob.  it's called life.  even at
the cia where one would assume they have the means and the need to
monitor every employee, there have been many cases of analysts
becoming spies for foreign powers for a variety of personal reasons.
that's data security too.

if you don't grow all your own food or if you've ever eaten at a
restaurant, you're an implicitly trusting person.

you'll just have to trust us :)

Re: [9fans] security

[Uriel]

On 10/28/07, Skip Tavakkolian <9nut@9netics.com> wrote:
> > What if the trojan broke out of that sandbox? Or knows how to
> > import other parts of the namespace into its process? Namespaces
> > on Plan 9 are nice, but they absolutely do not constitute a safe
> > sandbox. Boo easy answers.
>
> i know that you know about RFNOMNT; but sure there could be a kernel
> bug or more likely a bug in the sanxbox code.  that would be a flaw,
> not a malicious trojan horse put in - presumably by the author of the
> sandbox?! - for that purpose.  any scheme has its holes which are
> usually exposed by random events.
>
> what's the cost of security and what's the worth of the data?

I'm still wondering what is the cost of having path be (/bin .) (other
than running scripts actually becoming much faster when access to . is
slow).

For once I'm with don, just because perfect security is impossible
doesn't mean we should stop trying to get closer to it, specially when
the cost (as far as anyone has been able to tell in this case) is
negligible.

What is next? we get rid of file permissions 'because your coworkers
can already pick the pile of papers lying on your desk so you should
trust them anyway.

Seeing this kinds of arguments is quite sad, specially given how far
ahead plan9 is from every other system when it comes to *real*
*practical* security.

And I'm an idiot, but this whole discussion has become quite stupid.

uriel

Re: [9fans] security

[Iruata Souza]

just for the notice, I agree with don. I was just discussing his
methods of exposing his arguments.

iru

Re: [9fans] security

[arisawa]

I vote to Uriel.

On 2007/10/29, at 3:43, Uriel wrote:
>
> I'm still wondering what is the cost of having path be (/bin .) (other
> than running scripts actually becoming much faster when access to . is
> slow).
>
> For once I'm with don, just because perfect security is impossible
> doesn't mean we should stop trying to get closer to it, specially when
> the cost (as far as anyone has been able to tell in this case) is
> negligible.
>
> What is next? we get rid of file permissions 'because your coworkers
> can already pick the pile of papers lying on your desk so you should
> trust them anyway.
>
> Seeing this kinds of arguments is quite sad, specially given how far
> ahead plan9 is from every other system when it comes to *real*
> *practical* security.
>
> And I'm an idiot, but this whole discussion has become quite stupid.
>
> uriel

Re: [9fans] security

[Pietro Gagliardi]

I agree with Uriel as well. If you read my last post (I'll send it  
again if you didn't get it), I noticed some problems and I hope to  
find solutions or causes of them. Again, security is not my forte,  
but I know how to do it.

On Oct 28, 2007, at 6:48 PM, arisawa@ar.aichi-u.ac.jp wrote:

> I vote to Uriel.
>
> On 2007/10/29, at 3:43, Uriel wrote:
>>
>> I'm still wondering what is the cost of having path be (/bin .)  
>> (other
>> than running scripts actually becoming much faster when access  
>> to . is
>> slow).
>>
>> For once I'm with don, just because perfect security is impossible
>> doesn't mean we should stop trying to get closer to it, specially  
>> when
>> the cost (as far as anyone has been able to tell in this case) is
>> negligible.
>>
>> What is next? we get rid of file permissions 'because your coworkers
>> can already pick the pile of papers lying on your desk so you should
>> trust them anyway.
>>
>> Seeing this kinds of arguments is quite sad, specially given how far
>> ahead plan9 is from every other system when it comes to *real*
>> *practical* security.
>>
>> And I'm an idiot, but this whole discussion has become quite stupid.
>>
>> uriel
>

Re: [9fans] security

[Skip Tavakkolian]

> On 2007/10/29, at 3:43, Uriel wrote:
>>
>> I'm still wondering what is the cost of having path be (/bin .) (other
>> than running scripts actually becoming much faster when access to . is
>> slow).
>>
>> For once I'm with don, just because perfect security is impossible
>> doesn't mean we should stop trying to get closer to it, specially when
>> the cost (as far as anyone has been able to tell in this case) is
>> negligible.

i didn't say we should stop trying; i said if you're using "any" software
you didn't write, you are implicitly trusting the author.

we've all read 'reflections on trusting trust'.  if trust is not
implied then each user must first examine the plan9 kernel and all
other programs and compile the parts that he has understood and
verified to be trustworthy using a "trusted" compiler, before even
worrying about whether to put . in his path or just use ./foo
whenever he needs to.

>>
>> What is next? we get rid of file permissions 'because your coworkers
>> can already pick the pile of papers lying on your desk so you should
>> trust them anyway.
>>
>> Seeing this kinds of arguments is quite sad, specially given how far
>> ahead plan9 is from every other system when it comes to *real*
>> *practical* security.

nobody suggested getting rid of any of the current security features
or not improving the security for plan9.  i'm all for any necessary fixes
and sane/practical/reasonable improvements.

>>
>> And I'm an idiot, but this whole discussion has become quite stupid.
>>
>> uriel

Re: [9fans] detecting spam

[roger peppe]

> 1) rc: the value of $path is (. /bin). It is a classic case not to
> have . as the first directory when searching for programs - it allows
> Trojan horses to form.

i always set my path to put /bin first - it's faster when doing ls of
slow network
mounts anyway.

Re: [9fans] detecting spam

[Pietro Gagliardi]

How? When I put

	path=(/bin . /usr/pietro/bin)

at the end of my /usr/pietro/profile, rc resets it.

On Oct 27, 2007, at 5:00 AM, roger peppe wrote:

>> 1) rc: the value of $path is (. /bin). It is a classic case not to
>> have . as the first directory when searching for programs - it allows
>> Trojan horses to form.
>
> i always set my path to put /bin first - it's faster when doing ls of
> slow network
> mounts anyway.

Re: [9fans] detecting spam

[erik quanstrom]

> How? When I put
> 
> 	path=(/bin . /usr/pietro/bin)
> 
> at the end of my /usr/pietro/profile, rc resets it.

first, rc doesn't read that file, it reads $home/lib/profile.
second, the preferred way of adding $home/bin/rc and
$home/bin/$cputype to your path are by binding them
like so
	bind -a $home/bin/rc /bin
	bind -a $home/bin/$cputype /bin

rc(1) and bind(1) have more details.

- erik

Re: [9fans] detecting spam

[Pietro Gagliardi]

Sorry, typo (I'm still thinking UNIX). I did mean lib/profile. I'll  
add the bind commands soon. Thanks for the information.

On Oct 27, 2007, at 9:41 AM, erik quanstrom wrote:

>> How? When I put
>>
>> 	path=(/bin . /usr/pietro/bin)
>>
>> at the end of my /usr/pietro/profile, rc resets it.
>
> first, rc doesn't read that file, it reads $home/lib/profile.
> second, the preferred way of adding $home/bin/rc and
> $home/bin/$cputype to your path are by binding them
> like so
> 	bind -a $home/bin/rc /bin
> 	bind -a $home/bin/$cputype /bin
>
> rc(1) and bind(1) have more details.
>
> - erik
>

Re: [9fans] detecting spam

[Martin Neubauer]

* Pietro Gagliardi (pietro10@mac.com) wrote:
> How? When I put
> 
> 	path=(/bin . /usr/pietro/bin)
> 
> at the end of my /usr/pietro/profile, rc resets it.

You probably shouldn't do this too much towards the end. In the standard
lib/profile there is the line

	exec rio

Whatever comes afterwards is irrelevant.

	Martin

Re: [9fans] grap retarded??

[Douglas A. Gwyn]

I'm looking into it, but meanwhile I discovered a bug in
/n/sources/plan9/sys/src/cmd/grap/input.c
In function "eprint" the second occurrence of
	for (; p < q; p++)
should be
	for (; p < ep; p++)
(p has already passed q due to the previous loop).

Also I found a bug in your "eg" implementation:
In function "set_defaults" add the line
	start_drawing = 0

Re: [9fans] grap retarded??

[Pietro Gagliardi]

Thanks for the info

On Oct 29, 2007, at 6:10 AM, Douglas A. Gwyn wrote:
>
> Also I found a bug in your "eg" implementation:
> In function "set_defaults" add the line
> 	start_drawing = 0

Re: [9fans] grap retarded??

[Douglas A. Gwyn]

I found another bug, in Plan 9 "grap" source file print.c,
function "opentemp": if tfd is not NULL and also not stdout,
it gets fclose()d twice.  I don't know whether that happens
to be benign on the Plan 9 implementation, but it can cause
problems when ported to other platforms.
Also in the same file, in the "print" function, if tfd is
stdout then stdout is fclose()d but later continues to be
used.

I'm not sure of the intent of this change from an earlier
version of "grap"; however, I suggest the following patches
to src/grap/print.c:

In print(), change the test to
	if (tfd != stdout) {
		if (tfd != NULL)
			fclose(tfd);	/* end the temp file */
		tfd = stdout;
	}

In opentemp(), delete the first occurrence of
	if (tfd != NULL)
		fclose(tfd);