There is a security problem with p9auth in u9fs: it uses uname from
Tauth/Tattach as user's identity - ignoring the user id which has been
authenticated to the auth server. As uname is always set to up->user
in devmnt, this means that:
a) a user cann't have a different name on the u9fs machine; and, more
serious,
b) a user can easily masquerade as another user to u9fs by simply
booting his terminal under that user while using own credentials for
optaining the ticket.
A proposed fix has been submitted as /n/sources/patch/u9fs-p9sk1:
/n/dump/2011/1010/sys/src/cmd/unix/u9fs/authp9any.c:369,375 -
/sys/src/cmd/unix/u9fs/authp9any.c:369,378
fprint(2, "p9anyattach: afid %d state %d\n", rx->afid,
sp->state);
if (sp->state == Established && strcmp(rx->uname, sp->uname) == 0
&& strcmp(rx->aname, sp->aname) == 0)
+ {
+ rx->uname = sp->t.suid;
return nil;
+ }
return "authentication failed";
}
Whether to use t.suid or t.cuid as the target uid remains an open
question: authsrv(6) says t.suid represents target uid; the real use,
howerver, is not that clear: cwfs for 9p2k uses t.suid; while fossil,
exportfs, cpu -R and cwfs for old9p check against t.cuid. Comments in
/sys/include/authsrv.h:58,76 appear somewhat opaque until authsrv(6)
and p9sk1 client/server code in factotum are carefully studied.
- Yaroslav
─────
Related matter:
/sys/src/9/port/devmnt.c:281
/sys/src/9/port/devmnt.c:347
/sys/src/cmd/auth/factotum/p9sk1.c:170,171
/sys/src/cmd/auth/factotum/rpc.c:341
/sys/src/libauth/auth_chuid.c:37
/sys/src/cmd/unix/u9fs/authp9any.c:370
/sys/src/cmd/unix/u9fs/u9fs.c:417,420
/sys/src/cmd/cpu.c:665
/sys/src/cmd/fossil/9auth.c:30,38
/sys/src/cmd/fossil/9auth.c:132,151
/sys/src/cmd/fossil/9auth.c:155
/sys/src/cmd/fossil/9p.c:999,1007
/sys/src/cmd/cwfs/9p1.c:134,138
/sys/src/cmd/cwfs/9p2.c:252,262
/sys/src/cmd/cwfs/auth.c:313
/sys/src/cmd/cwfs/auth.c:291
/sys/src/cmd/exportfs/exportfs.c:189,192
