11618 Use exec_attr instead of suid for smbfs mount and unmount
Review Request #2262 - Created Aug. 24, 2019 and submitted
| Information | |
|---|---|
| Gordon Ross | |
| illumos-gate | |
| 11618 | |
| Reviewers | |
| general | |
11618 Use exec_attr instead of suid for smbfs mount and unmount
I have to say, the old "SUID, add priv, drop SUID" seemed simpler.
I guess the RBAC way is "better", right? :)
Works now.
gwr@gwr-oi2$ mkdir H gwr@gwr-oi2$ mount -F smbfs //gwr@sm20lab/home_gwr H gwr@gwr-oi2$ ls H [...] gwr@gwr-oi2$ umount H
Ship It!
Testing Done: |
|
|---|
I can't immediately see how the
prof_attrandexec_attrbits are expected to take effect? I think for those to apply, you have to first assign the profile you've created to a user. Then you have to run the program usingpfexec(to elevate privileges) based on that profile. You can also, I believe, use one of the "profile shells" which (as I recall) does thepfexecbits sort of implicitly. It seems like it would be possible to havemountre-exec itself with the special flags thatpfexecuses to trigger the kernel to elevate privileges, but I don't think this just happens by populating those files per se...
Change Summary:
Try adding to profile: Basic Solaris User
Diff: |
Revision 5 (+43 -33)
|
|---|
Diff: |
Revision 6 (+41 -33)
|
|---|
Change Summary:
works now
Testing Done: |
|
|---|
Description: |
|
|---|
Testing Done: |
|
|---|
Ship It!
Ship It!
Change Summary:
Continue to use __init_suid_priv so that __priv_bracket can (still) be used to put SYS_MOUNT in effect only when we need it.
Diff: |
Revision 10 (+80 -48) |
|---|
Actually do "least privilege" (again).
-
usr/src/cmd/fs.d/smbclnt/mount/mount.c (Diff revisions 8 - 10) -
Interesting: I discovered that while __init_suid_priv appears to be designed to work OK when a process is not SUID, it does not appear to expect the requested privileges to be already in effect when it runs. To deal with that, I just added a __priv_bracket(PRIV_OFF) call after it.
The remaining __priv_bracket calls then DTRT.
-
usr/src/cmd/fs.d/smbclnt/mount/mount.c (Diff revision 10) -
Should I add any comments about why this ... PRIV_OFF call is here?
+ * The __init_suid_priv call was designed for SUID programs, + * but also works for privileges granted via exec_attr with + * one difference: the added privileges are already effective + * when the program starts, and remain effective after the call. + * To make this work more like the SUID case we'll turn off the + * additional privileges with a __priv_bracket() call here.
Ship It!
Neat! Glad you were able to get the
PRIV_PFEXECbit to work.
-
usr/src/cmd/fs.d/smbclnt/umount/umount.c (Diff revision 11) -
The sprintf here was a bug, reported by Marco Ivaldi marco.ivaldi@mediaservice.net (thanks). If someone were to exec this program with a very long argv[0] then data after typename could be smashed.
Note however that the bug was NOT any sort of root exploit because after the __init_suid_priv() call above the program has given up its root privileges and is running as the real user. That makes this just an ordinary bug, not a security bug.