[rescue] NeWS

[Jonathan C. Patschke]

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.

> 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.

> 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?  The programs that need that sort
of access (perhaps shared use of a JET database, pun not intended) are
few and far between.  Applications should just be able to deal with
having write access to the user's profile root ONLY.

> 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.

>> 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?

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

> 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.

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

No you wouldn't.  Code loaded into the kernel at runtime can do any
sort of thing it pleases, including patching routines into the VFS layer
to hide files or make phantom files appear.  It's just a big block of
machine code; you can inject jumps anywhere you want.

>> 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.

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.

-- 
Jonathan Patschke    )   "Pain and misery always hit the spot,
Elgin, TX           (     knowing you can't lose what you haven't got."
USA                  )                         --Depeche Mode, "Lilian"