Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.vms > #58393 > unrolled thread
| Started by | lawrencedo99@gmail.com |
|---|---|
| First post | 2016-06-15 00:54 -0700 |
| Last post | 2016-06-23 12:57 -0400 |
| Articles | 4 on this page of 24 — 12 participants |
Back to article view | Back to comp.os.vms
VMS Privileges Versus Linux Capabilities lawrencedo99@gmail.com - 2016-06-15 00:54 -0700
Re: VMS Privileges Versus Linux Capabilities Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-16 20:53 +0000
Re: VMS Privileges Versus Linux Capabilities lawrencedo99@gmail.com - 2016-06-16 16:02 -0700
Re: VMS Privileges Versus Linux Capabilities lawrencedo99@gmail.com - 2016-06-16 16:03 -0700
Re: VMS Privileges Versus Linux Capabilities Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-16 20:06 -0400
Re: VMS Privileges Versus Linux Capabilities "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-16 20:57 -0400
Re: VMS Privileges Versus Linux Capabilities RobertsonEricW <robertsonericw@netzero.net> - 2016-06-21 05:29 -0700
SEVMS, was: Re: VMS Privileges Versus Linux Capabilities Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-21 13:02 +0000
Re: VMS Privileges Versus Linux Capabilities Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-21 11:20 -0400
Re: VMS Privileges Versus Linux Capabilities Jerry Eckert <jerry.eckert@gmail.com> - 2016-06-21 11:41 -0500
Re: VMS Privileges Versus Linux Capabilities lawrencedo99@gmail.com - 2016-06-21 22:59 -0700
Re: VMS Privileges Versus Linux Capabilities lawrencedo99@gmail.com - 2016-06-21 22:57 -0700
Re: VMS Privileges Versus Linux Capabilities Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-22 09:38 -0400
Re: VMS Privileges Versus Linux Capabilities mcleanjoh@gmail.com - 2016-06-22 01:09 -0700
Re: VMS Privileges Versus Linux Capabilities Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-22 09:47 -0400
Re: VMS Privileges Versus Linux Capabilities David Froble <davef@tsoft-inc.com> - 2016-06-22 16:39 -0400
Re: VMS Privileges Versus Linux Capabilities Paul Sture <nospam@sture.ch> - 2016-06-22 23:14 +0200
Re: VMS Privileges Versus Linux Capabilities abrsvc <dansabrservices@yahoo.com> - 2016-06-22 14:41 -0700
Re: VMS Privileges Versus Linux Capabilities lawrencedo99@gmail.com - 2016-06-22 19:03 -0700
Re: VMS Privileges Versus Linux Capabilities Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-22 17:48 -0400
Re: VMS Privileges Versus Linux Capabilities Chris Scheers <chris@applied-synergy.com> - 2016-06-22 19:57 -0500
Re: VMS Privileges Versus Linux Capabilities David Froble <davef@tsoft-inc.com> - 2016-06-22 20:11 -0400
Re: VMS Privileges Versus Linux Capabilities koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-23 09:19 -0400
Re: VMS Privileges Versus Linux Capabilities David Froble <davef@tsoft-inc.com> - 2016-06-23 12:57 -0400
Page 2 of 2 — ← Prev page 1 [2]
| From | Chris Scheers <chris@applied-synergy.com> |
|---|---|
| Date | 2016-06-22 19:57 -0500 |
| Message-ID | <nkfc5b$82p$1@dont-email.me> |
| In reply to | #58795 |
Stephen Hoffman wrote: > On 2016-06-22 21:14:53 +0000, Paul Sture said: > >> SETPRV is a special one though. It doesn't actually go away if you >> disable it. Note for the following user SETPRV is enabled in the >> default privileges, but not in the authorized ones. > > Haven't checked this lately, but it used to be that SETPRV in the > default mask was not honored. It had to be in the authorized mask. > Allowing SETPRV from the authorized mask was intended to avoid a user > ending up nailed by the SET PROCESS /PRIVILEGE=NONE command. Various > versions of the IDSM have a write-up on this, and there have been > previous discussions. > > This SETPRV behavior led to a sequence for a username that needs > privileges initially but you wished to somewhat armor the process > against subsequent nefarious use of SETPRV: put SETPRV in the default > mask and not the authorized mask, login with the user, then SPAWN and > issue the commands requiring privileges, and then log out of the > subprocess and remove SETPRV. The SPAWN copied the privilege list from > the default mask in the parent to the authorized mask in the subprocess. Somewhat related: If you have a utility that includes a SPAWN capability, and the utility is installed with privileges, test it very carefully. At least in some versions of VMS, the SPAWNed process inherits the installed privileges unless there is code around the spawn to remove the extra privileges. -- ----------------------------------------------------------------------- Chris Scheers, Applied Synergy, Inc. Voice: 817-237-3360 Internet: chris@applied-synergy.com Fax: 817-237-3074
[toc] | [prev] | [next] | [standalone]
| From | David Froble <davef@tsoft-inc.com> |
|---|---|
| Date | 2016-06-22 20:11 -0400 |
| Message-ID | <nkf9es$14m$4@dont-email.me> |
| In reply to | #58791 |
Paul Sture wrote: > On 2016-06-22, David Froble <davef@tsoft-inc.com> wrote: >> mcleanjoh@gmail.com wrote: >>> On Friday, June 17, 2016 at 10:06:43 AM UTC+10, Stephen Hoffman wrote: >>> >>>> UWSS and drivers and execlets and ACPs, and images >>>> installed with any ALL-class privilege — and other such constructs — >>>> are already or can become fully privileged, with complete system >>>> access. >>> I thought ALL privileges didn't automatically include SECURITY >>> privilege, or does it in some contexts? >>> > > That does ring a faint bell. What version of VMS? > >> Hmmm .... >> >> AS800> set proc/priv=all >> AS800> sho proc/priv >> >> 22-JUN-2016 16:37:17.79 User: DFE Process ID: 0000012F >> Node: AS800 Process name: "DFE" >> >> Authorized privileges: >> NETMBX SETPRV SYSPRV TMPMBX >> >> Process privileges: >> ACNT may suppress accounting messages >> ALLSPOOL may allocate spooled device >> ALTPRI may set any priority value >> AUDIT may direct audit to system security audit log >> BUGCHK may make bug check log entries >> BYPASS may bypass all object access controls >> CMEXEC may change mode to exec >> CMKRNL may change mode to kernel >> DIAGNOSE may diagnose devices >> DOWNGRADE may downgrade object secrecy >> EXQUOTA may exceed disk quota >> GROUP may affect other processes in same group >> GRPNAM may insert in group logical name table >> GRPPRV may access group objects via system protection >> IMPERSONATE may impersonate another user >> IMPORT may set classification for unlabeled object >> LOG_IO may do logical i/o >> MOUNT may execute mount acp function >> NETMBX may create network device >> OPER may perform operator functions >> PFNMAP may map to specific physical pages >> PHY_IO may do physical i/o >> PRMCEB may create permanent common event clusters >> PRMGBL may create permanent global sections >> PRMMBX may create permanent mailbox >> PSWAPM may change process swap mode >> READALL may read anything as the owner >> SECURITY may perform security administration functions >> SETPRV may set any privilege bit >> SHARE may assign channels to non-shared devices >> SHMEM may create/delete objects in shared memory >> SYSGBL may create system wide global sections >> SYSLCK may lock system wide resources >> SYSNAM may insert in system logical name table >> SYSPRV may access objects via system protection >> TMPMBX may create temporary mailbox >> UPGRADE may upgrade object integrity >> VOLPRO may override volume protection >> WORLD may affect other processes in the world >> >> Process rights: >> DFE resource >> INTERACTIVE >> REMOTE >> >> System rights: >> SYS$NODE_AS800 >> >> Soft CPU Affinity: off >> >> Yep, there it is, right after READALL and before SETPRV .... > > Same behaviour for SECURITY on VAX V7.3-1. > > SETPRV is a special one though. It doesn't actually go away > if you disable it. Note for the following user SETPRV is enabled > in the default privileges, but not in the authorized ones. > > UAF> show fred > > ... > > Authorized Privileges: > ALTPRI CMKRNL IMPERSONATGRPNAM NETMBX OPER SYSNAM SYSPRV > TMPMBX VOLPRO WORLD > Default Privileges: > ALTPRI CMKRNL IMPERSONATGRPNAM NETMBX OPER SETPRV SYSNAM > SYSPRV TMPMBX VOLPRO WORLD > > And it doesn't show up in the authorized privileges, it is in the current > ones: > > $ sh proc/priv > > 22-JUN-2016 22:56:37.47 User: FRED Process ID: 00000215 > Node: SPEEDY Process name: "FRED" > > Authorized privileges: > ALTPRI CMKRNL IMPERSONATGRPNAM NETMBX OPER SYSNAM SYSPRV > TMPMBX VOLPRO WORLD > > Process privileges: > ALTPRI may set any priority value > CMKRNL may change mode to kernel > IMPERSONATE may impersonate another user > GRPNAM may insert in group logical name table > NETMBX may create network device > OPER may perform operator functions > SETPRV may set any privilege bit > SYSNAM may insert in system logical name table > SYSPRV may access objects via system protection > TMPMBX may create temporary mailbox > VOLPRO may override volume protection > WORLD may affect other processes in the world > > And yes, you can use it in that state. > > > I don't think the default privs ever go away. Could be wrong. Too lazy to check.
[toc] | [prev] | [next] | [standalone]
| From | koehler@eisner.nospam.decuserve.org (Bob Koehler) |
|---|---|
| Date | 2016-06-23 09:19 -0400 |
| Message-ID | <cGsWD1xkaIsF@eisner.encompasserve.org> |
| In reply to | #58808 |
In article <nkf9es$14m$4@dont-email.me>, David Froble <davef@tsoft-inc.com> writes: > > I don't think the default privs ever go away. Could be wrong. Too lazy to check. You can turn them off, so that your current process doesn't have them. But when you try to turn them back on, the UAF will be consulted to see if you're allowed to have them, not just your current process privileges. So you don't need SETPRV to get back something you're authorized to have.
[toc] | [prev] | [next] | [standalone]
| From | David Froble <davef@tsoft-inc.com> |
|---|---|
| Date | 2016-06-23 12:57 -0400 |
| Message-ID | <nkh4cs$e44$1@dont-email.me> |
| In reply to | #58843 |
Bob Koehler wrote: > In article <nkf9es$14m$4@dont-email.me>, David Froble <davef@tsoft-inc.com> writes: >> I don't think the default privs ever go away. Could be wrong. Too lazy to check. > > You can turn them off, so that your current process doesn't have them. > But when you try to turn them back on, the UAF will be consulted to see > if you're allowed to have them, not just your current process > privileges. So you don't need SETPRV to get back something you're > authorized to have. > Yeah, and the terminology is "authorized", not "default". I just tried to turn them off, and they are still listed. Not sure if they are set in the process tables, or just pulled from SYSUAF. Back to "too lazy" ..
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | comp.os.vms
csiph-web