Diff: |
Revision 2 (+39 -30) |
---|
11618 Use exec_attr instead of suid for smbfs mount and unmount
Review Request #2262 — Created Aug. 24, 2019 and submitted
Information | |
---|---|
gwr | |
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
-
I can't immediately see how the
prof_attr
andexec_attr
bits 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 thepfexec
bits sort of implicitly. It seems like it would be possible to havemount
re-exec itself with the special flags thatpfexec
uses 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: |
|
---|
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.
-
-
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.