Hi James, > I don't think that's off-topic at all.
Well - I mean OT, since it is not especially related to the /lib/svc/method flaw ... > In fact, I > think it's the crux > of the argument you're trying to make: that the pkg* > tools are a > better way to enable or disable software than any > tool (such as > svcadm) that's designed for enabling or disabling > software features. Well, not really. Why should I install all software/services available on earth? Just because I might be able to use svcadm to enable/disable it? Why should I install poorly crafted/outdated SUN packages, if there are other, much better replacements, which satisfy customer/admin needs? Just because I might be able to use svcadm to disable it? E.g. the SUNsendm* packages might be ok for "dumb" clients/zones (just neglecting the bad patch behavior of overwriting modified *.cf unconditionally), which use it to just relay the mail to a central hub. But it causes more problems than it solves on mail gateways/hubs, where uptodate functionality is required and the software can be enhanced by other contrib software without getting into big problems (e.g. because the ancient and thus unsupported version of the SUNW* software) ... Or even more concret: Why should I install StarOffice7? Just because it is bundled with Sol10? Why should I waste gigabytes of space and a lot of time (wrt patching), when nobody needs this outdated software (remember _each_ update of it requires about 250 MB /var/sadm/pkg + the space for downloading the patches, which usually go into /var as well). > I disagree. Besides the uneasy problems of > inaccurate and missing > package dependencies[1] and patch havoc[2], the core > issue is that > removing the software doesn't remove the security > risk. Hmmm - depends. In case of suid/sgid progs removing the binaries definetely removes the risk. Having a software not installed, may definitely lower the risk: Usually maleware authors expect certain software to be available - if it is not there, they do not care, because rewriting the rookit to download everything what is needed, just requires to much time and effort ... Looking at Windooze: there are much more targets, which usually have the software installed, so there is no need to modify the kiddy tools. > As long as > users are still able to create files and set the > execute permission > bits, users can recreate those applications whenever > they want. Yes, but who says, that they always can do that? And who says, that even if they can do that, that they are able to bring the system into an unstable/unusable state or even effect other users environment ? > It's at best security-by-obscurity. No, that's IMHO a completely different thing! E.g. like no or bad documentation (cssd comes into my mind) or unknown [config] file [format]s, creating a file and unlink it,while it is still beeing used (e.g. vmware), etc. > If the real concern here is security, then I would > suggest limiting > the privileges(5) granted to users, roles, and > subsystems such that > they just _can't_ do the things you don't want them > doing. Well, actually the concern of the original posting in smf(5) were poorly crafted packages especially wrt. /lib/svc/method. Anyway, thanks for the hint. If I'm getting paranoid and find the time to study it, I'll definitely try it out (and let some users getting headaches ;-)). > If the real concern is that Sun ships a few programs > that are setuid > or setgid, then you should address that concern with > your support > folks. Sun has extensive security tools and > practices in this area > that are designed to limit the number of such > applications and to > review and audit the ones that are. Yes, but even if SUN does, what it can, it doesn't say, that a software is secure. May be one can proof, that a program does what is expected, if it is written in Z. But I doubt, that any usable software is written in Z ;-) and even if so, still the question is, whether the compiler/interpreter does the right thing with the [source] code ... > (Neither xterm nor sendmail are setuid, though > sendmail is setgid to > its own separate group. Hmmm - example is the keyword here. In S10 it got changed, but I think, I can still remember to advisories, which explictly gave the advice to disable the suid bit of xterm and several security advisories wrt. sendmail and sticky bits as well. Yes, those well known problems are fixed today, but: > I'm not sure what the "who > knows" part refers > to; it's not as if Sun ever takes a "who knows" > approach to security > in any software it ships.) Well, as already said, it doesn't matter, whether SUN or a well known security company or anybody else takes any measures to discover security holes. The point is, that it is quite questionable, that any machine or human beeing is able to absolutely guarantee, that a program always does, what it should. A little compiler/interpreter bug is the simplest thing, what might be happen, lead/hide a problem... (Not sure, what gdm version was shipped with the initial Sol10 or right now, but it might have [had] such a problem (i.e. uninitialized referred vars -> SEGV ... bla bla bla)). So the "who knows" refers to "nobody/nothing is perfect". > Also, don't forget that other solutions (such as > Domains, LDoms and > Xen) may be more appropriate for some situations. > That's why there's > ore than one solution in this space. May be, but which one is supported for production environents? > As for the experience issue, I don't think it's > entirely safe to > assume that those suggesting the use of 'svcadm' are > just > inexperienced. I didn't, did you ? > 1. Core Solaris software tends not to have a > complete list of > dependencies in the packaging database. Instead, > testing relies > on the supported metaclusters (reduced networking, > core, user, > developer, entire distribution). If you add or > remove packages, > you have to be very careful to get the > dependencies right. Well, nobody expects to get/include all dependencies a software might have, since sometimes it isn't a trivial task. However, IMHO the cause of this SUN homegrown problem is package separation. I.e. mixing the content of several "standalone" software packages into one "logical" package, e.g. SUNWcsr, SUNWman, SUNWgnome-libs or on the other hand splits it into "doesn't make sense anymore" packages (e.g.the thousands of locale packages). "doesn't make sense" is: wrt. big HDDs today, it doesn't simply make sense to split message catalogs anymore (beside the time it takes for reviews etc.). Providing add. packages e.g. for japanese/ chines fonts/X support is a different story. I think, every Linux distributor did that "logical" mixing in its early days but soon they discovered, that this introduces much more problems, than it might superficially solve. AFAIK today no Linux vendor builds "mixed" packages anymore (wondering why SUN hasn't learned this lecture yet). So building a software, elfdump -d its binaries/libs and grab the libs in the pkgmap collection of already build packages can be easily done and thus, one gets at least the essential deps w/o a lot of headaches. BTW: This way I'm building packages for Linux for about 8 years [and now for Solaris again] on demand (without doc pkgs theses are now ~ 400) and never had a real problem with it... > 2. Patch havoc can occur when you remove a package, > patch the system, > and then later realize that you need to add a > removed or new > package to the system -- because, for example, > some user has a > legitimate need for one of the applications that > were excluded. > The patching system skips over packages that are > not present at > the time the patch is applied. It doesn't > "remember" what changes > it would have made if the package had been > present. If you later > install a package, that newly-added package won't > have the same > patches as applied elsewhere on the system, > leading to > inconsistent operation or just plain failure. Also a SUN homegrown problem. packages have usually a version/revision number and if one does a smpatch analyze it would be easy to say, what patch needs to be applied... > The only safe thing to do is to back out every > patch that applied > to the package in question, add the package, and > then reapply all > of the patches. No wonder, why Solaris can't get into SME market ... Regards, jens. This message posted from opensolaris.org
