[9front] user none: cwfs vs hjfs

[9front] user none: cwfs vs hjfs

[Stanley Lieber]

can someone with a working cwfs install please verify that user none is unable to access files (even user none g+rw) unless they are world readable?

hjfs allows user none to access files that are not world readable.

thanks,

sl

Re: [9front] user none: cwfs vs hjfs

[hiro]

cpu% date > blabla; ls -l blabla; auth/none cat blabla
--rw-r--r-- M 3288 hiro hiro 29 Jan 19 21:34 blabla
Tue Jan 19 21:34:07 CET 2021

cwfs manpage has:

          The group numbered 9999, normally called noworld, is special
          on the file server.  Any user belonging to that group has
          attenuated access privileges.  Specifically, when checking
          such a user's access to files, the file's permission bits
          are first ANDed with 0770 for normal files or 0771 for
          directories.  The effect is to deny world access permissions
          to noworld users, except when walking directories.

but i don't know how to check if none is part of noworld group...?

On 1/19/21, Stanley Lieber <sl@stanleylieber.com> wrote:
> can someone with a working cwfs install please verify that user none is
> unable to access files (even user none g+rw) unless they are world
> readable?
>
> hjfs allows user none to access files that are not world readable.
>
> thanks,
>
> sl
>

Re: [9front] user none: cwfs vs hjfs

[Silas McCroskey]

mystia% auth/none cat /usr/glenda/secstore
cat: can't open /usr/glenda/secstore: '/usr/glenda/secstore' access
permission denied
mystia% auth/none ls -l /usr/glenda/priv/
ls: /usr/glenda/priv/: '/usr/glenda/priv/' access permission denied
mystia%

anything more specific to try out?

- sam-d

Re: [9front] user none: cwfs vs hjfs

[Silas McCroskey]

ah, missed the "owned by user none g+rw" part.

Same behavior:

mystia% ls -ld /usr/none/incoming
d-rwxrwx--- M 5300 none ftp 0 Nov 15  2016 /usr/none/incoming
mystia% auth/none ls -l /usr/none/incoming
ls: /usr/none/incoming: '/usr/none/incoming' access permission denied
mystia% auth/none chmod 0777 /usr/none/incoming
mystia% auth/none touch /usr/none/incoming/file
mystia% auth/none chmod 0770 /usr/none/incoming/file
mystia% auth/none cat /usr/none/incoming/file
cat: can't open /usr/none/incoming/file: '/usr/none/incoming/file'
access permission denied
mystia%

- sam-d

On Tue, Jan 19, 2021 at 12:51 PM Silas McCroskey <inkswinc@gmail.com> wrote:
>
> mystia% auth/none cat /usr/glenda/secstore
> cat: can't open /usr/glenda/secstore: '/usr/glenda/secstore' access
> permission denied
> mystia% auth/none ls -l /usr/glenda/priv/
> ls: /usr/glenda/priv/: '/usr/glenda/priv/' access permission denied
> mystia%
>
> anything more specific to try out?
>
> - sam-d

Re: [9front] user none: cwfs vs hjfs

[Stanley Lieber]

On January 19, 2021 3:57:29 PM EST, Silas McCroskey <inkswinc@gmail.com> wrote:
>ah, missed the "owned by user none g+rw" part.
>
>Same behavior:
>
>mystia% ls -ld /usr/none/incoming
>d-rwxrwx--- M 5300 none ftp 0 Nov 15  2016 /usr/none/incoming
>mystia% auth/none ls -l /usr/none/incoming
>ls: /usr/none/incoming: '/usr/none/incoming' access permission denied
>mystia% auth/none chmod 0777 /usr/none/incoming
>mystia% auth/none touch /usr/none/incoming/file
>mystia% auth/none chmod 0770 /usr/none/incoming/file
>mystia% auth/none cat /usr/none/incoming/file
>cat: can't open /usr/none/incoming/file: '/usr/none/incoming/file'
>access permission denied
>mystia%
>
>- sam-d
>
>On Tue, Jan 19, 2021 at 12:51 PM Silas McCroskey <inkswinc@gmail.com> wrote:
>>
>> mystia% auth/none cat /usr/glenda/secstore
>> cat: can't open /usr/glenda/secstore: '/usr/glenda/secstore' access
>> permission denied
>> mystia% auth/none ls -l /usr/glenda/priv/
>> ls: /usr/glenda/priv/: '/usr/glenda/priv/' access permission denied
>> mystia%
>>
>> anything more specific to try out?
>>
>> - sam-d
>

