[rescue] NeWS

[Charles Shannon Hendrix]

Thu, 02 Feb 2006 @ 15:48 -0600, Jonathan C. Patschke said:

> On Thu, 2 Feb 2006, Charles Shannon Hendrix wrote:
> 
> > Can you really blame a developer for using admin privs to work around
> > that kind of tech support nightmare?
> 
> Yes.
> 
> When their application starts up it can check for some sort of
> checkpoint flag in the Registry, and, if that flag is not present, the
> program can spawn some setup widget when it is first run.

For the scripting, I suppose that would work. It sounds right. A couple
of people I know said they do that.

But that's only one of many problems.

Parts of many installs involve bootup and user login triggers and
scripting, and from what I hear there is no way around that.

Also, installing software for multiple users... how can you do that as
an unpriveledged user?

On a UNIX system, I could install to an application directory that every
user could write to, and the installer could make sure everyone could
access it.

Should Windows start doing that?

Just curious: how does Mac OS X handle this sort of thing?

> That depends on what you mean by "standard user account".  In Windows
> 2000, I believe that typically meant being a member of the Power Users
> group, which means you can load some device drivers.  If you don't have
> permissions to load device drivers, you can't exploit this.  Typical
> users do NOT need permissions to load device drivers to do what they do.

True.

However, this guy did his magic with a non-priv account. All it needed
to be able to do was run a C compiler.

The C code used IPC to get through a hole, at least that was one method.
It would actually try several in case the system was patched against it.

Remember this guy's job was to find non-priv security holes.

> Windows has regedit.  Troll HKLM\System\CurrentControlSet\Services and
> HLMK\Software\Microsoft\Windows\CurrentVersion\Run* to find out what's
> getting loaded when.  Yes, drivers can obscure that, but VFS patches
> loaded into Unix can obscure configuration files and library files just
> as easily.

How are those VFS patches going to get loaded?

Sure, I could make my system able to do that, but it sure won't let you
do that right now.

I would have to specifically install any such thing as root and then
rebuild my boot blocks.

> > I can check just about everything on my UNIX boxes very quickly,
> > including checking for unwanted kernel bits.
> 
> Not if one of the drivers you loaded patches the loadable-module list so
> as to obscure itself.

But why would I load that?

It's not that hard to make sure a kernel and its configuration and
drivers are not modified without your permission.

> > So I recognize the potential for problems, but also see that it would
> > be a much different game than on Windows.
> 
> Administrator access is the same anywhere.  When you're -loading code
> into the kernel-, you have the power to change the rules.  

Yes, but that's analogous to logging in as administrator.  I'm not
talking about preventing "root" from doing bad things, because 
as currently designed systems don't do much about that.

I'm talking about within the context of an installer, which is what we
are really talking about.

Logging in as root or "administrator" is not the same as running an
installer that does nothing to limit what can be done during an install.

UNIX does not even have an installer. Right now we tell people to become
root and install an application, or get an admin to help them. That is a
problem, but not the same problem as the Windows install system.

The problem is a lack of demand for a user software installer, not an
inability to create one.

For that matter, Microsoft could probably create an installer that
didn't let anyone touch their kernel either, assuming the OS provides
the needed support.

I've deployed UNIX systems that let users intall software. It worked
great, and no one was able to do bad things because the installer simply
did not let them.

Even root could not modify the kernel or install applications outside
where they were supposed to be when using the installer.

Granted, root could bypass the installer and do bad things, but I'm
not talking about the actions of the unlimited user account.

Do you not see the difference?

I don't see any reason why a UNIX software installer, especially with
new developments like jails, could not be written to be fairly
bulletproof.

I think Microsoft could do a lot better too.



-- 
shannon "AT" widomaker.com -- ["Tara is grass, and behold how Troy lieth
low--And even the English, perchance their hour will come!"]