Hello!
The comments on this profile are unclaimed and thus are unverified.
Do they belong to you? Claim these comments.
Seth
Is this you? Claim Profile »
9 months ago
in Monovation: Assembly Injection into Live Processes - Miguel de Icaza on Miguel de Icaza's blog
Wow. This is exciting stuff.
I second most of the security concerns. Just pointing at similar capabilities in competing technologies doesn't mean it is secure. It just means they are all flawed for the same pragmatic reasons (productivity). I do think the truth is not so dramatic as some of the commenters make it sound, but hey: it is a concern.
Dll-injection on Win32 has proven to be the backspine of all spy-ware. Yes it is powerful. Lot's of powerful things are dangerous.
My most important fear here, is actually more on the conceptual level. Using this for debugging is ok. Using it for auditing might be ok. [provided adequate privileges are required for each task]. However, the examples lean in the direction of (oh - no - here it comes) automation.
It is just another 'interoperability' route going the promiscuous/incestuous way: we have had DDE (oh no), OLE (mmm) COM(+) Application Servers (ok-ish), Office Automation (Noooooooooooooooooooo(2)), Dll-Injection (whoaaaaa), Bonobo (mmm), DBus (ok-ish); etc. etc. etc. All quite different in many respects, but the main thing that has stood out to me is that
(a) desktop environments stop mingling together(1),
(b) there is a significant performance penalty (bonobo, DCopserver, Dbus - they all grow and have their slightly obese backends running at all times)
(c) most importantly applications get tightly bound, where there should have been no need to.
In my mind this is the 'easy' way to integrate from dev standpoint. But it is the type of lazy easy that comes with heavy costs - in the long run.
E.g. DBus has got over this new 'mono attach' design, that it is easy (necessary) to specify *exactly* what interface surface you'd like to expose. If you wanted plugins: define a plugin interface and just explicitely load these things. This was already exceedingly simple by design in .NET/Java.
In my opinion any layer on top of simple text-file/socket protocols has the obvious advantages over these strategies (decoupling, portability (try mono attach using perl; try mono attach from our AIX server - oops?), transparency (try remote attach? try attach across virtual machine boundaries?), security (reduced surface, explicit POSIX permissions, optional ACLs to name a few).
Now, I happen to really like features like this one, but I have this worry that the (Gnome) desktop will become the same muddy clutter that we have seen in all other OS-es that couldn't resist adding every feature they could think of.
My boot time is already up there with Windows 2003 running Ubuntu 8.04; I'd like to think we let Microsoft hold pole position in that area...
Starting Thunderbird is already starting to take scary amounts of time.
In the mean time: both csharp and 'mono attach' are very nice tools and valuable 'firsts' for the mono community. If handled with care, lot's of good will come of it !
Cheers
(1) no that app cannot be saved as part of the session, it doesn't speak bonobo, sorry
(2) get me right: VBA = good (the feature, not the language), office automation = bad (see: installing Outlook on servers; launching Word to inspect document contents by automation - eeeeeeeeeeeeeeck)
PS. Would it be possible to attach to a process, while creating a separate AppDomain in the target process? This could be a help in keeping things as secure as possible
I second most of the security concerns. Just pointing at similar capabilities in competing technologies doesn't mean it is secure. It just means they are all flawed for the same pragmatic reasons (productivity). I do think the truth is not so dramatic as some of the commenters make it sound, but hey: it is a concern.
Dll-injection on Win32 has proven to be the backspine of all spy-ware. Yes it is powerful. Lot's of powerful things are dangerous.
My most important fear here, is actually more on the conceptual level. Using this for debugging is ok. Using it for auditing might be ok. [provided adequate privileges are required for each task]. However, the examples lean in the direction of (oh - no - here it comes) automation.
It is just another 'interoperability' route going the promiscuous/incestuous way: we have had DDE (oh no), OLE (mmm) COM(+) Application Servers (ok-ish), Office Automation (Noooooooooooooooooooo(2)), Dll-Injection (whoaaaaa), Bonobo (mmm), DBus (ok-ish); etc. etc. etc. All quite different in many respects, but the main thing that has stood out to me is that
(a) desktop environments stop mingling together(1),
(b) there is a significant performance penalty (bonobo, DCopserver, Dbus - they all grow and have their slightly obese backends running at all times)
(c) most importantly applications get tightly bound, where there should have been no need to.
In my mind this is the 'easy' way to integrate from dev standpoint. But it is the type of lazy easy that comes with heavy costs - in the long run.
E.g. DBus has got over this new 'mono attach' design, that it is easy (necessary) to specify *exactly* what interface surface you'd like to expose. If you wanted plugins: define a plugin interface and just explicitely load these things. This was already exceedingly simple by design in .NET/Java.
In my opinion any layer on top of simple text-file/socket protocols has the obvious advantages over these strategies (decoupling, portability (try mono attach using perl; try mono attach from our AIX server - oops?), transparency (try remote attach? try attach across virtual machine boundaries?), security (reduced surface, explicit POSIX permissions, optional ACLs to name a few).
Now, I happen to really like features like this one, but I have this worry that the (Gnome) desktop will become the same muddy clutter that we have seen in all other OS-es that couldn't resist adding every feature they could think of.
My boot time is already up there with Windows 2003 running Ubuntu 8.04; I'd like to think we let Microsoft hold pole position in that area...
Starting Thunderbird is already starting to take scary amounts of time.
In the mean time: both csharp and 'mono attach' are very nice tools and valuable 'firsts' for the mono community. If handled with care, lot's of good will come of it !
Cheers
(1) no that app cannot be saved as part of the session, it doesn't speak bonobo, sorry
(2) get me right: VBA = good (the feature, not the language), office automation = bad (see: installing Outlook on servers; launching Word to inspect document contents by automation - eeeeeeeeeeeeeeck)
PS. Would it be possible to attach to a process, while creating a separate AppDomain in the target process? This could be a help in keeping things as secure as possible
2 replies
psantosl
Amazing guys!!! I really like all this stuff about dynamic code loading. It only makes Mono better.
Beyond all the "dangerous" stuff (hey, evil is just there), I think it opens up a whole world of great possibilities... Now it's our turn (app developers) to really make sure we get the best out of this!
Congratulations!
Beyond all the "dangerous" stuff (hey, evil is just there), I think it opens up a whole world of great possibilities... Now it's our turn (app developers) to really make sure we get the best out of this!
Congratulations!
9 months ago
in Stream.CopyStream - Miguel de Icaza on Miguel de Icaza's blog
mmm I have always stopped short of implementing this in a framework bit (rock, part of runtime, whatever), because.... quite frankly I don't see the added value.
In my intuition it almost always comes down to deficiencies in the desing of the stream libraries/consumers that create the need to 'copy' a stream. Invariably this is more like 'relabeling' just to to the taste of a receiving party. While thinking about this it might simply be a wrong intuition (I can think of simple counterexamples like copying a socket to a file).
In all non-trivial cases, however, Copy is simply a misnomer, because a fair bit of transformation is usually involved (charsets, endianness, line ends, etc).
In my experience, C++ <iostream> is about the only library that 'gets it right' (.NET duplicating to much of the pitfalls from Java, thought fortunately less so). In c++ any (compatible, i.e. wellknown conversions or 1:1 binary equivalent) streams can simply be copied by saying smart things like:
std::cout << fstream1.rdbuf() /* << std::eos */;
Essentially: it is the separation of buffer and stream that saves the day. (Don't try std::cout << fstream1; unless you are very interested in the (hex) address of fstream1 instance).
In my intuition it almost always comes down to deficiencies in the desing of the stream libraries/consumers that create the need to 'copy' a stream. Invariably this is more like 'relabeling' just to to the taste of a receiving party. While thinking about this it might simply be a wrong intuition (I can think of simple counterexamples like copying a socket to a file).
In all non-trivial cases, however, Copy is simply a misnomer, because a fair bit of transformation is usually involved (charsets, endianness, line ends, etc).
In my experience, C++ <iostream> is about the only library that 'gets it right' (.NET duplicating to much of the pitfalls from Java, thought fortunately less so). In c++ any (compatible, i.e. wellknown conversions or 1:1 binary equivalent) streams can simply be copied by saying smart things like:
std::cout << fstream1.rdbuf() /* << std::eos */;
Essentially: it is the separation of buffer and stream that saves the day. (Don't try std::cout << fstream1; unless you are very interested in the (hex) address of fstream1 instance).
1 reply
Jonathan Pryor
I think you don't fully understand .NET's Stream concept, as it's closer to C++ than Java.
Stream is _only_ byte oriented. No encodings, no endianness, no line endings, just raw data. It is thus analogous to the C++ std::streambuf type, if even more primitive (there is no wstreambuf equivalent).
StreamReader and StreamWriter are responsible for text-oriented manipulation, such as encoding issues, end of line encodings, etc., which is what std::istream and std::ostream deal with in C++ (and more).
Stream is _only_ byte oriented. No encodings, no endianness, no line endings, just raw data. It is thus analogous to the C++ std::streambuf type, if even more primitive (there is no wstreambuf equivalent).
StreamReader and StreamWriter are responsible for text-oriented manipulation, such as encoding issues, end of line encodings, etc., which is what std::istream and std::ostream deal with in C++ (and more).
9 months ago
in Encrypted File Systems - Miguel de Icaza on Miguel de Icaza's blog
Ok, I for one would like to see this comment being equally concrete and to-the-point as the original post :)
@MIguel: kudos for pointing out the obvious (fuse is more usable then kernel/loop) and implicit (ssh backing... nice).
@tf: just tell me *one* of these distros and I'll give it a go today.
@MIguel: kudos for pointing out the obvious (fuse is more usable then kernel/loop) and implicit (ssh backing... nice).
@tf: just tell me *one* of these distros and I'll give it a go today.
1 reply
tf
debian (l am using lenny); when it comes to partitioning, you get the option to use encryption, I use encrypted LVM.
10 months ago
in getline.cs: Partying like its 1988 - Miguel de Icaza on Miguel de Icaza's blog
Well thank you very much. That'll spare me the boring details of fidgetting with keyboard entry, control codes, terminal capabilities etc.
Quite incredible that it doesn't depend on say libreadline? I'm curious as to how portable this really behaves, but I'll give you the credit based on your track record for now
Great work
Quite incredible that it doesn't depend on say libreadline? I'm curious as to how portable this really behaves, but I'll give you the credit based on your track record for now
Great work
1 reply
Ed Ropple
> Quite incredible that it doesn't depend on say libreadline?
Doesn't look like it does. And a good thing, too - anything to get away from the GPL for utility libraries is a good thing (GPLv2 for readline? *Really*?).
-Ed
Doesn't look like it does. And a good thing, too - anything to get away from the GPL for utility libraries is a good thing (GPLv2 for readline? *Really*?).
-Ed
1 year ago
in My Bachelor degree and the importance of the Free and Open Source Software on Ivan Zlatev
practicle “exercises” hehe
reading too much quatnum machenics are you? Well, congratulations, sure sounds like you have a CV cut-out there!
PS. Isn't 3 years a bit shortish? But then again, you didn't care much for that city
reading too much quatnum machenics are you? Well, congratulations, sure sounds like you have a CV cut-out there!
PS. Isn't 3 years a bit shortish? But then again, you didn't care much for that city
1 reply
Ivan Zlatev
In the United Kingdom Bachelor Degree takes 3 years, Masters takes 1 year. I think in most other European countries it is 4 and 2 years accordingly.
Sure, it will "protect" the target application for all of 10 seconds, the 10 seconds it takes you to call system("rm -rf ~") which would have been a simpler, more effective attack.