Use of BYPASS privilege in layered products

[Bart Zorn_1]

This may be chasing ghosts but I have been doing it for years already :-(

Did you ever do the following:

$ SEARCH SYS$STARTUP:TCPIP*.COM BYPASS /NOOUT/STAT

You get an amazing 21 matches, both in TCPIP V5.4 ECO5 and V5.5 ECO1.

Here is a snippet from TCPIP$DHCP_V50_V51_DBROLL.COM (I know, you don't use it every day)

$!
$! Set the required privileges.
$! BYPASS read files owned by someone else. set file ownership to someone
$! else.
$! SYSPRV don't know
$! OPER to use cluster shutdown/sysman
$ REQUIRED_PRIVILEGES = "BYPASS,SYSPRV,OPER"

This really gives me the creeps. The author of this code does not seem to have a clue what he/she is talking about.

Should we trust a layered product like that?

I am looking forward to your reactions! (but I am not sure if I am going to assign points :-)

Regards,

Bart Zorn

[Arch_Muthiah]

Bart,

As far as I know and (as per VMS docs) many of SMTP, MAIL cmnds require BYPASS, SYSNAM, and SYSPRV privileges because those MAIL related commands inturn call many $kernel mode IO services. So first read system's priv mask sets and make sure it has the required priv bit set and then it starts processing further, if it doesn't find those priv, it will show error like MAIL$_NOxxxPRV errors.

TCPIP> set config SMTP, start mail, stop mail, and send mail all requires BYPASS priv.

Also there are conflicts in our docs about the required priv for any operations by any products.
for example. doc says mail cmds require SYSNAM priv, but SYSPRV will work fine; BYPASS is reqd priv for BACKUP, but we can do backup with SYSPRV. Like that DEFINE/SYSTEM requires SYSNAM, but SYSPRV also can be used. So thats why people feels free to use these priv with layered products

Archunan

[Uwe Zessin]

> mail cmds require SYSNAM priv,
> but SYSPRV will work fine;

I think SYSNAM is explicitly asked for if you like to set a forward for a different user although, technically, the code only needs write access to the mail profile file.

> BYPASS is reqd priv for BACKUP,
> but we can do backup with SYSPRV.

Try to do a BACKUP with SYSPRV privilege if the user has removed all access from the SYSTEM field of the file protection mask ;-)

You don't need "BYPASS" privilege to do backups - you need read access to the file (and perhaps CONTROL access for BACKUP/RECORD)

The READALL privilege has been created a long time ago for these purposes.

>Like that DEFINE/SYSTEM requires SYSNAM,
> but SYSPRV also can be used.

You need write access to the logical name table and you need SYSNAM privilege if you want to create a logical name in an inner mode.


The problem is that VMS has started to carry a lot of ballast from old limitations and workarounds. The documentation is not always up to date nor crystal clear. Certain privileges have side effects.


> Should we trust a layered product like that?

I have seen much worse code over the years - not only from VMS' owner, but other companies as well. I have seen software with a lot of obvious (at least to me ;-) bugs that used to or is still running in mission critial environments.
Sad, but true!!

[John Gillings]

Bart,

If you mean what I think you mean, I agree. Resorting to BYPASS usually indicates laziness or ignorance, and opens up the possibility that a trivial error turns into a disaster.

In the case of SYS$ and TCPIP$ procedures I guess you just have to "trust HP". They're doing system level things, usually from system level accounts where the privilege lists are redundant (even for BYPASS).

I must admit "$! SYSPRV don't know" is a bit scary ;-)

[Bart Zorn_1]

I am sure that the fact that SMTP requires BYPASS does NOT come from the use of kernel services, but just from laziness. The implementation of SMTP in TCP/IP services for OpenVMS looks very clumsy to me anyway. It doesn't even know what a cluster is! But then again, I used to manage systems running PMDF.

My general feeling regarding users who take the effort to block files from system access (so that SYSPRV is not enough to do backups) is that they should also take the effort to arrange their own backups.

I wish you all a merry Christmas and a happy New Year!

Bart Zorn

[Bart Zorn_1]

To Archunan Muthiah:

I doubt if the fact that the requirement for certain privileges is documented warrants the proper use.

I know of a certain Job Scheduling package which, according to their documentation, needs all kinds of privileges, including things like BYPASS and SETPRV for sharable images. Some images even needed PRCNAM privilege, again, according to their documentation. Because they apparently got DCL errors trying to enable PRCNAM, they just installed all 44 images with ALL privileges.

To John,

OK, this is not a Digital/Compaq/HP product. But just trusting the TCP/IP product after all the trouble we have had with it (we are running V5.4 ECO5Plus3 on OpenVMS V7.3-2) is a bit much to ask.

Regards,

Bart Zorn

[Arch_Muthiah]

Bart,

I accept your points. I think VMS system only maintains too many privileges than any other OS. For each function, there is specific priv, I have confusion/trouble remembering all those Priv. Importantly all those privileges are added only for VMS native functionalities, not for any layered products.

