On Friday 01 Nov 2002 11:51 am, Vincent Béron wrote:
> Le ven 01/11/2002 à 11:27, Geoff Thorpe a écrit :
> > Hi there,
>
> [snip]
>
> > > What do you mean? No PE apps can link straight to glibc. Only
> > > Unix-implemented DLLs (like the Wine ones) can link to it. The
> > > problem
> >
> > Ah, this
Le ven 01/11/2002 à 11:27, Geoff Thorpe a écrit :
> Hi there,
>
[snip]
> > What do you mean? No PE apps can link straight to glibc. Only
> > Unix-implemented DLLs (like the Wine ones) can link to it. The problem
>
> Ah, this had been my question. It seemed otherwise from the earlier post
> I had
Hi there,
On Friday 01 Nov 2002 8:23 am, Ove Kaaven wrote:
> On Thu, 31 Oct 2002, Geoff Thorpe wrote:
> > However, that still *requires* that the wineserver is actually doing
> > all the work and the wine processes that load and link PE images are
> > doing very little except marshalling the win32
On Thu, 31 Oct 2002, Geoff Thorpe wrote:
> However, that still *requires* that the wineserver is actually doing all
> the work and the wine processes that load and link PE images are doing
> very little except marshalling the win32 API back and forth to the
> wineserver. I'm not convinced that's
Hi there,
On Thursday 31 Oct 2002 2:21 pm, David Fraser wrote:
> I think this is missing the point.
No, I think you're stuck on a point that wine is simply destined (ie. as
in "fate") to miss on both our behalves. I'm talking about a different
point where some useful headway could be made.
> The
Greg Turner <[EMAIL PROTECTED]> wrote:
>On Thursday 31 October 2002 08:10 am, Raul Dias wrote:
>> My $0.02,
>>
>> A way to make it more secure is to catch key API calls and decide if
>> the application is allowed to run it or not.
>
>not a bad idea.
>
>> Wine could implement a clean Security Layer:
Geoff Thorpe wrote:
On Thursday 31 Oct 2002 10:00 am, Greg Turner wrote:
On Thursday 31 October 2002 08:10 am, Raul Dias wrote:
My $0.02,
A way to make it more secure is to catch key API calls and decide if
the application is allowed to run it or not.
not a bad idea.
Wine co
On Thursday 31 Oct 2002 10:00 am, Greg Turner wrote:
> On Thursday 31 October 2002 08:10 am, Raul Dias wrote:
> > My $0.02,
> >
> > A way to make it more secure is to catch key API calls and decide if
> > the application is allowed to run it or not.
>
> not a bad idea.
>
> > Wine could implement a
Marcus Meissner wrote:
On Thu, Oct 31, 2002 at 11:10:33AM -0300, Raul Dias wrote:
My $0.02,
I always though of a wine as way to run windows apps
better than windows.
Better also means "more secure" for me.
A way to make it more secure is to catch key API calls and decide if
the application i
On Thu, Oct 31, 2002 at 11:10:33AM -0300, Raul Dias wrote:
> My $0.02,
>
> I always though of a wine as way to run windows apps
> better than windows.
>
> Better also means "more secure" for me.
>
> A way to make it more secure is to catch key API calls and decide if
> the application is allowe
On Thursday 31 October 2002 08:10 am, Raul Dias wrote:
> My $0.02,
>
> A way to make it more secure is to catch key API calls and decide if
> the application is allowed to run it or not.
not a bad idea.
> Wine could implement a clean Security Layer: YES
Clean, perhaps, but secure? That depends
My $0.02,
I always though of a wine as way to run windows apps
better than windows.
Better also means "more secure" for me.
A way to make it more secure is to catch key API calls and decide if
the application is allowed to run it or not.
This would be easy to detect if an application is trying
On Mon, 28 Oct 2002, Francois Gouget wrote:
> On Sun, 27 Oct 2002, Peter Andersson wrote:
> [...]
> > I agree. Using chroot could offer the functionality Im looking for.
>
> I also saw this today on kernel-traffic. It looks pretty much like what
> you are looking for:
>
> * Linux Security Protect
On Sun, 27 Oct 2002, Peter Andersson wrote:
[...]
> I agree. Using chroot could offer the functionality Im looking for.
I also saw this today on kernel-traffic. It looks pretty much like what
you are looking for:
* Linux Security Protection System
http://www.uwsg.indiana.edu/hypermail/linux/k
On Sunday 27 October 2002 22.19, Francois Gouget wrote:
> On Sun, 27 Oct 2002, Peter Andersson wrote:
> > What is it with you people?
> > I was just trying to make a point about the security risks about using
> > wine at present. And you start flameing me?
>
> We're not flaming you. We're just see
On Sun, 27 Oct 2002, David D. Hagood wrote:
> P. Christeas wrote:
>
> >
> > Write a segment of code that will abort wine, if it is run as root
> > (that is,
> > just before wine starts anything). This piece of code should only be
> > explicitly disabled in the 'configure' script. That way, only a
On Sun, 27 Oct 2002, Peter Andersson wrote:
> What is it with you people?
> I was just trying to make a point about the security risks about using wine
> at present. And you start flameing me?
We're not flaming you. We're just see big flaws with your proposal. We
also proposed alternatives that
> Also, I stated that the command line parameter to wine would be required
> to even start the process - in other words, if you didn't supply it, you
> would not get the dialog, wine would just terminate.
>
> AND, this would not necessarily have to be bloat in wine, it could be
> handled by a defa
On Sun, Oct 27, 2002 at 07:51:01AM -0600, David D. Hagood wrote:
> I would ALSO suggest that wine check the execute bit on the application
> being run - the recent incident with Klez running under Wine would not
> have happened (I think) if wine would not run that which is not marked
> with the
Eric Pouech wrote:
does rm have such an option ? rm doesn't, so I don't see any reason for
Actually, rm DOES have such an option:
-i, --interactive
prompt before any removal
AND certain distros (RedHat for example) alias rm to "rm -i" by default.
Also, I stated that the com
On October 27, 2002 06:37 am, Peter Andersson wrote:
> My idea is to use ptrace in a supervisor process to trap all syscalls from
> the wine process, and use some kind of sanity checks for some of the
> syscalls. Watching the fork,exec,open,write and unlink syscalls and doing
> sanity checks could
Excuse me, but I don't think that any of these proposed methods will
live up to any real malicious code. Personally, I believe we should make
wine:
A. Not require root
B. As secure on it's own as possible (i.e. - not open to any problems
not introduced by the hosted program).
These two should a
> I slightly disagree - I think the thing to do would be to have wine not
> run if UID == 0, UNLESS the commandline parameter --i-know-i-am-root is
> set, AND THEN pop up a dialog box that requires confirmation before
> continuing.
does rm have such an option ? rm doesn't, so I don't see any reason
P. Christeas wrote:
Write a segment of code that will abort wine, if it is run as root
(that is,
just before wine starts anything). This piece of code should only be
explicitly disabled in the 'configure' script. That way, only a
I slightly disagree - I think the thing to do would be to have
> Peter Andersson <[EMAIL PROTECTED]> writes:
> > The question is...Would you expect that damage from running a windows app
> > in wine, when you know it could be safely run in Windows?
> > In just a few embedded bytes in the code it could remove your home
> > directory in a single syscall. Would y
On Sunday 27 October 2002 11:37, Peter Andersson wrote:
> What is it with you people?
> I was just trying to make a point about the security risks about using wine
> at present. And you start flameing me?
I don't see any flames, just strong criticism of your idea for which you may
not have thoug
On Sun, 27 Oct 2002, Peter Andersson wrote:
> What is it with you people?
> I was just trying to make a point about the security risks about using wine
> at present. And you start flameing me?
> Instead of continuing this flame war I will try to express myself more
> clearly.
You call that a fla
What is it with you people?
I was just trying to make a point about the security risks about using wine
at present. And you start flameing me?
Instead of continuing this flame war I will try to express myself more
clearly.
Before I go into details of my idea, lets make a few things clear...
I a
On Saturday 26 October 2002 11:43 pm, Francois Gouget wrote:
> On Sat, 26 Oct 2002, Greg Turner wrote:
> > That is, wine "emulates" an OS with no security measures at the
> > filesystem level, no security policy regarding what API's can be called
> > (except as provided by the CPU itself), and so o
On Sat, 26 Oct 2002, Greg Turner wrote:
[...warning: slight reordering...]
> I think the problem is one of wine being closely associated with Windows,
> and windows having a reputation of being insecure; in other words, it's a problem
> of perception, not of technical merit. Nothing wrong with tha
On Saturday 26 October 2002 08:32 pm, Vincent Béron wrote:
> Peter Andersson a écrit:
> > Malicious Linux/Unix syscalls could be embedded
> > in windows apps and if executed do a great deal of damage.
>
> And don't forget that if you try to build a wall in an open field, there
> will probably be s
Peter Andersson <[EMAIL PROTECTED]> writes:
> The question is...Would you expect that damage from running a windows app
> in wine, when you know it could be safely run in Windows?
> In just a few embedded bytes in the code it could remove your home directory
> in a single syscall. Would you expec
On Sun, 27 Oct 2002, Peter Andersson wrote:
[...]
> I believe most wine users trust wine not to touch anything outside of
> its configured drive space. Malicious Linux/Unix syscalls could be embedded
> in windows apps and if executed do a great deal of damage. After all checking
> your app is run
Peter Andersson a écrit:
Hello again,
(FYI, I took the liberty to change the topic since I started the
former thread "How is Win/Dos syscalls implemented in Wine?"
which I feel has gone a little bit off-topic)
I had some more thoughts on the issue...
I believe most wine users trust wine not
Hello again,
(FYI, I took the liberty to change the topic since I started the
former thread "How is Win/Dos syscalls implemented in Wine?"
which I feel has gone a little bit off-topic)
I had some more thoughts on the issue...
I believe most wine users trust wine not to touch anything outside
35 matches
Mail list logo
