[rescue] NeWS

[Charles Shannon Hendrix]

Tue, 21 Feb 2006 @ 20:11 -0600, Jonathan C. Patschke said:

> On Tue, 21 Feb 2006, Charles Shannon Hendrix wrote:
> 
> > Parts of many installs involve bootup and user login triggers and
> > scripting, and from what I hear there is no way around that.
> 
> No, there really isn't; but that's also not the only way to solve the
> problem.  The application can, again, check a flag at first startup and
> perform self-installation.

According to developrs I've talked to, not everything can be done that
way.  I don't know, but at least some of the people I've talked to seem
pretty sharp.

Even Microsoft installers seem to need admin privs. At least, they
always fail for me if I don't have that.

> > Also, installing software for multiple users... how can you do that as
> > an unpriveledged user?
> 
> Members of the Power Users group typically have append access to the
> shared Start Menu folder and to C:\Program Files.

If it is append only, how do they remove a program, upgrade it, or
create common data areas?

Does Windows have a shadow user for common data?

> > 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.
> 
> Why would the application need write access to that directory after
> installation, especially by everyone?  

I didn't say anything about after installation. I'm talking specifically
about installation.

Data areas that are shared would be configured by the admin, and the
installer should be aware of that.

Like I said, UNIX has no installation system yet.

> Applications should just be able to deal with having write access to
> the user's profile root ONLY.

For storing a user's data, sure.

Good luck finding many that are like that though. Even some of the very
latest games still insist on saving user data in the master install
directory.

Even when you can be multi-user in Windows, app developers can't seem to
get out of single-user mindsets.

> > Just curious: how does Mac OS X handle this sort of thing?
> 
> sudo wrapped up in a GUI.
> 
> > 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.
> 
> Then this is a bug, not a design flaw.  I guess, by that logic, Unix
> systems were designed with an insecure API because there are buffer
> overflow exploits in libraries that setuid binaries sometimes use.

Yes it is a bug, but a bug caused by bad design. The design also makes
it hard to fix things.

Windows was never designed to be secure or multi-user, and attempts to
graft that on have been poorly done.

And yes, part of UNIX's problem is also bad design.  We learned a lot
since its basic parts were created.

Fortunately, people have done a better job fixing it and changing it
than they have with Windows.

But talk to an old mainframe or VMS guy sometime, and they'll be happy
to point out just how bad UNIX sucks.

> kldload, insmod, or your system's local equivalent?

Why would an installer system let those run?

> > Sure, I could make my system able to do that, but it sure won't let
> > you do that right now.
> 
> If you're running untrusted code as root (which is the equivalent of how
> most Windows users run things), I guarantee you that can happen.

Of course it can, which is why I'm not arguing that it can't.

The thread started out about things that happen when a Windows installer
runs.

> There is nothing magic about an installer on Windows.  It has to adhere
> to the same rules as anything else.  Yes, the Windows Installer service
> runs with elevated privileges, but it gates those privileges through the
> same ACLs that the rest of the system does.  When that "Run As..."
> dialog pops up after you start an installation, you're creating a
> security context as an administrator, which is the same as logging in,
> anything else that happens in the installer is something a user could do
> manually.

But the installer doesn't have to do anything that is requested of it.

What exactly forces the installer to modify a running kernel, or allow
any arbitrary thing to happen?

When you write programs that have root privs, do you write code in them
that let's a user or an anonymous script do anything?

Of course not.  You check what you've been given and only allow a
restricted set of things to happen.

-- 
shannon "AT" widomaker.com -- ["Consulting wouldn't be what it is today
without Microsoft Windows" -- Chris Pinkham]