| Hi Leo.
> Is there any plan to include B1 security features inside
> Digital UNIX 4.1 internals?
It's always been a goal to make "MLS+" be just a config option
of DU -- whether the work will ever be funded is another question.
Ask Phil Becker, GSG Marketing ([email protected]) and/or Kent
Ferson (VP UEG).
> If so, it would be possible to run any layered products without
> any changes (customizations) ?
I don't believe having B1 features built in to the current code
base (or even be customizable, or be a subset installed "on top"),
will guarantee that layered products would run without modification.
(Unless there is some very clever design going to take place.)
IOW, I think that what you have now with MLS+ is exactly what you
would have in the future, even if MLS+ functionality were built
"inside" of the current shipping version of DU: you will still have
some probability that layered products might require some tweaking.
(The advantage for having B1 features built-in to DU so has more to
do with being able to keep up with the latest hardware support, and
keeping up with latest fixes and patches, than with making the
interfaces to B1 features completely transparent.)
Another way of saying this is, that MLS+ *is* DIGITAL UNIX with the
B1 security features built in. (It also has additional security
features, i.e., more than B1, but that's another topic.)
What I think you mean to say is: why don't layered products always
work on MLS+ without any modifications?
The answer is: because no one made the layered products people
*make* their products work on MLS+. They know nothing about MLS+,
and their management is not asking them to worry about whether
their product runs on MLS+.
Here's why:
1. Layered products sometimes "cut corners". If they make
assumptions about data structures they may make themselves
incompatible. For example: B1 security means MAC labels;
MAC labels have to be stored somewhere; they are stored in
the inode/gnode/whatever, then if your application makes
assumptions about the structure of the inode/gnode/whatever
instead of using standard library calls to access that
structure, your code will not work on MLS+. And this cannot
be fixed unless the layered product fixes its code.
2. Sometimes layered products use features that are not "secure".
Example that came up recently: SoftWindows evidently for some
reason expects some file named "/var/opt/SWN200/sys.swn2config"
to have the suid bit set with owner root. This is not a
"secure" thing to do. By default, there are no files with
the suid bit set. But to make SoftWindows install, you can
"break security" by adding an entry in /etc/auth/system/files
for the above file to have f_mode be set at 04550 or whatever.
Another example: They may call setuid(0) to get root privileges
in their program. This is also not a "secure" thing to do,
according to B1 policy. Normally you can get around this
by giving the program a granted priv in /etc/auth/system/files,
but sometimes you cannot -- depending on what else they
are doing in their code.
> Is MLS+ the only planned way to support B1 features on Digital
> UNIX 4.X ?
So far, yes. But is that really what you are asking? Are you
really looking for a way to *know* whether a layered product
works on MLS+, or even a way to get layered products to work
on MLS+, that is completely (or relatively) painless?
We used to have some funding to do applications porting, but we do
not anymore. You should ask Phil Becker or Kent Ferson to see about
making that a business goal. In practical today terms, we'd need an
ECP or the equivalent, then we could do the work, e.g.,:
-- someone to verify whether layered products work on MLS+,
and if they do, what are the special installation
instructions they may need to work (e.g., how
to set up /usr/.smdb. files so it will install;
what to add to /etc/auth/system/files if it needs
granted privileges, or files with special modes, etc.)
-- someong to work with the layered product developers to
ensure that their product will be built to work on MLS+,
if it cannot be fiddled in the above manner.
For example, the Firewall product today ships modified DU
kernel files that it installs. Obviously, if they happen
to modify a DU kernel object that we also modify, we're going
to have a conflict. They should not be shipping modified
kernel objects -- they then saddle themselves with the same
problem we face: if a kernel patch for DU goes out to one of
the kernel modules they've modified, they have to port the
patch again and re-issue that module -- IOW a Firewall user
cannot install vanilla DU patches automatically, they may
break Firewall.
Firewall (just like MLS+) should be submitting to
the DU code pool. (But then who tests the combinations
of configuration options... that's another problem.)
|
| Just to add my 2p woth (how dare you discuss my favorite subject when
I'm on a customer site :-)
When DOVER wanted some of these products to be supported on MLS+, we
did the ECPs (an awful lot of paperwork, btw). The final mail
exchanges went along the lines of...
xxx_prod_mgr: If we make the changes to support MLS+, how many xxx
licenses will you sell.
DOVER_mgr: 2 (maybe 3 if we count the development system)
xxx_prod_mgr: Ha Ha Ha (paraphrased :-)
Another xxx_prd_mgr quoted something like $100k to investigate what it
would cost to support MLS+. This was without actually doing the work
that may have been required!
IMHO, the direction will have to come from above to get LPs to
supportt MLS+ - there is not enough money for each LP to be able to
justify this.
Jc
|
| Flame ON:
Creak creak... In the old days, the sales district managers would
roll up their "out of band" experiences, observations and predictions
into the "District Managers' Report", which would keep the top brass
informed and forewarned about field trends.
I do not know what the mechanism is, if any such exists, for rolling up
market trends and requirements across districts.
DU product management is not interested in supporting B1 security
related projects because the license count is miniscule. They have
asked GSG in the past to come up with numbers, and GSG has failed to do
so. GSG just have a "notion" that collateral sales would be lost if DEC
does not offer a B1 product.
There appears to be is no mechanism, out of band or otherwise, for
accounting for the impact of leverage products. If GSG's "notion" is
correct, then unless this "accounting flaw" is fixed, those whose noses
can sniff out only the next meal, are going to ensure that there isn't
a meal after that.
What comes after B1? Will the military arrive at some new definitions
for 'secure' systems? No one knows. That sort of research is not
funded either. "Walking backwards into the future": our new corporate
slogan.
Flame off.
|
| Hi Leo,
No, there isn't any current plan to add B1 features to DU kernal, although,
as Barb says, it was in the security group's long term vision.
Interesting to note that Data General has a single UNIX product which can be
configured for C2 features, enhanced C2 features that they call "C3", B1
features, and even B2. Data General does not have a full featured secure
window system, however and one could point out that al B2ness is suspect at
the users window.
One problem is that if more security features were added to the base product,
the company would lose the ability to price it differently. In the grand
scheme of product management, one would unify the product only if the overall
return would increase against the overall cost. That is not the case at
this time for a B1 UNIX product, it seems. There is a lot of pressure on the
cost of UNIX because of the lower cost NT. I think Data General got to a
unified product because they designed it from scratch that way. They may
also have some license tiers that Digtial doesn't use in the UNIX license
process.
Sun, HP, and SCO do not have unified products.
On to your other question, why is it so hard to get products ported to MLS+?
I can't add anything to the technical answer Barb gave. We in the US
FGR sales region have long complained about the problem, too. We have paid
for ports when a customer required them, and we partner with some integrators
to get products ported, too, examples, Trusted Computer Solutions, Computer
Sciences.
The UK MOD team complains about the same thing, but they have had good
success with the product in Europe and pay for their own ports. You are
welcome to contact Mike Tierney in the UK and share frustrations.
The simple fact is that there is no money in UEG for this work. We'll have
to do it on our own, or submit an ECP.
As I told you in my previous response, a successful ECP takes the local sales
region's commitment to the customer problem and faith that the business will
close profitably.
|