wineboot: Start items in StartUp folder on boot, includes security measures.

[richardvoigt at gmail.com]

On 2/12/07, James Hawkins <truiken at gmail.com> wrote:
> On 2/12/07, richardvoigt at gmail.com <richardvoigt at gmail.com> wrote:
> >
> > You advocated that wine aim for working exactly like Windows, no less
> > and no more, rather than deviating in user-configurable ways to
> > enhance the user's control over his own system.
> >
>
> Right.  That's the purpose of Wine.  You'd know that if you were a
> developer on this project.

You'll get there a lot faster by contributing to colinux
(www.colinux.org) instead.

>
> > Maybe while we're at
> > it, wine should have the bug which allows certain software to prevent
> > screen grabs.
> >
>
> I don't know of any apps that depend on this behavior, so that's not
> likely to happen.

Any DRM-enabled media player... which you would have understood if you
looked at my next comment!

>
> > No, I think defeating DRM to enable fair use is
> > perfectly reasonable, and there are some bugs which should be fixed.
> > Should wine try to patch remote exploits at the exact same rate as
> > windowsupdate.com?
> >
>
> Since we have completely different code bases, I don't see how we can
> fix their code in our tree.

You misunderstood me completely, I'm beginning to wonder if you're
doing so intentionally.

To maintain "bug for bug compatibility", then when an exploit is
discovered, wine won't be able to release a patch until after
Microsoft has done so, because to do so earlier would be to implement
functionality that doesn't match WIndows, breaking compatibility.

>
> > That would be also be required for true
> > bug-for-bug compatibility.  After all, someone properly authorized
> > might be using that backdoor to reboot their webfarm remotely -- not!
> >
> > There are things that are wrong in a theoretical sense (i.e. the
> > Pentium floating-point bug), or misclassification of Unicode
> > characters, which some programs might reasonably depend on.  And then
> > there are things that are wrong from a practical engineering
> > perspective, like software taking away the user's choice to not run
> > it, which the mere fact that a program depends on it makes it malware.
> >
>
> Are you a software engineer?  From a practical engineering
> perspective, adding this option adds unnecessary complication to the
> code base and increases the chances for bugs.  This is exactly what

I consider this sort of thing quite necessary, I would implement that
function on Windows if it was possible without totally replacing all
the security code (processing of Start menu/Programs/Startup and
HKLM/Software/.../Run can be turned off, but group policy start items
can't be disabled in any way that I'm aware of).

> UAC does, and no competent engineer thinks UAC is a good thing, or
> that it adds any amount of security.  This "malware" that you're so

UAC does add security, but the interface is horrid.  It's really the
same idea as Linux's don't-login-as-root, except that with linux you
don't necessarily have to use sudo and type a password for every
process you want to run elevated, there's suid, sudo remembers your
credentials for a short while, you can open an elevated shell, etc.  I
think UAC has some of the same capability between signed manifests in
place of suid and you can probably run an elevated shell there as
well.

> afraid of can just write over that registry entry.
>

I don't run Vista, but my understanding is that you can't permanently
approve a particular program to run elevated, the question reappears
every single time.  Giving the user a per-program "Remember my answer"
option improves the user experience so much it's not even comparable.

And I have never advocated for putting this in the registry, my
suggestion has always been to store these settings in a file outside
the .wine/drive_c jail area that is accessbile via wine's Win32 API.

> If this entry defaults to "Always" or "Never", then the users won't
> even know that the option exists, and that's one more piece of
> information that we'll have to broadcast and answer questions about.

So the best thing would be to set "Ask" as the installation default,
and in addition to the "Yes/No/Always/Never" buttons on the prompt,
provide a link to the winecfg page where the default is configured.

>
> > Reduced privileges do little or nothing to prevent network abuse (open
> > spam relay and the like).
> >
>
> If you're running executables that are going to add themselves to
> AutoStart, the fact that they might run again is the least of your
> concerns.

While I agree 100%, stopping the malware from running itself after a
reboot is still a very good thing.

How useful would chroot be if the chrooted programs could set up
autostart items or cron jobs without the admin's approval?  Not nearly
as much as it is now.