tchrist@convex.COM (Tom Christiansen) (03/14/91)
From the keyboard of jfh@rpp386.cactus.org (John F Haugh II):
:In article <1991Mar13.042033.12450@convex.com> tchrist@convex.COM (Tom Christiansen) writes:
:>I maintain that both "auth" and "sysadmin" give you indirect
:>root privileges. With auth, you can create accounts or modify
:>existing ones. With sysadmin, you can mount arbitrary things
:>at arbitrary points, do dumps and restores etc.
:
:Consider, just as an example, that I could implement the
:"mount" system call in such a way that any privileged commands
:on that volume wouldn't be treated as privileged until a
:privileged system utility had verified that the volume was
:in an acceptable state. So "sysadmin" lets you mount some
:disk - big deal. Perhaps "sysadmin" also lets you crash
:the machine by unmounting critical volumes or over-mounting
:others. A quick look at the audit logs will reveal what
:happened.
Audit logs can be altered once you are powerful enough. And
it's important to stop it from happening in the first place.
:SecureWare, not being a formally evaluated product, probably
:has =many= little holes, and if this is one of them, point
:out how I can become "auth" with just access to "sysadmin"
:and then we can sit back and have a good laugh at SecureWare.
I'm not here to have a good laugh at anybody, including SecureWare. I
just want to point out that the C2 security stuff I've seen applied to
UNIX has some fundamental problems in its approach. Breaking up the
superuser into small compartments that each do a few very powerful things
isn't enough if you're not very very very very careful. I haven't yet
seen any that are that careful.
Let's take a "sysadmin" user, who has the privs to do dumps, restores, and
mounts. Each of these is quite powerful. The dumps allow me to see any
data on the system. The restores allow me to create or overwrite any
file on the system, including the whole TCB and authorization database.
Being able to run mount allows me to patch in my own version of /etc or
whatever I want.
If you work very very hard to patch up problems like this, you might be
able to convince me that "syadmin" is not as powerful as the old
superuser, but so far I haven't seen an implementation that did so.
--tombrnstnd@kramden.acf.nyu.edu (Dan Bernstein) (03/14/91)
In article <1991Mar13.185609.21132@convex.com> tchrist@convex.COM (Tom Christiansen) writes: > From the keyboard of jfh@rpp386.cactus.org (John F Haugh II): > :In article <1991Mar13.042033.12450@convex.com> tchrist@convex.COM (Tom Christiansen) writes: > :>I maintain that both "auth" and "sysadmin" give you indirect > :>root privileges. Undoubtedly you would stop complaining if ``auth'' were named ``root-auth'' and ``sysadmin'' were named ``root-sysadmin''. > :Perhaps "sysadmin" also lets you crash > :the machine by unmounting critical volumes or over-mounting > :others. A quick look at the audit logs will reveal what > :happened. > Audit logs can be altered once you are powerful enough. And > it's important to stop it from happening in the first place. The situation is no worse than the situation where ``sysadmin'' equals ``root'' to begin with. The way UNIX is typically used, you have about three levels of users: root, independent ``system'' uids and gids, and normal users. If you have an operation that uses root privileges but you can downgrade it to a system uid or gid, you make it at least nominally more difficult to break root, and you reduce the chance that a bug in one program will bring down the entire system. Yes, people have to be just as careful with the system uids as with root. So what? It's no worse than the previous situation, where you'd need to be root for everything. I think it would be better for all the system uids to fall within a special namespace or uid-space. That way it would be hard not to notice that you're dealing with a system uid. But the concept of having more structure than ``root'' and ``everyone else'' is inherently sound in any case. ---Dan
tchrist@convex.COM (Tom Christiansen) (03/14/91)
From the keyboard of brnstnd@kramden.acf.nyu.edu (Dan Bernstein): :In article <1991Mar13.185609.21132@convex.com> tchrist@convex.COM (Tom Christiansen) writes: :> From the keyboard of jfh@rpp386.cactus.org (John F Haugh II): :> :In article <1991Mar13.042033.12450@convex.com> tchrist@convex.COM (Tom Christiansen) writes: :> :>I maintain that both "auth" and "sysadmin" give you indirect :> :>root privileges. : :Undoubtedly you would stop complaining if ``auth'' were named :``root-auth'' and ``sysadmin'' were named ``root-sysadmin''. No, I don't think I would. The C2 folks seem to think a system is more secure this way, but I see it as having N accounts to try to find holes into rather than just one. This makes it easier for the cracker. :> :Perhaps "sysadmin" also lets you crash :> :the machine by unmounting critical volumes or over-mounting :> :others. A quick look at the audit logs will reveal what :> :happened. :> Audit logs can be altered once you are powerful enough. And :> it's important to stop it from happening in the first place. : :The situation is no worse than the situation where ``sysadmin'' equals :``root'' to begin with. Except for that people think it's more secure when it's not. --tom
jfh@rpp386.cactus.org (John F Haugh II) (03/14/91)
In article <1991Mar13.185609.21132@convex.com> tchrist@convex.COM (Tom Christiansen) writes: >I'm not here to have a good laugh at anybody, including SecureWare. I >just want to point out that the C2 security stuff I've seen applied to >UNIX has some fundamental problems in its approach. Breaking up the >superuser into small compartments that each do a few very powerful things >isn't enough if you're not very very very very careful. I haven't yet >seen any that are that careful. Well, I think it is very important to expose fraud whereever it is found. Part of the concept behind the TCSEC and the NCSC is that we trust the NCSC to properly apply the criteria described in the TCSEC so that the criteria have some meaning. What companies such as SecureWare are doing is to take a meaningful collection of criteria and announce, without proof, that they adhere to these well defined criteria. Naive users do not fully understand what the difference between a "rated" and an "unrated" system are - there are very real differences and SecureWare is clouding them up. Notice how quiet SecureWare is? They =are= on the net, and yet they do not get engaged in this discussion because their behavior is =unethical=. The mistake was on the part of the NCSC. Just as the Motion Picture Assoc. should have "trademarked" or whatever the "X" rating, so should the NCSC have "trademarked" the "C2" rating. To continue with the real topic, "C2" is not that "secure" of a rating. If you expect the system to warn you of auditable events which might indicate a violation of the security policy you have to go to a higher level. The only rating level between "C2" and MS-DOS is "C1". There are still 3 "B" levels and an "A" level above "C2". The description of "C2" is "Systems in this class enforce a more finely grained discretionary access control than (C1) systems, making users individually accountable for their actions through login procedures, auditing of security- relevant events, and resource isolation." What you are expecting "C2" to do isn't even a part of "C2". You probably want "B2" or possibly "B3". As long as the system audits everything the "auth" or "sysadmin" user is doing, including that they turned off auditing or whatever, it has fulfilled the "C2" criteria. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "I've never written a device driver, but I have written a device driver manual" -- Robert Hartman, IDE Corp.
sef@kithrup.COM (Sean Eric Fagan) (03/15/91)
In article <19104@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >Naive users do not >fully understand what the difference between a "rated" and an >"unrated" system are - there are very real differences and >SecureWare is clouding them up. Uhm, SecureWare got at least one of their products rated. Again, just something I seem to recall reading somewhere (probably, again, InfoWorld, although it might have been ComputerWorld [magazines people send to me for free]). Wish I could remember. But I think it was a B-level. You can't blame SW or SCO for not getting the C2 product evaluated: the gov't isn't going to rate C level products anymore, I've been told, because it's not worth the effort! >Notice how quiet SecureWare is? >They =are= on the net, and yet they do not get engaged in this >discussion because their behavior is =unethical=. Or because they're busy. Do you know what the word "slander" mean, John? Lots of people at *any* company don't post to the net, either out of lack of time or interest. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
wcs) (03/17/91)
In article <19104@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > Naive users do not fully understand what the difference between a "rated" > and an "unrated" system are - there are very real differences and One of the major differences is that the NCSC doesn't really have the resources to formally evaluate every product that wants it - you've got to have something new and interesting to offer, and be willing to wait about 1.5 - 2 years AFTER convincing them to bother with you, and evaluation is for specific hardware configurations as well as software. Most of the market is satisfied with C2 functionality, and doesn't really need the NSA Good Housekeeping Seal. This is especially important, since adding networking affects your Trusted Computing Base, and throws you out into uncharted Red Book territory, even at C2 level. Most customers would really rather have networking now, hopefully with the bigger holes patched, rather than wait until the general research problem is solved well enough for the NCSC to certify systems. (Remember that even Verdix is just a "component", not a complete system.) > To continue with the real topic, "C2" is not that "secure" of > a rating. If you expect the system to warn you of auditable > events which might indicate a violation of the security policy > you have to go to a higher level. The only rating level between > "C2" and MS-DOS is "C1". There are still 3 "B" levels and an > "A" level above "C2". The description of "C2" is [ C1 + Good Auditing/Accountability + Object Reuse prevention ] Well, there's also D level; the TCSEC definition says: Level D: Thank you for sharing that. :-) All of the levels add increasing amounts of assurance. The interesting additions at B1 are Mandatory Access Control - you get the equivalent of "Unclassified/Secret/TopSecret", with system enforcement so users can't just give stuff away. If you trust your users, or don't trust your superuser, this doesn't buy you much extra, though you can gain some significant protection by giving the system software and audit trails their own classification levels, which regular users (or bugs) can't touch. B2 adds Trusted Path, Covert Channel Analysis, and Least Privilege, and starts to feel less like Real Unix, because you don't really have One All-Powerful Root any more. Covert channel analysis is a real problem - something that was adequate protection on a 1 MIPS box may not do the job on a 200 MIPS multi-processor with a 500 MFLOPS add-on vector board. -- Pray for peace; Bill # Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ # Hacker. System Designer. Troublemaker.
karl@ficc.ferranti.com (Karl Lehenbauer) (03/18/91)
In article <1991Mar14.022920.19647@convex.com> tchrist@convex.COM (Tom Christiansen) writes: >... The C2 folks seem to think a system is >more secure this way, but I see it as having N accounts to try to >find holes into rather than just one. This makes it easier for >the cracker. Yeah, too, most Unix systems are small enough that they only have one or two administrators anyway, so for small sites, having lots of different signons with different permissions is simply an inconvenience to the one person who does all the admin stuff anyway. -- -- "If it ain't too broke, don't fix it." -- me, with apologies to Bert Lantz Save Twin Peaks!!
faigin@aerospace.aero.org (Daniel P. Faigin) (03/18/91)
In article <1991Mar17.060540.3911@cbnewsh.att.com>, wcs@cbnewsh.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs) writes: > Most of the market is satisfied with C2 functionality, and doesn't > really need the NSA Good Housekeeping Seal. Correction. Most of the COMMERCIAL market. The ratings are there to help the DoD side of things. This goes along with the Agency's charter. If it ever gets the budget, the commercial side will probably be happer with NIST. > This is especially important, since adding networking affects your Trusted > Computing Base, and throws you out into uncharted Red Book territory, even > at C2 level. I wouldn't say the TNI (red book) is uncharted. It is a different way of thinking. It is charted, as there are evaluations working against it. > Most customers would really rather have networking now, hopefully with the > bigger holes patched, rather than wait until the general research problem is > solved well enough for the NCSC to certify systems. The NCSC does not certify systems. That is up to the accrediting agency that determines that the residual risk for a particular system in a particular installation is acceptable. The NCSC only rates systems. As for networks, yes, it is a problem that many systems on the EPL do not support real-life configurations. Vendors also have to accept a risk when they go into "uncharted territory". If systems don't get submitted in real-life configurations, they don't get evaluated in real-life configurations. What happens in real-life is that the accreditor must look at the changes to the system from the EPL configuration, and decide that the risk is acceptable. For this to be "a good thing", the accreditor must be given (and be capable of understanding) the nuances of the additional information. > B2 adds Trusted Path, Covert Channel Analysis, and Least Privilege, and > starts to feel less like Real Unix, because you don't really have One > All-Powerful Root any more. More importantly for Unix, B2 adds requirements in the area of system architecture that make it difficult, if not impossible, for retrofitted Unix systems. Daniel -- [W]:The Aerospace Corp. M1/055 * POB 92957 * LA, CA 90009-2957 * 213/336-8228 [Email]:faigin@aerospace.aero.org [Vmail]:213/336-5454 Box#3149 "A consensus means that everyone agrees to say collectively what no one believes individually" -- Abba Eban
faigin@aerospace.aero.org (Daniel P. Faigin) (03/19/91)
In article <19104@rpp386.cactus.org>, jfh@rpp386.cactus.org (John F Haugh II) writes: > In article <1991Mar13.185609.21132@convex.com> tchrist@convex.COM (Tom Christiansen) writes: >>I'm not here to have a good laugh at anybody, including SecureWare. I >>just want to point out that the C2 security stuff I've seen applied to >>UNIX has some fundamental problems in its approach. Breaking up the >>superuser into small compartments that each do a few very powerful things >>isn't enough if you're not very very very very careful. I haven't yet >>seen any that are that careful. First of all, it should be noted that when a system is accredited (this is different than rating a system), computer security such as that provided by a rating is only one of many security disciplines. Other disciplines include personnel and physical security, as well as procuedural security. For example, it is assumed that, before given an account privileges, you have ensured that the user of that account is trustworthy. > Well, I think it is very important to expose fraud whereever it is found. > Part of the concept behind the TCSEC and the NCSC is that we trust the NCSC > to properly apply the criteria described in the TCSEC so that the criteria > have some meaning. First of all, note that the NCSC (actually, the TPEP portion of NCSC's parent) does not apply the criteria. They evaluate how well a system meets the criteria. It is up to the vendor to apply the criteria. > What companies such as SecureWare are doing is to take a meaningful > collection of criteria and announce, without proof, that they adhere to > these well defined criteria. Naive users do not fully understand what the > difference between a "rated" and an "unrated" system are - there are very > real differences and SecureWare is clouding them up. A rated system is one that has been evaluted by the NCSC (so to speak). An unrated system is one that has obtains its rating, to coin a Steve Walker phrase, by emphatic assertion. > The mistake was on the part of the NCSC. Just as the Motion Picture Assoc. > should have "trademarked" or whatever the "X" rating, so should the NCSC > have "trademarked" the "C2" rating. I do agree with you on this one. It annoys me when I see vendors "claiming" to have a rating, when they are unevaluated. It cheapens the evaluation work that I do. > To continue with the real topic, "C2" is not that "secure" of a rating. No rating is "secure". They are "trust" levels, based on features and assurances. The "secure"-ness of a system is a result of all security disciplines. > If you expect the system to warn you of auditable events which might > indicate a violation of the security policy you have to go to a higher > level. The only rating level between "C2" and MS-DOS is "C1". MS-DOS has never been rated. > As long as the system audits everything the "auth" or "sysadmin" user is > doing, including that they turned off auditing or whatever, it has fulfilled > the "C2" criteria. And if you can't trust the trusted user, well, you get what you deserve... Daniel -- [W]:The Aerospace Corp. M1/055 * POB 92957 * LA, CA 90009-2957 * 213/336-8228 [Email]:faigin@aerospace.aero.org [Vmail]:213/336-5454 Box#3149 "A consensus means that everyone agrees to say collectively what no one believes individually" -- Abba Eban
jfh@rpp386.cactus.org (John F Haugh II) (03/19/91)
In article <FAIGIN.91Mar18121748@sunstroke.aerospace.aero.org> faigin@aerospace.aero.org (Daniel P. Faigin) writes: >In article <1991Mar17.060540.3911@cbnewsh.att.com>, wcs@cbnewsh.att.com (Bill >Stewart 908-949-0705 erebus.att.com!wcs) writes: > >> Most of the market is satisfied with C2 functionality, and doesn't >> really need the NSA Good Housekeeping Seal. > >Correction. Most of the COMMERCIAL market. The ratings are there to help the >DoD side of things. This goes along with the Agency's charter. If it ever gets >the budget, the commercial side will probably be happer with NIST. I tend to think that there are features above the C2 level that are interesting in a commercial environment that would be beneficial if they could be extracted from the remainder of the B1/B2 requirements. Particularly, MAC and Least Privilege. MAC is extremenly important if information is to be protected - trojan horses can depend on DAC to permit exporting information, but MAC prevents any unintentional downgrading of information. Thus, management data is protected from programs gone awry. It doesn't have to be "full-blown" MAC, with all the requirements - just the basic concepts of subject and object dominance. I should be able to downgrade my own information so long as I am on the trusted path. [ Guess that means I need "trusted path" too, eh? ] Least privilege is in there because it's just a good idea and allows operators to be given just enough authority to get their jobs done. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "I've never written a device driver, but I have written a device driver manual" -- Robert Hartman, IDE Corp.
slamont@network.ucsd.edu (Steve Lamont) (03/20/91)
Uh... can someone *please* tell me what all of this blather has to do with *sources* or the discussion thereof? spl (the p stands for probably some source code involved somwehere...) -- Steve Lamont, SciViGuy -- (408) 646-2752 -- a guest at network.ucsd.edu -- NPS Confuser Center / Code 51 / Naval Postgraduate School / Monterey, CA 93943 "The only way to deal with exploiters is to terrorize the bastards." - The late Congressmember Phillip Burton
faigin@aerospace.aero.org (Daniel P. Faigin) (03/20/91)
In article <19115@rpp386.cactus.org>, jfh@rpp386.cactus.org (John F Haugh II) writes: > I tend to think that there are features above the C2 level that are > interesting in a commercial environment that would be beneficial if they > could be extracted from the remainder of the B1/B2 requirements. I think you are right. If you look at how the Canadians and Europeans have structured their criteria, you will see that features have been unbundled from assurances. > Particularly, MAC and Least Privilege. MAC is extremenly important if > information is to be protected - trojan horses can depend on DAC to permit > exporting information, but MAC prevents any unintentional downgrading of > information. Thus, management data is protected from programs gone awry. This is the critical point. I believe that once commercial companies realize the advantages of using trusted systems to protect disclosure of company proprietary, company private, and corporate secrets -- either through hierarchical levels or compartments, then the use of trusted systems in the "B" division will take off. However, the commercial side is very concerned with one aspect not addressed by the normal TCSEC, Bell-LaPadula policy -- integrity and protection of data from modification. This needs to be adequately addressed. > It doesn't have to be "full-blown" MAC, with all the requirements - just the > basic concepts of subject and object dominance. Um, what features of the *functionality* of the MAC requirements don't you need. Not that much functionality is added after B1. > I should be able to downgrade my own information so long as I am on the > trusted path. [ Guess that means I need "trusted path" too, eh? ] Not necessarily. If you were truly untrusted, how can I have assurance that what you are downgrading really should be downgraded (i.e., that you're not downgrading it just to leak it). Now, if I trust you to downgrade, I could always grant you a privilege. Funny, that's allowed under the TCSEC. > Least privilege is in there because it's just a good idea and allows > operators to be given just enough authority to get their jobs done. Yes. Note that it is contradictory to the typical Unix "root" philosophy. What the higher ratings buy you is increased assurance. Well structured kernels, reference monitors, formal verification. All of this is important if you are to be sure your system does what it will say it will do. Not that much of an increase in functionality, tho. Daniel -- [W]:The Aerospace Corp. M1/055 * POB 92957 * LA, CA 90009-2957 * 213/336-8228 [Email]:faigin@aerospace.aero.org [Vmail]:213/336-5454 Box#3149 "A consensus means that everyone agrees to say collectively what no one believes individually" -- Abba Eban