i first noticed this discrepancy back when i was first screwing around with /mail/queue; i mentioned it, but nobody was interested. hjfs just honors normal file permissions. at the very least, shouldn't all our file systems treat user none the same way?

sl

Re: [9front] user none: cwfs vs hjfs

[hiro]

i was under the impression that cwfs, like hjfs, wrongly allows
access. do notice that the cat in my example succeeds and prints date.
it shouldn't IMO.

On 1/19/21, Stanley Lieber <sl@stanleylieber.com> wrote:
> On January 19, 2021 3:57:29 PM EST, Silas McCroskey <inkswinc@gmail.com>
> wrote:
>>ah, missed the "owned by user none g+rw" part.
>>
>>Same behavior:
>>
>>mystia% ls -ld /usr/none/incoming
>>d-rwxrwx--- M 5300 none ftp 0 Nov 15  2016 /usr/none/incoming
>>mystia% auth/none ls -l /usr/none/incoming
>>ls: /usr/none/incoming: '/usr/none/incoming' access permission denied
>>mystia% auth/none chmod 0777 /usr/none/incoming
>>mystia% auth/none touch /usr/none/incoming/file
>>mystia% auth/none chmod 0770 /usr/none/incoming/file
>>mystia% auth/none cat /usr/none/incoming/file
>>cat: can't open /usr/none/incoming/file: '/usr/none/incoming/file'
>>access permission denied
>>mystia%
>>
>>- sam-d
>>
>>On Tue, Jan 19, 2021 at 12:51 PM Silas McCroskey <inkswinc@gmail.com>
>> wrote:
>>>
>>> mystia% auth/none cat /usr/glenda/secstore
>>> cat: can't open /usr/glenda/secstore: '/usr/glenda/secstore' access
>>> permission denied
>>> mystia% auth/none ls -l /usr/glenda/priv/
>>> ls: /usr/glenda/priv/: '/usr/glenda/priv/' access permission denied
>>> mystia%
>>>
>>> anything more specific to try out?
>>>
>>> - sam-d
>>
>
> i first noticed this discrepancy back when i was first screwing around with
> /mail/queue; i mentioned it, but nobody was interested. hjfs just honors
> normal file permissions. at the very least, shouldn't all our file systems
> treat user none the same way?
>
> sl
>

Re: [9front] user none: cwfs vs hjfs

[Anthony Martin]

/sys/src/cmd/cwfs/sub.c:/^iaccess
/sys/src/cmd/hjfs/auth.c:/^permcheck
/sys/src/cmd/fossil/9p.c:/^permFile

Hjfs is the odd man out.

Cheers,
  Anthony

Re: [9front] user none: cwfs vs hjfs

[ori]

Quoth Anthony Martin <ality@pbrane.org>:
> /sys/src/cmd/cwfs/sub.c:/^iaccess
> /sys/src/cmd/hjfs/auth.c:/^permcheck
> /sys/src/cmd/fossil/9p.c:/^permFile
> 
> Hjfs is the odd man out.
> 
> Cheers,
>   Anthony

Unfortunately I can't test, since I don't currently
have hjfs -- but I think this change brings hjfs
in sync.

diff -r 01125acb5565 sys/src/cmd/hjfs/auth.c
--- a/sys/src/cmd/hjfs/auth.c	Tue Jan 19 19:56:38 2021 -0800
+++ b/sys/src/cmd/hjfs/auth.c	Thu Jan 21 08:21:34 2021 -0800
@@ -301,10 +301,13 @@
 	if((fs->flags & FSNOPERM) != 0)
 		return 1;
 	perm = d->mode & 0777;
