Discussion:
Can HP Secured Web server (SWS) run under an account other that apache$www?
(too old to reply)
d***@gmail.com
2017-06-08 11:17:02 UTC
Permalink
Raw Message
Recent I installed the web server, I would like run it under an existing account. But it looks like apache$www is everywhere in the configuration, startup and shutdown script. looks like you have to use the default account - apache$www. Is there a way to change this default account?
Jan-Erik Soderholm
2017-06-08 12:22:04 UTC
Permalink
Raw Message
Post by d***@gmail.com
Recent I installed the web server, I would like run it under an existing
account. But it looks like apache$www is everywhere in the
configuration, startup and shutdown script. looks like you have to use
the default account - apache$www. Is there a way to change this default
account?
Do you want to run the whole web environment under another user or
just selected URL/scripts? I do not know SWS in details, but usually
one can run the main server under a default user and then run
selected script processes under whatever user is appropriate.
That is how it is done on WASD at least...
Stephen Hoffman
2017-06-08 13:26:43 UTC
Permalink
Raw Message
Post by d***@gmail.com
Recent I installed the web server, I would like run it under an
existing account. But it looks like apache$www is everywhere in the
configuration, startup and shutdown script. looks like you have to use
the default account - apache$www. Is there a way to change this default
account?
Short answer:

I certainly hope not. I'd use the default install, and would set up
identifiers and would use file and directory ACLs to allow specific
users or groups or identifier-holders to have read or read-write access
in the web-related directories.

Long answer:

Why not? Okay, OpenVMS is generally way, way, way too willing to
expose this sort of stupid-flexibility to end-users, which makes
creating the associated procedures and the testing far, far, far, far
more difficult than it should be, and often exposes this flexibility
for absolutely zero gain. The developers think they're providing
something useful, when they're really either trying to avoid making a
decision, or they're making the effort required of the end-users and
third-party developers harder. This sort of flexibility makes the
associated VSI and third-party and end-user command procedures — if
they even support this sort of customization, or support installing
somewhere weird, or otherwise — more complex to test, and to support.

Given that it's easy to add the necessary user or site-specific group
identifiers to allow the desired access into the web directories, I've
yet to hit a case where I couldn't use the default Apache user. A
default user is also very common on other platforms.)

