Lets see - they're trying to move data processing and storage to a centralized (in some respects) server and move the interface to the client (the web browser). You know what that sounds like? X-Windows. Does web services sound like thin client to anyone else?
What's limiting about web browsers is that you have a very limited range of widgets (and so are limited in what kinds of interfaces you can make). Web browsers also tend to talk to the server infrequently (as compared to normal interface/backend communication in the world of locally run apps). This makes web based services less fat than X is, but X gives you a lot more flexability (maybe too much).
Because X is too fat for much more than running apps over a LAN, something more light weight is needed. How about a protocol that functions similarily to X, but allows one to negotiate the frequency of communication between client and server for a connection? I think that sort of protocol could bridge the worlds of the web and thin client.
Well, not completely... in the windows world you can always use roaming profiles and save your crap to a share on a file server. If you want total thin client, there's terminal services and citrix.
I think that a large proportion of the infected machines are the desktops of users who just installed IIS along with the rest of everything because they didn't know what they needed and what they didn't. These are boxes that don't have systems admins to patch them. I'll bet that half of these people don't even know that they have IIS installed and if they do, they don't realize that they're infected since they're files are all still there and the virus hasn't popped up a HUGE message on their screen saying "YOU ARE INFECTED".
You don't need to buy books, there's a tonne of documentation that comes with almost every distribution... man pages are pretty authoritative, and stuff in/usr/share/doc is usually pretty thorough... almost every package has a website with a mailing list and posts the author's contact information. If you need to buy a book after all of that, it's not the fault of the developer. Books are nice, but not necessary. I havn't really used Windows since Windows 95, but I remember that the documentation sucked, and if you wanted to understand how much actually worked, you'd have to buy a book or dig through websites that were badly organized.
Well, the IETF hopes that that will only be the case before IPV6 is fully implemented. It's hoped that ISPs will realize that there isn't any cost in giving users more addresses and so more addresses shouldn't be charged for. You can already connect to the current IPV6 net via a tunnel and get a big address space (free).
Terminal velocity is not an instant thing... it takes time to reach terminal velocity. Objects in space travel at huge speeds... many many thousands of km/hour. The object would not have decelerated to terminal velocity before it hit the ground. If you look at the damage that screws cause when they collide with spacecraft in space, you'll see why a small meteorite could cause HUGE damage.
Thanks for so thorough a response:) Of course not every point applies to every situation. My main point is simply that attackers don't need to invest many resources to attack computer systems, especially when they have a tonne of free time and are supported by others (think teenagers). Defenders have large systems to manage and must invest a lot in terms of time and money to manage them securely. In this sense, attackers are at an advantage. Essentially, attackers have most of the advantages that defenders do, but also have some particular advantages of their own. So yah - just that it's easier to do damage than to prevent damage.
defense always has an advantage over offense, in terms of time and effort
I would argue that this is not the case in the computer world.
o A defender has many bases to protect; often with few resources.
o The human resources needed to build an effective security team are incredibly expensive.
o If an attacker compromises even one 'base', hiding tracks and stepping to other resources is often easy.
o Even detecting a compromise can be extremely difficult, let alone determining what damage has been done, etc.
o Attackers may attack at leisure and need only find ONE of many possible vulnerabilities.
o Attackers can also attack with very little cost or consequence by bouncing through different proxies.
o Defenders must obey the law, while attackers may not.
o In the real world, defenders can launch offensive measures as a defense; you can't really do this in the computer world.
o Attackers often find out about vulnerabilties in the defender's system before the defender knows about them
I don't think that defenders have any advantage; attackers almost certainly have the upper hand. In the real world, the following factors make defense positions stronger in conventional warfare:
o Defense can see that attack comming and anticipate what the attacker will do
o Attacker's goals are often obvious
o Attacker is out in the open, while defense has had time to build heavy physical defenses and stockpile resources
o Attacker is unlikely to find a gaping hole in the defender's defensive measures
Well, performance is important in a lot of situations. Businesses (often targets) will often choose performance over security simply because the cost savings are up front if you can run more on one box... security is one of those delayed savings things ("it won't happen to me" mentality). I agree that people should be using stackguard type things. I also think that we need to maintain least privilige concepts - don't let processes setuid to any user - restrict it (via rsbac), use ACLs to limit access to files to specific applications, run most programs under their own user, etc. This would stand to greatly limit the impact of buggy software.
I can't wait until distributions start shipping with ACL support, and installed files come with ACLs that are as restrictive as possible. Also, with stuff like RSBAC's (www.rsbac.org) auth mechanism for fine control of setuid stuff and more fine grained capabilities control will raise the bar and make it more difficult for attackers to exploit buggy server software. Hopefully it'll be soon:)
There's an idea being passed around to tie an indentity system into jabber. Jabber's decentralized in a similar way to email. User addresses are user@host, so hosts are authoritative for particular user's identities. Users can set policies to decide who can access personal information (and exactly what information). Jabber servers would function as a sort of certificate authority, issuing identity certificates to it's users... the certificates can then facilitate strong encryption over the jabber protocol, as well as letting subscribed services authenticate simply by making sure that the certificate is signed by the user's server. This provides for decentralized (from the network perspective) but centralized (from the user's perspective) authentication.
Well, I find that almost all hacking attempts come from compromised boxes. I like to report these compromised boxes to their admins. Sometimes, these attacks come from IPs with no reverse lookup record. The whois database helps me to find email addresses that I can send mail to. I think that policy should depend on the tld..com,.net, and.edu, should all require telephone, email, mailing and fax address information... but.org, and.arpa should only require maybe email contact info... country TLDs can set their own policies.
Nowhere did I suggest obscurity. I just think that manufacturing items with intent to help someone commit a crime is wrong and should be illegal. It's like growing anthrax and putting advertisments out in the paper saying, 'I grew anthrax, come get some for free if you want to do some "research"'. You do that and you're in shit (and rightly so). People in labratories can grow anthrax and sell it to other labs legally because their intent is good; if ever it's discovered that they're selling it to people who are obviously terrorists, the lab could be charged with neglegence, or even murder (if you could prove that the lab people knew they were selling to terrorists). Posessing a root kit for purposes like investigating it's function to help secure your boxes is reasonable, but like other people have said, intent matters.
Lets stop trying to make analogies for every single issue? They're only useful when trying to explain an issue to someone who doesn't understand it; I think that the issue of rootkits is generally pretty well understood by this community. Rootkits are designed to aide criminal activity - I can't think of any other purpose for them except to make sys admins afraid and thus more vigilant. If you have a root kit, you can claim that you're experimenting to see how it can be defeated... but if you create one, you're creating a tool which has a sole purpose that's illegal. I don't think we need more law for this; shouldn't it be covered by aiding and abetting laws already?
One, dselect can get confused with complex dependancy problems and not really show you a way to fix it... it can also mess up complex dependancies and try to remove all sorts of packages (which is VERY bad). These problems show up most when using the unstable distribution. apt-get's quick, tells you about dependancies and lets you take action with some thought, doesn't over-automate stuff (as in won't automatically remove all sorts of packages unless you tell it to), etc. apt-get is also a bit more flexable than dselect... the command line tools coupled with grep, awk, sed, etc are extremely useful to do calculations on how much space is taken by a specific set of packages, etc etc. Dselect's nice for newbies, but once you know your way around the system, it's quicker, easier, and more safe to use apt-get and not dselect.
PS to another poster (sorry I forget who) - using task packages you can easily use apt-get to install a system from base, without dselect... even without tasks you can just apt-get the major packages that you want and it'll grab the dependancies that it needs - that covers most packages you'll want to install.
The amount of time that it takes for a full reboot to complete (especially on a windows 2000 box) is orders of magnitude greater than restarting X. A more accurate comparison would be hitting 'log off of username' in windows and logging back in. Also, when X dies, I can still sometimes send X programs signals... I think that there needs to be a signal such that when given to a program, it will save it's state in a temporary location so that it can be restored when started again... that would save a lot of the issues with restarting X.
Are you sure that fixes for those bugs weren't backported into the stable tree? You can always deb-src the newer packages and have them automagically compile against stable tree libraries and be installed.
I love that nowhere in MS's W2K texts that I've read, does it mention that a kerberos KDC needs to be computationally secure, since if it is compromised, all passwords in a domain must be changed, since the attacker can potentially decrypt the session keys in use on the network.
Probably because those successful companies were started by people with really great ideas... when you have a good idea, and have enthusiasm, and can insite that in others, you're going to have a good business:) (probably:)
What better way to learn about networks and computers? Get permission from parents to let the kids bring in games... then have them set them up and play against eachother... have them set up the ethernet network that they're going to play over, and teach them how it works. Most kids like playing video games:) They'll learn how to install software, what files are, what networks are, vaguely how networks work, and they'll do it having a lot of fun (which is the most important thing). When I was in elementary school, I hated sitting in acedemic classes - you've got to disguise the learning in fun:) I'll bet kids don't really care that an ASCII character is 8 bits, and which is different from a 16 unicode character... they won't care to know how to count in binary, and they probably won't care how to address memory in any programming language.
Slashdot Mirror
Lets see - they're trying to move data processing and storage to a centralized (in some respects) server and move the interface to the client (the web browser). You know what that sounds like? X-Windows. Does web services sound like thin client to anyone else?
What's limiting about web browsers is that you have a very limited range of widgets (and so are limited in what kinds of interfaces you can make). Web browsers also tend to talk to the server infrequently (as compared to normal interface/backend communication in the world of locally run apps). This makes web based services less fat than X is, but X gives you a lot more flexability (maybe too much).
Because X is too fat for much more than running apps over a LAN, something more light weight is needed. How about a protocol that functions similarily to X, but allows one to negotiate the frequency of communication between client and server for a connection? I think that sort of protocol could bridge the worlds of the web and thin client.
10 million bucks is a lot of money to drop one (admittedly large) cannonball :)
I wasn't argueing that Windows does multi-user as well as Unix - just that it could do it to some degree.
Well, not completely... in the windows world you can always use roaming profiles and save your crap to a share on a file server. If you want total thin client, there's terminal services and citrix.
I think that a large proportion of the infected machines are the desktops of users who just installed IIS along with the rest of everything because they didn't know what they needed and what they didn't. These are boxes that don't have systems admins to patch them. I'll bet that half of these people don't even know that they have IIS installed and if they do, they don't realize that they're infected since they're files are all still there and the virus hasn't popped up a HUGE message on their screen saying "YOU ARE INFECTED".
You don't need to buy books, there's a tonne of documentation that comes with almost every distribution... man pages are pretty authoritative, and stuff in /usr/share/doc is usually pretty thorough... almost every package has a website with a mailing list and posts the author's contact information. If you need to buy a book after all of that, it's not the fault of the developer. Books are nice, but not necessary. I havn't really used Windows since Windows 95, but I remember that the documentation sucked, and if you wanted to understand how much actually worked, you'd have to buy a book or dig through websites that were badly organized.
This is a good topic for a slashdot poll: how much money as a consumer have you spent on Linux distributions? 0, 1-100, 100-500, 500-2000, 2000+
Well, the IETF hopes that that will only be the case before IPV6 is fully implemented. It's hoped that ISPs will realize that there isn't any cost in giving users more addresses and so more addresses shouldn't be charged for. You can already connect to the current IPV6 net via a tunnel and get a big address space (free).
Terminal velocity is not an instant thing... it takes time to reach terminal velocity. Objects in space travel at huge speeds... many many thousands of km/hour. The object would not have decelerated to terminal velocity before it hit the ground. If you look at the damage that screws cause when they collide with spacecraft in space, you'll see why a small meteorite could cause HUGE damage.
Thanks for so thorough a response :) Of course not every point applies to every situation. My main point is simply that attackers don't need to invest many resources to attack computer systems, especially when they have a tonne of free time and are supported by others (think teenagers). Defenders have large systems to manage and must invest a lot in terms of time and money to manage them securely. In this sense, attackers are at an advantage. Essentially, attackers have most of the advantages that defenders do, but also have some particular advantages of their own. So yah - just that it's easier to do damage than to prevent damage.
defense always has an advantage over offense, in terms of time and effort
I would argue that this is not the case in the computer world.
o A defender has many bases to protect; often with few resources.
o The human resources needed to build an effective security team are incredibly expensive.
o If an attacker compromises even one 'base', hiding tracks and stepping to other resources is often easy.
o Even detecting a compromise can be extremely difficult, let alone determining what damage has been done, etc.
o Attackers may attack at leisure and need only find ONE of many possible vulnerabilities.
o Attackers can also attack with very little cost or consequence by bouncing through different proxies.
o Defenders must obey the law, while attackers may not.
o In the real world, defenders can launch offensive measures as a defense; you can't really do this in the computer world.
o Attackers often find out about vulnerabilties in the defender's system before the defender knows about them
I don't think that defenders have any advantage; attackers almost certainly have the upper hand. In the real world, the following factors make defense positions stronger in conventional warfare:
o Defense can see that attack comming and anticipate what the attacker will do
o Attacker's goals are often obvious
o Attacker is out in the open, while defense has had time to build heavy physical defenses and stockpile resources
o Attacker is unlikely to find a gaping hole in the defender's defensive measures
o Attack is resource consuming
Well, performance is important in a lot of situations. Businesses (often targets) will often choose performance over security simply because the cost savings are up front if you can run more on one box... security is one of those delayed savings things ("it won't happen to me" mentality). I agree that people should be using stackguard type things. I also think that we need to maintain least privilige concepts - don't let processes setuid to any user - restrict it (via rsbac), use ACLs to limit access to files to specific applications, run most programs under their own user, etc. This would stand to greatly limit the impact of buggy software.
I can't wait until distributions start shipping with ACL support, and installed files come with ACLs that are as restrictive as possible. Also, with stuff like RSBAC's (www.rsbac.org) auth mechanism for fine control of setuid stuff and more fine grained capabilities control will raise the bar and make it more difficult for attackers to exploit buggy server software. Hopefully it'll be soon :)
There's an idea being passed around to tie an indentity system into jabber. Jabber's decentralized in a similar way to email. User addresses are user@host, so hosts are authoritative for particular user's identities. Users can set policies to decide who can access personal information (and exactly what information). Jabber servers would function as a sort of certificate authority, issuing identity certificates to it's users... the certificates can then facilitate strong encryption over the jabber protocol, as well as letting subscribed services authenticate simply by making sure that the certificate is signed by the user's server. This provides for decentralized (from the network perspective) but centralized (from the user's perspective) authentication.
Well, I find that almost all hacking attempts come from compromised boxes. I like to report these compromised boxes to their admins. Sometimes, these attacks come from IPs with no reverse lookup record. The whois database helps me to find email addresses that I can send mail to. I think that policy should depend on the tld. .com, .net, and .edu, should all require telephone, email, mailing and fax address information... but .org, and .arpa should only require maybe email contact info... country TLDs can set their own policies.
Nowhere did I suggest obscurity. I just think that manufacturing items with intent to help someone commit a crime is wrong and should be illegal. It's like growing anthrax and putting advertisments out in the paper saying, 'I grew anthrax, come get some for free if you want to do some "research"'. You do that and you're in shit (and rightly so). People in labratories can grow anthrax and sell it to other labs legally because their intent is good; if ever it's discovered that they're selling it to people who are obviously terrorists, the lab could be charged with neglegence, or even murder (if you could prove that the lab people knew they were selling to terrorists). Posessing a root kit for purposes like investigating it's function to help secure your boxes is reasonable, but like other people have said, intent matters.
Sounds like the prosecutor deserves a bit of career damage; wasting 18 months on distributed.net? That's incompetent.
Lets stop trying to make analogies for every single issue? They're only useful when trying to explain an issue to someone who doesn't understand it; I think that the issue of rootkits is generally pretty well understood by this community. Rootkits are designed to aide criminal activity - I can't think of any other purpose for them except to make sys admins afraid and thus more vigilant. If you have a root kit, you can claim that you're experimenting to see how it can be defeated... but if you create one, you're creating a tool which has a sole purpose that's illegal. I don't think we need more law for this; shouldn't it be covered by aiding and abetting laws already?
well, it's arms, not guns in the constitution... I'd say bullets are arms.
One, dselect can get confused with complex dependancy problems and not really show you a way to fix it... it can also mess up complex dependancies and try to remove all sorts of packages (which is VERY bad). These problems show up most when using the unstable distribution. apt-get's quick, tells you about dependancies and lets you take action with some thought, doesn't over-automate stuff (as in won't automatically remove all sorts of packages unless you tell it to), etc. apt-get is also a bit more flexable than dselect... the command line tools coupled with grep, awk, sed, etc are extremely useful to do calculations on how much space is taken by a specific set of packages, etc etc. Dselect's nice for newbies, but once you know your way around the system, it's quicker, easier, and more safe to use apt-get and not dselect.
PS to another poster (sorry I forget who) - using task packages you can easily use apt-get to install a system from base, without dselect... even without tasks you can just apt-get the major packages that you want and it'll grab the dependancies that it needs - that covers most packages you'll want to install.
The amount of time that it takes for a full reboot to complete (especially on a windows 2000 box) is orders of magnitude greater than restarting X. A more accurate comparison would be hitting 'log off of username' in windows and logging back in. Also, when X dies, I can still sometimes send X programs signals... I think that there needs to be a signal such that when given to a program, it will save it's state in a temporary location so that it can be restored when started again... that would save a lot of the issues with restarting X.
Are you sure that fixes for those bugs weren't backported into the stable tree? You can always deb-src the newer packages and have them automagically compile against stable tree libraries and be installed.
I love that nowhere in MS's W2K texts that I've read, does it mention that a kerberos KDC needs to be computationally secure, since if it is compromised, all passwords in a domain must be changed, since the attacker can potentially decrypt the session keys in use on the network.
Probably because those successful companies were started by people with really great ideas... when you have a good idea, and have enthusiasm, and can insite that in others, you're going to have a good business :) (probably :)
What better way to learn about networks and computers? Get permission from parents to let the kids bring in games... then have them set them up and play against eachother... have them set up the ethernet network that they're going to play over, and teach them how it works. Most kids like playing video games :) They'll learn how to install software, what files are, what networks are, vaguely how networks work, and they'll do it having a lot of fun (which is the most important thing). When I was in elementary school, I hated sitting in acedemic classes - you've got to disguise the learning in fun :) I'll bet kids don't really care that an ASCII character is 8 bits, and which is different from a 16 unicode character... they won't care to know how to count in binary, and they probably won't care how to address memory in any programming language.