Layered products are just sharing the existing priv. The problem is with the difference in the documentations of OS and layered products. The undocumented commands/ functions will be bundled with OS considering the layered products, and layered product docs says its own requirements. If we see the layered products resource/confgn requirements, it will be more than the actual requirements to avoid any OS resource/priv access conflicts. If we follow the layered prod docs, there won't be any problem. VMS can take care any unexpected problems cuased by layered products process. But if we install and run the layered product without the proper resource/priv/rights mentioned in the docs(VMS sometime allows to install), then VMS will not handle the due problems, instead either it will start hang or endup with crash with so many reasons. Most of the VMS crashes are being occured due to the VMS resource access conflicts with layered product's process.
And that too if the crash is by the process entered via TCP due to over privileged TCP processes, then tracing the crash reason would be very difficult.

Uwe: Thanks for remainding me about RAEDALL Priv. I did not have chance to go into deep anayzing the various alternate PRIV. I will use this chance to go through what you mentioned.

Archunan

[Jan van den Ende]

Bart,

From John's answer:


In the case of SYS$ and TCPIP$ procedures I guess you just have to "trust HP".


In the case of SYS$, and in fact ALL VMS-originated codes, I do indeed implicitly trust Engeneering (but not HP in general).
On of the basic rules that that trust stems from is "Do NOT break existing code".

But, as indicated various times by various people, TCPIP explicitly is NOT included in the description of VMS, if this statement is to remain valid.
And now you have quite clearly demonstrated that TCPIP is also an exception to the statement that VMS is secure.

HP would do well to re-vamp DECnet, ( fat chance! ) or by having "TCPIP services for VMS" done (re-done?) by trained VMS Engeneers, and not, or not exclusively, by some unixians that may spread their "root for all non-dummy-user functionality".

Bart, this was a real Christmas surprise, but not a pleasant one! :-(

Seasonal greetings to all,

Proost.

Have one on me.

jpe

[Robert Gezelter]

Bart,

I must, with all due respect, disagree with some of Archunan's comments.

First, you do not need BYPASS or SYSPRV to do BACKUPs, although very elevated privileges may be required to RESTORE files. A normal BACKUP operation (one that does not modify the subject files in any way) can accomplished with READALL.

The granularity of privilege in OpenVMS is more nuanced than say a *IX (where ROOT controls everything). Properly implemented, these privileges allow system management responsibilities to be widely distributed, without endangering the overall system (see the summary description of my presentation from HP World 2004, http://www.rlgsc.com/hpworld/2004/N227.html).

It is true that this flexibility requires a better understanding of the system than the "one bit controls everything" approach, but that is a good thing, not a bad thing. It is also true that some otherwise non-privileged, or lesser privileged command procedures require privileges for a single purpose (e.g. invoking SYSMAN or LATCP). It should also, but sometimes isn't, properly documented.

I have done security audits of some critical systems, and sites were written up for issues including excessive privileges, whether for program images or users. You simply cannot speak to the integrity of the overall system if there are a lot of privileges floating around.

- Bob Gezelter, http://www.rlgsc.com

[David Jones_21]

The TCP/IP product has a long tradition of lazy programmers. I remember one ECO that was released and then pulled because it was prone to crash your system because they didn't lock the memory pages before elevating IPL.

The supplied device drivers, running in inner mode, transcend the privilege scheme anyway so I don't sweat much about which privileges the user mode components use.

[Ian Miller.]

worrying :-)

I hope this is due to overstetched rather than ignorant programmers but its not a good sign considering this products chequered history.

BTW the part of VMS MAIL that needs SYSPRV is installed with it.

[Bart Zorn_1]

Archunan Muthiah wrote:

"Layered products are just sharing the existing priv. The problem is with the difference in the documentations of OS and layered products. The undocumented commands/ functions will be bundled with OS considering the layered products, and layered product docs says its own requirements. If we see the layered products resource/confgn requirements, it will be more than the actual requirements to avoid any OS resource/priv access conflicts. If we follow the layered prod docs, there won't be any problem. VMS can take care any unexpected problems cuased by layered products process. But if we install and run the layered product without the proper resource/priv/rights mentioned in the docs(VMS sometime allows to install), then VMS will not handle the due problems, instead either it will start hang or endup with crash with so many reasons. Most of the VMS crashes are being occured due to the VMS resource access conflicts with layered product's process.
And that too if the crash is by the process entered via TCP due to over privileged TCP processes, then tracing the crash reason would be very difficult."

I think that if someone is going to write a piece of software that he/she wants to sell and support, it is an absolute requirement that you know what you are talking about. If you are using system services you are going to read the documentation and there is exactly specified which privileges are needed for what purpose. So there is no way that a good programmer does not know what privileges are needed. Also, you will not be using undocumented features, because at some day they will bite you.

At least the part of your documentation which covers the required privileges is written in paralell with the code.

If layered products say (per their documentation) that they need more privileges than they actually do, then there is something seriously wrong.

Regards,

Bart

[Wim Van den Wyngaert]

It would be a nice improvement if something like

anal/ima/priv xxxx.exe

would report the privs needed by this exe and everything it is calling.

Asking the programmer to keep this info in a doc file is hopeless, especially if things change.

Wim