-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alan Altmark wrote:

>
> How many ways are there for two class G users to establish a
> communications path?
(snip)
>
> Are those two users authorized to establish such connections?

In our environment, yes.  If they weren't, we'd start by worrying about
the far easier to use from linux internet family of protocols, subnets,
routing, and such.

We don't run multiple security domains on the same LPAR.  We are also
not a DOD shop, or anything approaching that.

>
> Security by obscurity is a discredited practice.  If there be gold, there
> be pirates.  Avast!

Err, isn't security by obscurity the entire basis of secret passwords as
the primary user access mechanism?

Obscurity *is* a useful security mechanism, however, it just can't be
the *only* one.  Better make sure you still cover your bases via other
mechanisms.

> If Mayo IT security policy
> approaches the world differently, that's ok - I cannot gainsay it.

While neither Bob nor I work in our information security office, as
sysadmins, we have to implement security every day.  However, like
anything else, security is not an at all costs endevour.  Instead, it
has to be balanced against other considerations such as functionality,
cost, and convenience.

What Bob's fundamentally arguing for is a mechanism to grant access to
these objects (vswitches) in the cases where it makes sense.   In our
case, it does.

If we ever get to the point of running multiple vswitches for different
security domains, e.g. if we have DMZ and internal only guests on our
hosts, then many of these calculations change, as well as consideration
of other possible guest communication mechanisms.  Although at this
point I'd argue for separate LPARs.  In fact I'm ask for resources to
separate out our production and non-production guests into separate
LPARs right now.

We aren't there yet.  In our situation, and I have to imagine in other
people's as well, we have a much simpler proposition, and this
particular lack of feature can, has and does bite us.

>
> Are your backup tapes encrypted?

Are your employee's USB keys?  How 'bout their ipods?  What happens to
old computers?   Laptop's universally have encrypted drives?  Better
yet, are your USB keys locked in a restricted access facility with
access audit records?

In other words, let's not blow this out of context.

>
> But this is all rote for me and has to be kept in perspective.  If the
> guests don't have access to any sensitive data and can't get to any
> sensitive networks and don't control any critical processes, then it may
> not be worth worrying about and all you need to do is fix your
> provisioning process to include the needed authorizations.  Recall that
> DIRMAINT has exits.  Perhaps they can help you add the needed
> authorizations to the directory entries automatically.

Sure, and thanks for the hints.  It may be that we're one of few people
with this particular desire, in which case, ya, we're pretty much stuck
doing some form of home grown workaround.

As I mentioned earlier, though, I imagine that we're *not* the only
people with this circumstance.  If there are others in similar
situations (simple single security domain + no ESM), that's when grant
vswitch foo to public becomes useful.

- -- Pat

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ75SMNObCqA8uBswRAlWHAJ94ss3T1vb9xSwuY/9BdXtOeZsKCgCfbLYx
sQW/Av28F6ZQkVbv8DvK+mw=
=7I+D
-----END PGP SIGNATURE-----

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to