Re: BYPASS privilege !!

In article <1181606749.449032.311320@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
BaxterD@xxxxxxxxxx wrote:


....

Equally obvious, to a user with BYPASS privilege, it matters not how
well you lock down the security on your app, since BYPASS by
definition, will bypass all system security. Once the app is
properly secured, then the only way for a non-application, privileged
username to access the application directories or files is either to
grant themselves the necessary identifiers, or use BYPASS to bulldoze
their way in. Both of these actions, (and most other discrete
attempts) can be recorded in the Security Audit Journal.

There are a number of ways to completely bypass security in addition to
BYPASS priv. Some of them require a bit more work.

In particular, if you give me CMKRNL, I can write a program to do
anything. So you need to keep me from writing a program or bringing one
on site. And I could create the program using EDIT. (Slow and painful,
but possible.)


It goes without saying, but I'll say it anyway, that you need to read and
understand the guide to system security. I assume you've done that, but a
reminder seems prudent for other folks reading the thread.


However, If there happen to be multiple Administrators, all using the
SYSTEM account for their admin duties. How do you determine who
did what?

I know this sounds fairly paranoid, and for people running 2- and 3-
tier apps, this all sounds a bit weird, but we are just running
through (a few of the endless number of) options.

1. Give each admin a personalized admin account with no BYPASS (and
maybe other privs also)

This is one ingredient of every serious security policy I've read about.
If you have multiple people sharing an account, you really can't audit who
did what to which objects.

For starters, you should give each admin his own account, copying the
privs and quotas of the system account. Remove privs as you test
understand the impact of doing so.

VMS products SHOULD document what privs are requried, but I fear the
documentation is less than perfect. Some trial and error will likely be
needed.

If you find documentation that is wrong or incomplete in terms of required
privs, please send feedback to HP.

Reserve the SYSTEM account for:
1. Starting the system. I fear you'll create a LOT of work chasing down
little-known priv requirements if you try to use a different account.

2. Emergency use, to fix problems due to unforseen personnel changes and etc.


2. Lock down the SYSTEM account for use only when carrying out
Maint, Upgrades or Patching.

Even for this, individual accounts are safer. You'll see warnings, but
installs and patches should still work.

3. Enable auditing of Privilege use and UAF modification.

Yes, you've still got to have some level of trust for your system admins,
because they'll have to have some elevated privs. But you can keep track
of what they've done.

Final comment, I could present an endless number of scenarios which
represent risk, and for each one, someone would come up with a
solution. However the solution always comes after the
solution. We are not asking for solutions, we are merely asking if
anyone knows the answers to the two simple questions,

1. Does anyone know of any function, particularly during system
startup, which "absolutely" requires BYPASS" privilege.

Don't know. Startup is routinely tested with the SYSTEM account, which
has all privs. I'm not aware of any effort to test with a subset of
privs.

2. Does anyone know of any Admin function which "absolutely"
requires the SYSTEM account.

No, a copy of the account should always work. If you find an exception, I
would call it a bug. Report it.

For many tasks, fewer privs will be needed. Give your individual admin
accounts those privs.

If you find occasional tasks that require more privs, add them temporarily
(under supervision). Or use special task-oriented accounts with extra
privs, that are DISUSERed when not needed.
.

Relevant Pages

  • Re: Two new security flaws found in WinXP SP2
    ... :> Bob wrote: ... :> You mean if I created an account on my VMS system for you with only ... SYSTEM account with all privs. ... Last Alpha chip to arrive on Monday ...
    (sci.med.transcription)
  • Re: Security Flaws with XP
    ... You can put a password on that account. ... >> Microsoft's logon. ... >> year old punk to be able to bypass it at will. ... > You can bypass the logon screen in safe mode and logon with a default ...
    (microsoft.public.windowsxp.security_admin)
  • Re: BYPASS privilege !!
    ... and are discussing the effects of removing BYPASS privilege ... If it requires you to remove BYPASS from the system accouunt, ... Of course, if the account has SETPRV, then ... SysAdmin function which "absolutely" must be done from the SYSTEM ...
    (comp.os.vms)
  • Re: Two new security flaws found in WinXP SP2
    ... > You mean if I created an account on my VMS system for you with only ... automatically has admin privs, just like when you install VMS, you get the ... SYSTEM account with all privs. ...
    (sci.med.transcription)
  • Re: BYPASS privilege !!
    ... and are discussing the effects of removing BYPASS privilege ... If it requires you to remove BYPASS from the system accouunt, ... Of course, if the account has SETPRV, then it might as well have BYPASS in many situations. ... You can enable a second password on the SYSTEM account with, say, one password known only to the System Manager, and the other known only to someone else so it takes TWO people to log in as system. ...
    (comp.os.vms)