This particular case can also potentially allow a successful attack
against the web server or a web server script to be extended, or allow
the attack to more easily persist, given that the selected user may and
often does have write access outside the web directories. Or to
effect other processes sharing the same username. I really don't
trust a down-revision web server to remain particularly secure, so
keeping it isolated by username and often preventing the web server
from even owning and having write-access to as much of its own
directories as feasible seems... prudent. I'd prefer to sandbox the
web server, if the operating system supported that. (OpenVMS doesn't.)

Then there's that the last couple of times I've used the Apache command
procedures — the HPE CSWS/SWS/Apache command procedure versions,
working with the VSI versions is an upcoming project — they were...
somewhat fragile, and limited. It was much easier to wholly remove
and re-install Apache than it was to rename the host-specific
host-named web directories that the Apache procedures had created.

Then there's that the UICs of these server accounts should be
hard-coded — fixed UICs for all system accounts, just as OpenVMS
correctly did for its original core usernames — is a far easier
approach for everybody, but that's fodder for another discussion.
Just always create the damned accounts for Apache and all of the
individual TCP/IP Service server usernames and related, and each with a
hard-coded UIC value from within an existing or newly-created reserved
range. This just as [1,4] is always SYSTEM. No, don't put Apache in a
(lowercase-system) system UIC, either.

Then there's also that Apache should be part of the base installation
of OpenVMS, and in the same places. That simplifies the implementation
and testing and dependency checks of the procedures that need to use
Apache. Then all the system and add-on procedures have to test for is
"is Apache running?". But I digress.

I've had success using Python and other tools running under the account
to present a custom web server to the accessors, if that's where you're
headed.

EOR.
--
Pure Personal Opinion | HoffmanLabs LLC
David Froble
2017-06-08 15:57:32 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by d***@gmail.com
Recent I installed the web server, I would like run it under an
existing account. But it looks like apache$www is everywhere in the
configuration, startup and shutdown script. looks like you have to use
the default account - apache$www. Is there a way to change this
default account?
I certainly hope not. I'd use the default install, and would set up
identifiers and would use file and directory ACLs to allow specific
users or groups or identifier-holders to have read or read-write access
in the web-related directories.
Never used the product, so I don't know details.

It sure would be nice for the web server stuff to use a logical, or rooted
logical, and then one logical name definition would suffice for putting it
wherever you desired.
Post by Stephen Hoffman
Why not? Okay, OpenVMS is generally way, way, way too willing to expose
this sort of stupid-flexibility to end-users, which makes creating the
associated procedures and the testing far, far, far, far more difficult
than it should be, and often exposes this flexibility for absolutely
zero gain. The developers think they're providing something useful,
when they're really either trying to avoid making a decision, or they're
making the effort required of the end-users and third-party developers
harder. This sort of flexibility makes the associated VSI and
third-party and end-user command procedures — if they even support this
sort of customization, or support installing somewhere weird, or
otherwise — more complex to test, and to support.
I've always considered the flexibility in VMS to be a strength, not a weakness.
Perhaps in some situations, and opinions, it's not.

Now, if the web server became part of the OS, then yes, just as with the rest of
the OS, run it as provided. Just hope whoever sets up the standard stuff did a
decent job.

Ok, perhaps look at electrical service in the US. Everyone get 110 volts, 60
cycle. The electric company doesn't give you the option of voltage and such.

Perhaps I'm an old dinosaur, and perhaps I'll soon be joining them, but, for me,
I still think the flexibility is a strength.
Jan-Erik Soderholm
2017-06-08 16:28:25 UTC
Permalink
Raw Message
Post by David Froble
Post by Stephen Hoffman
Post by d***@gmail.com
Recent I installed the web server, I would like run it under an existing
account. But it looks like apache$www is everywhere in the
configuration, startup and shutdown script. looks like you have to use
the default account - apache$www. Is there a way to change this default
account?
I certainly hope not. I'd use the default install, and would set up
identifiers and would use file and directory ACLs to allow specific users
or groups or identifier-holders to have read or read-write access in the
web-related directories.
Never used the product, so I don't know details.
It sure would be nice for the web server stuff to use a logical, or rooted
logical, and then one logical name definition would suffice for putting it
wherever you desired.
The issue was not where some files are located, but what user is
running the web server process(es). The files can be anyware and
you can always give the web server user the access needed.

I think the misunderstandings are due to that don.zong was a little
unclear in what he was supposed to achieve.
Stephen Hoffman
2017-06-08 16:53:15 UTC
Permalink
Raw Message
Post by David Froble
Post by Stephen Hoffman
Post by d***@gmail.com
Recent I installed the web server, I would like run it under an
existing account. But it looks like apache$www is everywhere in the
configuration, startup and shutdown script. looks like you have to use
the default account - apache$www. Is there a way to change this default
account?
I certainly hope not. I'd use the default install, and would set up
identifiers and would use file and directory ACLs to allow specific
users or groups or identifier-holders to have read or read-write access
in the web-related directories.
Never used the product, so I don't know details.
It sure would be nice for the web server stuff to use a logical, or
rooted logical, and then one logical name definition would suffice for
putting it wherever you desired.
I'd generally rather have a preferences file associated with the app
bundle and not logical names defined somewhere random and then used as
a run-time configuration mechanism. Certainly locating the web server
data files somewhere other than the system disk is reasonable.
Interestingly, that's also a standard part of the Apache configuration
too. https://httpd.apache.org/docs/2.4/mod/core.html#documentroot
No need for a logical name there, either. But as for the Apache files
and the Apache configuration files and related not-user-populated
directories? Preferably those are in the same spot on all systems, and
with no supported means to relocate those.

Running under a different username, not so much. Particularly around
web server security. Though there is the chroot directive available
via mod_unixd, though whether mod_unixd has been ported to or even
works with OpenVMS, as it's not listed as part of the HPE distro.
Really not fond of the idea of using some other random username here
though, and this chroot looks like the best bad compromise for the OP.
But no mod_unixd in the default install (unless VSI has added it), so
no chroot, and OpenVMS has no chroot jail, etc. Running under a
different username on OpenVMS? Wouldn't expect that to work right, nor
to upgrade reliably across arbitrary versions.

https://httpd.apache.org/docs/2.4/mod/mod_unixd.html#chrootdir
http://h41379.www4.hpe.com/openvms/products/ips/apache/csws_install_22.pdf
(page 35 for module list)
Post by David Froble
Post by Stephen Hoffman
Why not? Okay, OpenVMS is generally way, way, way too willing to
expose this sort of stupid-flexibility to end-users, which makes
creating the associated procedures and the testing far, far, far, far
more difficult than it should be, and often exposes this flexibility
for absolutely zero gain. The developers think they're providing
something useful, when they're really either trying to avoid making a
decision, or they're making the effort required of the end-users and
third-party developers harder. This sort of flexibility makes the
associated VSI and third-party and end-user command procedures — if
they even support this sort of customization, or support installing
somewhere weird, or otherwise — more complex to test, and to support.
I've always considered the flexibility in VMS to be a strength, not a
weakness. Perhaps in some situations, and opinions, it's not.
UI flexibility for a good cause is can be good thing. Flexibility
that just works, without requiring the end-user or the developer to
deal with or know about the flexibility is even better.

UI flexibility just for the sake of flexibility, or because the
designer or the developer didn't want to or wasn't able to spend the
time to learn about what problems folks had — which can be very
different from what problems folks tell you they have — or the designer
or developer didn't want to make a UI decision, or didn't want to think
through the actual benefits and ramifications of the flexibility, or —
worse — didn't want to force third-parties to make code changes that
they really need to make, not so much. The more that can be pulled
out of a user interface design and particularly the default UI, the
better it'll serve folks.
Post by David Froble
Now, if the web server became part of the OS, then yes, just as with
the rest of the OS, run it as provided. Just hope whoever sets up the
standard stuff did a decent job.
Ok, perhaps look at electrical service in the US. Everyone get 110
volts, 60 cycle. The electric company doesn't give you the option of
voltage and such.
Perhaps I'm an old dinosaur, and perhaps I'll soon be joining them,
but, for me, I still think the flexibility is a strength.
Makes for more testing, more documentation and more permutations and
for more support costs, too. (How many tools correctly deal with
<directory> syntax, for instance? For some years, I deliberately set
my login directory and the system configurations to use that syntax,
and it blew up parts of OpenVMS, and more than a little of the add-on
apps and third-party code for OpenVMS. Don't get me started on the
utter disaster of manual directory parsing necessary in DCL, either.)
Much like compatibility, flexibility is theoretically wonderful.
Unfortunately, profligate use of either compatibility or of flexibility
leads to pain. To security pain. Support pain. Upgrade pain.
Third-party where-the-heck-are-the-web-configuration-files pain.
Splattering-files-all-over-the-system pain. To user interfaces that
The more I have to add onto the system and dink around with and to
manage and patch and upgrade separately, and the more I have to
special-case, the more the costs accrue.

In terms of user interface and discussions of fly-by-wire and of pilot
or software primacy aside, of getting from this UI:
Loading Image... to
something closer to this:
Loading Image...
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Soderholm
2017-06-08 21:20:37 UTC
Permalink
Raw Message
Den 2017-06-08 kl. 18:53, skrev Stephen Hoffman
Running under a different username, not so much. Particularly around web
server security.
Maybe not the main web server as such. But for application specific
web server processes it might be better to run them under an application
specific username. So your web processes runs just as any other process
within that application with similar protection and rights.
Though there is the chroot directive available via
mod_unixd, though whether mod_unixd has been ported to or even works with
OpenVMS...
WASD uses the "$persona" service in VMS to switch its server processes
between usernames. Works, as I know, just OK.

http://wasd.vsm.com.au/wasd_root/doc/scripting/scripting_0100.html#0020d134

"There are advantages in running a script under a non-server account.
The most obvious of these is the security isolation it offers with
respect to the rest of the Web and server environment. It also means
that the server account does not need to be resourced especially for
any particularly demanding application."

I know little about SWS, maybe it doesn't support something similar...
David Froble
2017-06-09 00:31:28 UTC
Permalink
Raw Message
Post by David Froble
Post by Stephen Hoffman
Post by d***@gmail.com
Recent I installed the web server, I would like run it under an
existing account. But it looks like apache$www is everywhere in the
configuration, startup and shutdown script. looks like you have to
use the default account - apache$www. Is there a way to change this
default account?
I certainly hope not. I'd use the default install, and would set up
identifiers and would use file and directory ACLs to allow specific
users or groups or identifier-holders to have read or read-write
access in the web-related directories.
Never used the product, so I don't know details.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Snipped a bunch of stuff ....

What if you want to run 2 web servers? 10 web servers? Doable with SWS?
John E. Malmberg
2017-06-09 01:26:59 UTC
Permalink
Raw Message
Post by David Froble
Snipped a bunch of stuff ....
What if you want to run 2 web servers? 10 web servers? Doable with SWS?
Not sure. Apache supports virtual web servers.

Regards,
-John
***@qsl.net_work
Stephen Hoffman
2017-06-09 02:15:18 UTC
Permalink
Raw Message
Post by David Froble
What if you want to run 2 web servers? 10 web servers? Doable with SWS?
It's much easier to use the virtual host feature present in Apache, as
otherwise you're forced to figure out how to use separate TCP ports for
each of the separate servers. Apache virtual hosting permits multiple
separate web sites, from the same Apache server and with all of the
sites utilizing the same pool of Apache worker processes. And all of
the virtual host sites can share TCP 80 HTTP and/or TCP 443 HTTPS
ports. All from one Apache installation, and with one set of Apache
files to configure and maintain and upgrade. And as for where your
question is probably headed here, Apache permits configuring separate
user-populated web directories — the so-called document roots — within
each virtual host declarations.

Example: https://httpd.apache.org/docs/2.4/vhosts/examples.html

You'll also usually want a multiple-domain cert for these Apache
configurations, too. (a.k.a. UC, UCC, MDC, SAN, etc.)

FWIW, minimally use HPE SWS/CSWS/Apache V2.2-1, or preferably use the
much newer VSI Apache port. The VSI version is much closer to the
current Apache version. Among other issues and insecurities present
within the yet-older Apache releases, versions of Apache earlier than
the HPE V2.2-1 version don't support the current SHA-2 commercial
certificate format.

If I need a completely separate web server, it's probably running
something other than web browsing traffic; connections intended for a
Tomcat server or a server for some other REST-based protocol, or
clients and servers using who-knows what other application protocol via
HTTP. (OpenVPN via HTTP, or httptunnel, anyone?) For simpler
requirements, Python can be launched as a web server using its standard
library, too. Web browsers don't automatically find and use TCP ports
other than TCP 80 HTTP or TCP 443 HTTPS either (short of an explicit
specification in the URL, obviously), and there's no reasonable way to
allow two entirely separate web servers or network applications to both
share the same TCP port in parallel. There needs to be some sort of a
broker, or an Apache server configured for a reverse proxy, or some
other mechanism to pass arriving connections to the appropriate server
software. Or virtual hosting, for that matter.

FWIW, mail servers have some similarities here, and many mail servers
also support virtual hosting.
--
Pure Personal Opinion | HoffmanLabs LLC
d***@gmail.com
2017-06-09 08:07:51 UTC
Permalink
Raw Message
My intention is to use web server to build a web service to be consumed by other systems, an internal project, not a public facing website. basically the web service is a wrapper for a legacy application. I hope the web service can run under the application account that is used to run the legacy application
Post by Stephen Hoffman
Post by d***@gmail.com
Recent I installed the web server, I would like run it under an
existing account. But it looks like apache$www is everywhere in the
configuration, startup and shutdown script. looks like you have to use
the default account - apache$www. Is there a way to change this default
account?
I certainly hope not. I'd use the default install, and would set up
identifiers and would use file and directory ACLs to allow specific
users or groups or identifier-holders to have read or read-write access
in the web-related directories.
Why not? Okay, OpenVMS is generally way, way, way too willing to
expose this sort of stupid-flexibility to end-users, which makes
creating the associated procedures and the testing far, far, far, far
more difficult than it should be, and often exposes this flexibility
for absolutely zero gain. The developers think they're providing
something useful, when they're really either trying to avoid making a
decision, or they're making the effort required of the end-users and
third-party developers harder. This sort of flexibility makes the
associated VSI and third-party and end-user command procedures — if
they even support this sort of customization, or support installing
somewhere weird, or otherwise — more complex to test, and to support.
Given that it's easy to add the necessary user or site-specific group
identifiers to allow the desired access into the web directories, I've
yet to hit a case where I couldn't use the default Apache user. A
default user is also very common on other platforms.)
This particular case can also potentially allow a successful attack
against the web server or a web server script to be extended, or allow
the attack to more easily persist, given that the selected user may and
often does have write access outside the web directories. Or to
effect other processes sharing the same username. I really don't
trust a down-revision web server to remain particularly secure, so
keeping it isolated by username and often preventing the web server
from even owning and having write-access to as much of its own
directories as feasible seems... prudent. I'd prefer to sandbox the
web server, if the operating system supported that. (OpenVMS doesn't.)
Then there's that the last couple of times I've used the Apache command
procedures — the HPE CSWS/SWS/Apache command procedure versions,
working with the VSI versions is an upcoming project — they were...
somewhat fragile, and limited. It was much easier to wholly remove
and re-install Apache than it was to rename the host-specific
host-named web directories that the Apache procedures had created.
Then there's that the UICs of these server accounts should be
hard-coded — fixed UICs for all system accounts, just as OpenVMS
correctly did for its original core usernames — is a far easier
approach for everybody, but that's fodder for another discussion.
Just always create the damned accounts for Apache and all of the
individual TCP/IP Service server usernames and related, and each with a
hard-coded UIC value from within an existing or newly-created reserved
range. This just as [1,4] is always SYSTEM. No, don't put Apache in a
(lowercase-system) system UIC, either.
Then there's also that Apache should be part of the base installation
of OpenVMS, and in the same places. That simplifies the implementation
and testing and dependency checks of the procedures that need to use
Apache. Then all the system and add-on procedures have to test for is
"is Apache running?". But I digress.
I've had success using Python and other tools running under the account
to present a custom web server to the accessors, if that's where you're
headed.
EOR.
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Soderholm
2017-06-09 08:39:02 UTC
Permalink
Raw Message
Post by d***@gmail.com
My intention is to use web server to build a web service to be consumed
by other systems, an internal project, not a public facing website.
basically the web service is a wrapper for a legacy application. I hope
the web service can run under the application account that is used to
run the legacy application
We have an WebService (in its correct meaning with WSDL file and SOAP
interface) running since 8 year back. The web server as such runs
under its deafult user (HTTPD$SERVER or similar) and the process for
the WebServices run under the application specific username.

It uses WASD instead of SWS, but it would surprice me a lot if you
can't specific a user to run a specific script or URL.
Post by d***@gmail.com
Post by Stephen Hoffman
Post by d***@gmail.com
Recent I installed the web server, I would like run it under an
existing account. But it looks like apache$www is everywhere in the
configuration, startup and shutdown script. looks like you have to
use the default account - apache$www. Is there a way to change this
default account?
I certainly hope not. I'd use the default install, and would set up
identifiers and would use file and directory ACLs to allow specific
users or groups or identifier-holders to have read or read-write
access in the web-related directories.
Why not? Okay, OpenVMS is generally way, way, way too willing to
expose this sort of stupid-flexibility to end-users, which makes
creating the associated procedures and the testing far, far, far, far
more difficult than it should be, and often exposes this flexibility
for absolutely zero gain. The developers think they're providing
something useful, when they're really either trying to avoid making a
decision, or they're making the effort required of the end-users and
third-party developers harder. This sort of flexibility makes the
associated VSI and third-party and end-user command procedures — if
they even support this sort of customization, or support installing
somewhere weird, or otherwise — more complex to test, and to support.
Given that it's easy to add the necessary user or site-specific group
identifiers to allow the desired access into the web directories,
I've yet to hit a case where I couldn't use the default Apache user.
A default user is also very common on other platforms.)
This particular case can also potentially allow a successful attack
against the web server or a web server script to be extended, or
allow the attack to more easily persist, given that the selected user
may and often does have write access outside the web directories. Or
to effect other processes sharing the same username. I really don't
trust a down-revision web server to remain particularly secure, so
keeping it isolated by username and often preventing the web server
from even owning and having write-access to as much of its own
directories as feasible seems... prudent. I'd prefer to sandbox the
web server, if the operating system supported that. (OpenVMS
doesn't.)
Then there's that the last couple of times I've used the Apache
command procedures — the HPE CSWS/SWS/Apache command procedure
versions, working with the VSI versions is an upcoming project — they
were... somewhat fragile, and limited. It was much easier to wholly
remove and re-install Apache than it was to rename the host-specific
host-named web directories that the Apache procedures had created.
Then there's that the UICs of these server accounts should be
hard-coded — fixed UICs for all system accounts, just as OpenVMS
correctly did for its original core usernames — is a far easier
approach for everybody, but that's fodder for another discussion. Just
always create the damned accounts for Apache and all of the individual
TCP/IP Service server usernames and related, and each with a
hard-coded UIC value from within an existing or newly-created
reserved range. This just as [1,4] is always SYSTEM. No, don't put
Apache in a (lowercase-system) system UIC, either.
Then there's also that Apache should be part of the base installation
of OpenVMS, and in the same places. That simplifies the
implementation and testing and dependency checks of the procedures
that need to use Apache. Then all the system and add-on procedures
have to test for is "is Apache running?". But I digress.
I've had success using Python and other tools running under the
account to present a custom web server to the accessors, if that's
where you're headed.
EOR.
-- Pure Personal Opinion | HoffmanLabs LLC
David Froble
2017-06-09 12:59:17 UTC
Permalink
Raw Message
Post by d***@gmail.com
My intention is to use web server to build a web service to be consumed by
other systems, an internal project, not a public facing website. basically
the web service is a wrapper for a legacy application. I hope the web service
can run under the application account that is used to run the legacy
application
I think that what some people are saying is that you can have your data that is
used by a web server wherever you want it, while the actual executaables can be
in some "standard" location.

While that actually sounds reasonable, I will admit that I too might have first
looked at placing the web server stuff with the application. But after reading
some posts, I think I agree with using the standard location.
Jan-Erik Soderholm
2017-06-09 13:01:58 UTC
Permalink
Raw Message
Post by David Froble
Post by d***@gmail.com
My intention is to use web server to build a web service to be consumed by
other systems, an internal project, not a public facing website. basically
the web service is a wrapper for a legacy application. I hope the web service
can run under the application account that is used to run the legacy
application
I think that what some people are saying is that you can have your data
that is used by a web server wherever you want it, while the actual
executaables can be in some "standard" location.
As I wrote before, it is not about the *location* of file.
That is an easy one to solve...

It is about who (what username) is running the server process.
Post by David Froble
While that actually sounds reasonable, I will admit that I too might have
first looked at placing the web server stuff with the application. But
after reading some posts, I think I agree with using the standard location.
Once again... It is *not* about the location of anything.
Craig A. Berry
2017-06-09 14:58:51 UTC
Permalink
Raw Message
Post by d***@gmail.com
My intention is to use web server to build a web service to be
consumed by other systems, an internal project, not a public facing
website. basically the web service is a wrapper for a legacy
application. I hope the web service can run under the application
account that is used to run the legacy application
With Apache this is typically done with suEXEC:

<https://httpd.apache.org/docs/2.4/suexec.html>

<https://en.wikipedia.org/wiki/SuEXEC>

Though I've never used it, for some reason I have the impression it's
implemented on VMS with persona services but I'm not sure about that.
There might be some clues about what to do in:

APACHE$COMMON:[000000]APACHE$MANAGE_SUEXEC.COM

or, if you're desperate enough, reading the docs:

<http://h41379.www4.hpe.com/openvms/products/ips/apache/csws_install_22.pdf>
Arne Vajhøj
2017-06-09 15:23:34 UTC
Permalink
Raw Message
Post by d***@gmail.com
My intention is to use web server to build a web service to be
consumed by other systems, an internal project, not a public facing
website. basically the web service is a wrapper for a legacy
application. I hope the web service can run under the application
account that is used to run the legacy application
Does it need to run as CGI script? Does the wrapper need to
be native code?

If not there may be easier ways to expose a web service.

Alpha or I64?

Arne
Stephen Hoffman
2017-06-09 20:01:31 UTC
Permalink
Raw Message
Post by d***@gmail.com
My intention is to use web server to build a web service to be consumed
by other systems, an internal project, not a public facing website.
basically the web service is a wrapper for a legacy application.
Ignoring that it's a really bad idea to assume a firewall is anything
other than a demarcation between parts of the network your organization
gets to fix and parts others get to fix — as Target and more than a few
others have learned, and as the ransomware and the rest will
undoubtedly follow —
Post by d***@gmail.com
I hope the web service can run under the application account that is
used to run the legacy application
Again, I'd not try to kludge this. There are fully supported ways to
provide the required access, and that can target the intended access
while blocking the unintended access. The easiest is via identifiers.
Grant the account used for the web server an identifier that allows
access to the required files and directories, or add an identifier to
the ACLs on the files and directories to allow access from the web user.

Better still and somewhat more involved than granting identifiers to
users or adding ACEs to ACLs is to grant access to executable images,
and not to specific usernames. What are called subsystem identifiers.
Move the core data files and related materials for the application
off into to a separate username — a username that the rest of the
universe does not have read or write access to — and enable and use
subsystem identifiers on the executable images the users and CGI
processes utilize that allows access. This also isolates the damage
that individual users can cause to what the executables can do. Well,
short of the users invoking privileges, or some other path into the
data files.

And in either case — and if this is like other legacy sites I've worked
with — using identifiers or using subsystem identifiers also avoids
granting the web server and all the worker processes the privileges and
quotas that many of these legacy usernames have tended to accrue.

Usual way is to add an identifier ACE and a default identifier ACE to
each file and directory, using a SET SECURITY command or equivalent.

Beyond the identifiers, there's often rather more that can be
simplified or better secured in these configurations, too.
Specifically around better locking down access to what is usually
critical data. But that's fodder for another discussion or three.

Again, the above requires no changes to the Apache environment, simply
that the files and directories that are to be accessed be identified
and tagged.

In short, I'd suggest moving forward from a 1970s- or 1980s-era
security model to one that's maybe somewhere in the 1990s, not trying
to convince Apache to run under a different username (and then
maintaining what might result over arbitrary upgrades), and this using
the discretionary access control features inherent in OpenVMS.
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Soderholm
2017-06-09 21:52:48 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Again, I'd not try to kludge this. There are fully supported ways to
provide the required access, and that can target the intended access while
blocking the unintended access. The easiest is via identifiers. Grant
the account used for the web server an identifier that allows access to the
required files and directories, or add an identifier to the ACLs on the
files and directories to allow access from the web user.
Better to only allow access when the process is running under a specific
application specific URL, then to allow the whole web server environment
the same access.

Can't SWS run processes under specified users based on the URL?

I do not know much about SWS, but in the case of WASD, the default
user running all CGI server processes ([HTTP$NOBODY]) has normaly
no access to anything. You have to configure (in the WASD$MAP file)
everything that has to do with "applications". Such as what username
should be running the server processes.
Post by Stephen Hoffman
also avoids
granting the web server and all the worker processes the privileges and
quotas that many of these legacy usernames have tended to accrue.
Of course you should not!
Post by Stephen Hoffman
In short, I'd suggest moving forward from a 1970s- or 1980s-era security
model to one that's maybe somewhere in the 1990s, not trying to convince
Apache to run under a different username...
Of course not. The core web server should run under a user with no
access to critical data at all. You then configure specific URL and
web server processes to run under suitable usernames that are right
for each application.

To be running under a "critical" username, you hav to use some
specific URL, and then you can only run the specific applications
that has been configured.

Or I must be missing some fundamential points here...
Maybe that SWS simply can't be setup for this?
Craig A. Berry
2017-06-09 23:25:44 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Can't SWS run processes under specified users based on the URL?
Of course. I already posted links to the details.

Loading...