-	if(d->uid == uid)
-		perm >>= 6;
-	else if(ingroup(fs, uid, d->gid, 0))
-		perm >>= 3;
+	/* uid none gets only other permissions */
+	if(d->uid != 0) {
+		if(d->uid == uid)
+			perm >>= 6;
+		else if(ingroup(fs, uid, d->gid, 0))
+			perm >>= 3;
+	}
 	switch(mode & 3){
 	case OREAD:
 		return (perm & 4) != 0;

Re: [9front] user none: cwfs vs hjfs

[sirjofri]

Hello,

just a sidenote, the paper about 9 (/sys/doc/9.ps) also mentions the 
behavior of none, it basically always has world permissions, independent 
of the ownership, iirc.

sirjofri

Re: [9front] user none: cwfs vs hjfs

[Stanley Lieber]

On January 21, 2021 12:05:58 PM EST, sirjofri <sirjofri+ml-9front@sirjofri.de> wrote:
>Hello,
>
>just a sidenote, the paper about 9 (/sys/doc/9.ps) also mentions the 
>behavior of none, it basically always has world permissions, independent 
>of the ownership, iirc.
>
>sirjofri
>

yes, the whole problem here is hjfs does something different. i've been on hjfs so long i became accustomed to its behavior and expected it everywhere.

fixing hjfs may break assumptions in some people's setups.

sl

Re: [9front] user none: cwfs vs hjfs

[hiro]

otoh not fixing hjfs may break security assumptions.

Re: [9front] user none: cwfs vs hjfs

[Stanley Lieber]

On January 21, 2021 5:01:06 PM EST, hiro <23hiro@gmail.com> wrote:
>otoh not fixing hjfs may break security assumptions.
>

yes. i think we should fix hjfs. a lot of stuff relies on user none doing what it does in cwfs. the most import thing is that all file systems behave the same way.

that said, relegating user none to world readable files while simultaneously running basically every service as none makes isolating services, and more blatantly keeping local users out of service files, difficult if not impossible.

i think they got lazy with user none. we need some finer grade control over user capabilities.

sl

Re: [9front] user none: cwfs vs hjfs

[hiro]

why do you think running every service as none is a recommended practice?

On 1/21/21, Stanley Lieber <sl@stanleylieber.com> wrote:
> On January 21, 2021 5:01:06 PM EST, hiro <23hiro@gmail.com> wrote:
>>otoh not fixing hjfs may break security assumptions.
>>
>
> yes. i think we should fix hjfs. a lot of stuff relies on user none doing
> what it does in cwfs. the most import thing is that all file systems behave
> the same way.
>
> that said, relegating user none to world readable files while simultaneously
> running basically every service as none makes isolating services, and more
> blatantly keeping local users out of service files, difficult if not
> impossible.
>
> i think they got lazy with user none. we need some finer grade control over
> user capabilities.
>
> sl
>

Re: [9front] user none: cwfs vs hjfs

[hiro]

if multiple users need to keep state that is supposed to be separated
and private, then those users need to authenticate in a reliable way.

for this we have dp9ik, and fileservers can do user-level and even
group-level separation, so that state can be kept by a single and not
1 fileserver per user.

On 1/21/21, hiro <23hiro@gmail.com> wrote:
> why do you think running every service as none is a recommended practice?
>
> On 1/21/21, Stanley Lieber <sl@stanleylieber.com> wrote:
>> On January 21, 2021 5:01:06 PM EST, hiro <23hiro@gmail.com> wrote:
>>>otoh not fixing hjfs may break security assumptions.
>>>
>>
>> yes. i think we should fix hjfs. a lot of stuff relies on user none doing
>> what it does in cwfs. the most import thing is that all file systems
>> behave
>> the same way.
>>
>> that said, relegating user none to world readable files while
>> simultaneously
>> running basically every service as none makes isolating services, and
>> more
>> blatantly keeping local users out of service files, difficult if not
>> impossible.
>>
>> i think they got lazy with user none. we need some finer grade control
>> over
>> user capabilities.
>>
>> sl
>>
>

Re: [9front] user none: cwfs vs hjfs

[Silas McCroskey]

>  right now, running as user none is the only way to mask proc and other # file system data.

How so?

RFNOMNT   If set, subsequent mounts into the new name space
                    and dereferencing of pathnames starting with # are
                    disallowed.

- sam-d

Re: [9front] user none: cwfs vs hjfs

[Stanley Lieber]

On January 21, 2021 6:26:27 PM EST, Silas McCroskey <inkswinc@gmail.com> wrote:
>>  right now, running as user none is the only way to mask proc and other # file system data.
>
>How so?
>
>RFNOMNT   If set, subsequent mounts into the new name space
>                    and dereferencing of pathnames starting with # are
>                    disallowed.
>
>- sam-d
>

let's stipulate i don't know what i'm talking about.

when i brought this up with cinap and ori on irc they agreed there is a bit of a problem here. maybe we're all wrong, or maybe i misunderstood their confirmation of my observations.

observed: hjfs handles user none differently.

observed: as a regular user i was able to access # after rfork m.

i'll bow out pending this getting swept under the rug again.

sl

Re: [9front] user none: cwfs vs hjfs

[Silas McCroskey]

Huh, I can confirm RFNOMNT seems to not quite work as implied.

"rfork m; ls `{awk '{print $1}' /dev/drivers}"

Showed a lot of "mount/attach disallowed", but some were still allowed
(including #p).

- sam-d

Re: [9front] user none: cwfs vs hjfs

[cinap_lenrek]

we'r working towards getting rid of these exceptions...

tho #| will always be required as binding is how you
make a anonymous pipe.

--
cinap

Re: [9front] user none: cwfs vs hjfs

[ori]

Quoth Stanley Lieber <sl@stanleylieber.com>:
> On January 21, 2021 6:26:27 PM EST, Silas McCroskey <inkswinc@gmail.com> wrote:
> >>  right now, running as user none is the only way to mask proc and other # file system data.
> >
> >How so?
> >
> >RFNOMNT   If set, subsequent mounts into the new name space
> >                    and dereferencing of pathnames starting with # are
> >                    disallowed.
> >
> >- sam-d
> >
> 
> let's stipulate i don't know what i'm talking about.
> 
> when i brought this up with cinap and ori on irc they agreed there is a bit of a problem here. maybe we're all wrong, or maybe i misunderstood their confirmation of my observations.
> 
> observed: hjfs handles user none differently.

Yes. Let's normalize the behavior. Since it seems
like the cwfs behavior is expected and intended,
I'd want to patch hjfs to match it.

I'm happy to give you (and anyone else following)
time to fix bugs, maybe going as far as putting
the change behind a console knob for a few weeks
for testing. I'd want the knob to go away quickly,
though.

> observed: as a regular user i was able to access # after rfork m.

That is unexpected -- rfork m works as documented for me,
though I think we punched a couple of holes to make it
more useful. Without '#|', rc would be entirely broken
after 'rfork m'.

	cpu% rfork m
	cpu% for(d in `{awk '{print $1}' /dev/drivers}){
		ls $d>/dev/null && echo allowed: $d
	}
	ls: #/: mount/attach disallowed
	allowed: #c
	ls: #¶: mount/attach disallowed
	ls: #P: mount/attach disallowed
	ls: #$: mount/attach disallowed
	allowed: #e
	allowed: #|
	allowed: #p
	ls: #M: mount/attach disallowed
	ls: #s: mount/attach disallowed
	ls: #σ: mount/attach disallowed
	allowed: #d
	ls: #r: mount/attach disallowed
	ls: #D: mount/attach disallowed
	ls: #a: mount/attach disallowed
	ls: #¤: mount/attach disallowed
	ls: #K: mount/attach disallowed
	ls: #k: mount/attach disallowed
	ls: #l: mount/attach disallowed
	ls: #B: mount/attach disallowed
	ls: #I: mount/attach disallowed
	ls: #i: mount/attach disallowed
	ls: #m: mount/attach disallowed
	ls: #b: mount/attach disallowed
	ls: #v: mount/attach disallowed
	ls: #S: mount/attach disallowed
	ls: #æ: mount/attach disallowed
	ls: #A: mount/attach disallowed
	ls: #t: mount/attach disallowed
	ls: #u: mount/attach disallowed
	ls: #g: mount/attach disallowed
	ls: #X: mount/attach disallowed
	ls: #Δ: mount/attach disallowed

On the other hand:

	cpu% auth/none
	cpu% for(d in `{awk '{print $1}' /dev/drivers}){
			ls $d>/dev/null && echo allowed: $d
		}
	allowed: #/
	allowed: #c
	allowed: #¶
	allowed: #P
	allowed: #$
	allowed: #e
	allowed: #|
	allowed: #p
	ls: #M: mount/attach disallowed
	allowed: #s
	allowed: #σ
	allowed: #d
	allowed: #r
	allowed: #D
	allowed: #a
	allowed: #¤
	allowed: #K
	allowed: #k
	allowed: #l
	allowed: #B
	allowed: #I
	ls: #i: no frame buffer
	allowed: #m
	ls: #b: permission denied
	allowed: #v
	allowed: #S
	allowed: #æ
	ls: #A: no free devices
	allowed: #t
	allowed: #u
	allowed: #g
	allowed: #X
	allowed: #Δ

Re: [9front] user none: cwfs vs hjfs

[Stanley Lieber]

On January 21, 2021 7:24:05 PM EST, ori@eigenstate.org wrote:
>Quoth Stanley Lieber <sl@stanleylieber.com>:
>> On January 21, 2021 6:26:27 PM EST, Silas McCroskey <inkswinc@gmail.com> wrote:
>> >>  right now, running as user none is the only way to mask proc and other # file system data.
>> >
>> >How so?
>> >
>> >RFNOMNT   If set, subsequent mounts into the new name space
>> >                    and dereferencing of pathnames starting with # are
>> >                    disallowed.
>> >
>> >- sam-d
>> >
>> 
>> let's stipulate i don't know what i'm talking about.
>> 
>> when i brought this up with cinap and ori on irc they agreed there is a bit of a problem here. maybe we're all wrong, or maybe i misunderstood their confirmation of my observations.
>> 
>> observed: hjfs handles user none differently.
>
>Yes. Let's normalize the behavior. Since it seems
>like the cwfs behavior is expected and intended,
>I'd want to patch hjfs to match it.
>
>I'm happy to give you (and anyone else following)
>time to fix bugs, maybe going as far as putting
>the change behind a console knob for a few weeks
>for testing. I'd want the knob to go away quickly,
>though.
>
>> observed: as a regular user i was able to access # after rfork m.
>
>That is unexpected -- rfork m works as documented for me,
>though I think we punched a couple of holes to make it
>more useful. Without '#|', rc would be entirely broken
>after 'rfork m'.
>
>	cpu% rfork m
>	cpu% for(d in `{awk '{print $1}' /dev/drivers}){
>		ls $d>/dev/null && echo allowed: $d
>	}
>	ls: #/: mount/attach disallowed
>	allowed: #c
>	ls: #¶: mount/attach disallowed
>	ls: #P: mount/attach disallowed
>	ls: #$: mount/attach disallowed
>	allowed: #e
>	allowed: #|
>	allowed: #p
>	ls: #M: mount/attach disallowed
>	ls: #s: mount/attach disallowed
>	ls: #σ: mount/attach disallowed
>	allowed: #d
>	ls: #r: mount/attach disallowed
>	ls: #D: mount/attach disallowed
>	ls: #a: mount/attach disallowed
>	ls: #¤: mount/attach disallowed
>	ls: #K: mount/attach disallowed
>	ls: #k: mount/attach disallowed
>	ls: #l: mount/attach disallowed
>	ls: #B: mount/attach disallowed
>	ls: #I: mount/attach disallowed
>	ls: #i: mount/attach disallowed
>	ls: #m: mount/attach disallowed
>	ls: #b: mount/attach disallowed
>	ls: #v: mount/attach disallowed
>	ls: #S: mount/attach disallowed
>	ls: #æ: mount/attach disallowed
>	ls: #A: mount/attach disallowed
>	ls: #t: mount/attach disallowed
>	ls: #u: mount/attach disallowed
>	ls: #g: mount/attach disallowed
>	ls: #X: mount/attach disallowed
>	ls: #Δ: mount/attach disallowed
>
>On the other hand:
>
>	cpu% auth/none
>	cpu% for(d in `{awk '{print $1}' /dev/drivers}){
>			ls $d>/dev/null && echo allowed: $d
>		}
>	allowed: #/
>	allowed: #c
>	allowed: #¶
>	allowed: #P
>	allowed: #$
>	allowed: #e
>	allowed: #|
>	allowed: #p
>	ls: #M: mount/attach disallowed
>	allowed: #s
>	allowed: #σ
>	allowed: #d
>	allowed: #r
>	allowed: #D
>	allowed: #a
>	allowed: #¤
>	allowed: #K
>	allowed: #k
>	allowed: #l
>	allowed: #B
>	allowed: #I
>	ls: #i: no frame buffer
>	allowed: #m
>	ls: #b: permission denied
>	allowed: #v
>	allowed: #S
>	allowed: #æ
>	ls: #A: no free devices
>	allowed: #t
>	allowed: #u
>	allowed: #g
>	allowed: #X
>	allowed: #Δ
>
>

i run most of my services as regular users already (upas being the tricky one who changes its user under the hood). for this reason, /mail/queue already has to be chmod 777. user mailboxes are also a problem if some service like imap is accessing them. if none can acces them, anyone can. etc., etc., etc.

hjfs: if no one else objects i'm ready for the breaking change any time, but, yeah, a warning and a knob is probably good for a short period.

rfork m: yes, it was the punched holes i observed. the man page sam-d quoted seems to disagree with the source. also, i did not notice this discrepancy between rfork m and user none.

my most troublesome use case has been 9bbs, which does stupid things anyway, but also unexpectedly exposed stuff under # no matter if running as user none (where anyone on the fs can read all its passwords) or as a regular user (where nobody else on the 9fs can read all its passwords).

people reflexively blame observations such as these on writing rc instead of c, but i tend to ignore sic bigotry in light of the fact we've got more fundamental fish to fry!

wheeeeeeeee

sl

Re: [9front] user none: cwfs vs hjfs

[hiro]

> /mail/queue already has to be chmod 777

yeah that's definitely fucked up. did they have another way to
separate /mail/queue from the users ?! that sounds just wrong,
regardless of how we change none or `rfork m` behaviors.

> the man page sam-d quoted seems to disagree with the source.

yeah, that's bad.

> people reflexively blame observations such as these on writing rc instead of c, but i tend to ignore sic bigotry in light of the fact we've got more fundamental fish to fry!

remember, even rcpu is based on rc :D

Re: [9front] user none: cwfs vs hjfs

[Anthony Martin]

Silas McCroskey <inkswinc@gmail.com> once said:
> RFNOMNT   If set, subsequent mounts into the new name space
>           and dereferencing of pathnames starting with # are
>           disallowed.

/sys/src/9/port/chan.c:1321,1335

Cheers,
  Anthony

Re: [9front] user none: cwfs vs hjfs

[Stanley Lieber]

On January 21, 2021 5:55:00 PM EST, hiro <23hiro@gmail.com> wrote:
>if multiple users need to keep state that is supposed to be separated
>and private, then those users need to authenticate in a reliable way.
>
>for this we have dp9ik, and fileservers can do user-level and even
>group-level separation, so that state can be kept by a single and not
>1 fileserver per user.
>
>On 1/21/21, hiro <23hiro@gmail.com> wrote:
>> why do you think running every service as none is a recommended practice?
>>
>> On 1/21/21, Stanley Lieber <sl@stanleylieber.com> wrote:
>>> On January 21, 2021 5:01:06 PM EST, hiro <23hiro@gmail.com> wrote:
>>>>otoh not fixing hjfs may break security assumptions.
>>>>
>>>
>>> yes. i think we should fix hjfs. a lot of stuff relies on user none doing
>>> what it does in cwfs. the most import thing is that all file systems
>>> behave
>>> the same way.
>>>
>>> that said, relegating user none to world readable files while
>>> simultaneously
>>> running basically every service as none makes isolating services, and
>>> more
>>> blatantly keeping local users out of service files, difficult if not
>>> impossible.
>>>
>>> i think they got lazy with user none. we need some finer grade control
>>> over
>>> user capabilities.
>>>
>>> sl
>>>
>>
>

do you seriously not follow what i'm saying here or are you just trying to map out a solution?

user none masks the special # file system, but (once we fix hjfs) requires world accessible files. this means any user on the file system can also access those files unless special steps are taken to prevent it. for example, upas becomes user none to process files through /mail/queue no matter who upas starts out running as. the default listener runs as none and scans the service directory. any user on the file system (including none) must be trusted with any file none can access. there's a basic conflict here that has no current solution except "run everything that requires file privacy on separate file systems."

regular users honor finer grained file permissions, but cannot be masked from the special # file system. there is a basic conflict here that has no solution at all. any regular user must be trusted with proc, binding, unbinding, this is why user none exists in the first place.

the disconnect here is between file and process permissions. they are completely different things. we have fine grained file permissions but auth is all or nothing.

sl

Re: [9front] user none: cwfs vs hjfs

[Silas McCroskey]

> regular users honor finer grained file permissions, but cannot be masked from the special # file system. there is a basic conflict here that has no solution at all. any regular user must be trusted with proc, binding, unbinding, this is why user none exists in the first place.

Again, I think RFNOMNT makes this false, at least if it actually works
as advertised (I've never had reason to test it). The only
justification I can come up with for user none is anonymous read
access to the filesystem over the network (when that's enabled).

It does seem like I'm missing something, because I don't see why
services would've been written to become none in that case.

- Silas

Re: [9front] user none: cwfs vs hjfs

[hiro]

> do you seriously not follow what i'm saying here or are you just trying to
> map out a solution?

i was trying to imagine out loud how the existing security
architecture could be utilized as fully as possible.

i am not saying it is the best solution, just trying to stay on the
track that the bell-labs people have laid out.

i am not saying we didn't break it. but if we know the intent of the
basic architecture we might be able to fix it without creating a
second system.

Re: [9front] user none: cwfs vs hjfs

[Stanley Lieber]

On January 22, 2021 4:14:24 AM EST, hiro <23hiro@gmail.com> wrote:
>> do you seriously not follow what i'm saying here or are you just trying to
>> map out a solution?
>
>i was trying to imagine out loud how the existing security
>architecture could be utilized as fully as possible.
>
>i am not saying it is the best solution, just trying to stay on the
>track that the bell-labs people have laid out.
>
>i am not saying we didn't break it. but if we know the intent of the
>basic architecture we might be able to fix it without creating a
>second system.
>

yeah, i'm with you there. i really think they just tried to sidestep this whole issue by stipulating anyone with fs access was trusted. remember the "joke" about securing the fs by locking the server room door?

sl

Re: [9front] user none: cwfs vs hjfs

[hiro]

well there's a lot of truth in that joke.

and it really does look like they thought about proper security
concepts. but providing a nice basis, an OS, and making sure every
program uses it correctly are two different things.

it might be that this dissonance can be explained some other way. for
example if the people involved in making the email stuff were
different folks, who didn't know how to fit into that security
architecture.

as email has proven to be a longer-term thing after all, perhaps it's
worth fixing the broken upas assumptions so that upas fits again with
the rest of this system.

On 1/22/21, Stanley Lieber <sl@stanleylieber.com> wrote:
> On January 22, 2021 4:14:24 AM EST, hiro <23hiro@gmail.com> wrote:
>>> do you seriously not follow what i'm saying here or are you just trying
>>> to
>>> map out a solution?
>>
>>i was trying to imagine out loud how the existing security
>>architecture could be utilized as fully as possible.
>>
>>i am not saying it is the best solution, just trying to stay on the
>>track that the bell-labs people have laid out.
>>
>>i am not saying we didn't break it. but if we know the intent of the
>>basic architecture we might be able to fix it without creating a
>>second system.
>>
>
> yeah, i'm with you there. i really think they just tried to sidestep this
> whole issue by stipulating anyone with fs access was trusted. remember the
> "joke" about securing the fs by locking the server room door?
>
> sl
>

Re: [9front] user none: cwfs vs hjfs

[Stanley Lieber]

On January 22, 2021 10:01:34 AM EST, hiro <23hiro@gmail.com> wrote:
>well there's a lot of truth in that joke.
>
>and it really does look like they thought about proper security
>concepts. but providing a nice basis, an OS, and making sure every
>program uses it correctly are two different things.
>
>it might be that this dissonance can be explained some other way. for
>example if the people involved in making the email stuff were
>different folks, who didn't know how to fit into that security
>architecture.
>
>as email has proven to be a longer-term thing after all, perhaps it's
>worth fixing the broken upas assumptions so that upas fits again with
>the rest of this system.
>
>On 1/22/21, Stanley Lieber <sl@stanleylieber.com> wrote:
>> On January 22, 2021 4:14:24 AM EST, hiro <23hiro@gmail.com> wrote:
>>>> do you seriously not follow what i'm saying here or are you just trying
>>>> to
>>>> map out a solution?
>>>
>>>i was trying to imagine out loud how the existing security
>>>architecture could be utilized as fully as possible.
>>>
>>>i am not saying it is the best solution, just trying to stay on the
>>>track that the bell-labs people have laid out.
>>>
>>>i am not saying we didn't break it. but if we know the intent of the
>>>basic architecture we might be able to fix it without creating a
>>>second system.
>>>
>>
>> yeah, i'm with you there. i really think they just tried to sidestep this
>> whole issue by stipulating anyone with fs access was trusted. remember the
>> "joke" about securing the fs by locking the server room door?
>>
>> sl
>>
>

there is definitely a disconnect between "everyone uses the same fs" and the way they implemented all these services for mere users.

sl

Re: [9front] user none: cwfs vs hjfs

[hiro]

> upas becomes user none to process files through /mail/queue no
> matter who upas starts out running as.

sounds like a bug

> that has no current solution except "run everything that requires file
> privacy on separate file systems."

later on you say file permissions are granular enough. so i don't know
why you say here that "file privacy" would be a problem.

> but cannot be masked
> from the special # file system.

oh? i was not aware. do you have a trivial example for this, i'm curious!

> solution at all. any regular user must be trusted with proc, binding,
> unbinding, this is why user none exists in the first place.

> the disconnect here is between file and process permissions. they are
> completely different things. we have fine grained file permissions but auth
> is all or nothing.

so is there a problem with /proc ? can we read other user's memory or
something? or what did you find?

Re: [9front] user none: cwfs vs hjfs

[Stanley Lieber]

On January 21, 2021 5:51:02 PM EST, hiro <23hiro@gmail.com> wrote:
>why do you think running every service as none is a recommended practice?
>
>On 1/21/21, Stanley Lieber <sl@stanleylieber.com> wrote:
>> On January 21, 2021 5:01:06 PM EST, hiro <23hiro@gmail.com> wrote:
>>>otoh not fixing hjfs may break security assumptions.
>>>
>>
>> yes. i think we should fix hjfs. a lot of stuff relies on user none doing
>> what it does in cwfs. the most import thing is that all file systems behave
>> the same way.
>>
>> that said, relegating user none to world readable files while simultaneously
>> running basically every service as none makes isolating services, and more
>> blatantly keeping local users out of service files, difficult if not
>> impossible.
>>
>> i think they got lazy with user none. we need some finer grade control over
>> user capabilities.
>>
>> sl
>>
>

upas for one hardcodes switching to user none even if you don't run it as user none.

sl

Re: [9front] user none: cwfs vs hjfs

[Stanley Lieber]

On January 21, 2021 6:00:33 PM EST, Stanley Lieber <sl@stanleylieber.com> wrote:
>On January 21, 2021 5:51:02 PM EST, hiro <23hiro@gmail.com> wrote:
>>why do you think running every service as none is a recommended practice?
>>
>>On 1/21/21, Stanley Lieber <sl@stanleylieber.com> wrote:
>>> On January 21, 2021 5:01:06 PM EST, hiro <23hiro@gmail.com> wrote:
>>>>otoh not fixing hjfs may break security assumptions.
>>>>
>>>
>>> yes. i think we should fix hjfs. a lot of stuff relies on user none doing
>>> what it does in cwfs. the most import thing is that all file systems behave
>>> the same way.
>>>
>>> that said, relegating user none to world readable files while simultaneously
>>> running basically every service as none makes isolating services, and more
>>> blatantly keeping local users out of service files, difficult if not
>>> impossible.
>>>
>>> i think they got lazy with user none. we need some finer grade control over
>>> user capabilities.
>>>
>>> sl
>>>
>>
>
>upas for one hardcodes switching to user none even if you don't run it as user none.
>
>sl
>

right now, running as user none is the only way to mask proc and other # file system data.

it's the default user for the listener, hiro.

sl

Re: [9front] user none: cwfs vs hjfs

[Silas McCroskey]

On Tue, Jan 19, 2021 at 2:05 PM hiro <23hiro@gmail.com> wrote:
>
> i was under the impression that cwfs, like hjfs, wrongly allows
> access. do notice that the cat in my example succeeds and prints date.
> it shouldn't IMO.

That behavior is correct. None has read access because the file is
world-readable. There's nothing wrong in your example.

- sam-d

Re: [9front] user none: cwfs vs hjfs

[hiro]

i can't even do chgrp none file, -- not in group

On 1/20/21, Silas McCroskey <inkswinc@gmail.com> wrote:
> On Tue, Jan 19, 2021 at 2:05 PM hiro <23hiro@gmail.com> wrote:
>>
>> i was under the impression that cwfs, like hjfs, wrongly allows
>> access. do notice that the cat in my example succeeds and prints date.
>> it shouldn't IMO.
>
> That behavior is correct. None has read access because the file is
> world-readable. There's nothing wrong in your example.
>
> - sam-d
>

Re: [9front] user none: cwfs vs hjfs

[Stanley Lieber]

On January 19, 2021 8:12:46 PM EST, hiro <23hiro@gmail.com> wrote:
>i can't even do chgrp none file, -- not in group
>
>On 1/20/21, Silas McCroskey <inkswinc@gmail.com> wrote:
>> On Tue, Jan 19, 2021 at 2:05 PM hiro <23hiro@gmail.com> wrote:
>>>
>>> i was under the impression that cwfs, like hjfs, wrongly allows
>>> access. do notice that the cat in my example succeeds and prints date.
>>> it shouldn't IMO.
>>
>> That behavior is correct. None has read access because the file is
>> world-readable. There's nothing wrong in your example.
>>
>> - sam-d
>>
>

yes, file permissions will apply as normal so long as you're not actually user none.

the problem i'm describing here is cwfs and hjfs behave differently for user none.

sl

Re: [9front] user none: cwfs vs hjfs

[Stanley Lieber]

On January 19, 2021 3:51:37 PM EST, Silas McCroskey <inkswinc@gmail.com> wrote:
>mystia% auth/none cat /usr/glenda/secstore
>cat: can't open /usr/glenda/secstore: '/usr/glenda/secstore' access
>permission denied
>mystia% auth/none ls -l /usr/glenda/priv/
>ls: /usr/glenda/priv/: '/usr/glenda/priv/' access permission denied
>mystia%
>
>anything more specific to try out?
>
>- sam-d
>

; chmod 700 file.       # file not owned by none
; chgrp none file && chmod g+wr file
; auth/none cat file

sl