SSOOS

[hexic]

Hello everyone. I have this OS that I am working on called SSOOS. It is still on the drawing board, so there is nothing downloadable yet, except for a few detailed descriptions of various parts of it. If you want more information, go to
http://www.freewebs.com/ssoos

[proxy]

a few comments:

the firewall idea is interesting, but tracking mac addresses will be near useless as once traffic hits the interet (other side of a router) the mac address info is effectivly gone or useless. MAC addresses are really a LAN thing for when switchs and such are involved.

Also the filesystem seems a little half baked. it may be good, but it needs more panning out. For example a 1 byte id is rather limiting, you can only have 256 files totol in a file system... my OS nears that in it source files...

just some thoughts.

proxy

[Legend]

And don't forget that at least more expensive card have reconfigurable MAC addresses (at least until rebooted)

[Candy]

And don't forget that at least more expensive card have reconfigurable MAC addresses (at least until rebooted)

expensive cards such as the very common $6-$12 rtl8139-based cards...

[Legend]

Gets even better then

I only needed this feature at work, and here are no realtek chips, so I didn't know, sorry

[bkilgore]

s/IP/MAC in his document and it becomes a better idea...

[Dreamsmith]

So all ports appear open. To implement this, one cannot REJECT attempts to connect to unbound ports. One can't even simply drop the packets on the floor without responding. One has to go through the work of responding to any TCP connection attempt by essentially establishing one, and responding to incoming data packets appropriately while dropping the data on the floor. That's a lot more work -- but the idea is intriguing. It's a ***** for error detection -- you don't know whether the data you're sending to the server is being read or not -- but it's a great way to make sure the outside has no information about what, if anything, is going on inside. Double-edged sword, but useful in some circumstances. Probably overkill, but I'd like to see the expression of the face of the unsuspecting portscanning script kiddie when his screen fills with a list of every possible port, assuming his portscanner doesn't overflow a buffer and crash LOL...

[Dreamsmith]

You know, the more I think about this idea, the more I like it. It has other potential advantages. For example, a client could potentially connect to a server before the server is ready, even before it's been run! The OS allows and establishes a connection to port X, even though no app is listening to port X, because that's just how this OS does things. A few seconds later, the server that reads port X comes online. From that point forward, instead of data on this connection being dropped on the floor, it goes to the app. There's a problem of what about the data that was sent before the app came up, but perhaps you could buffer a reasonable amount of information, even in the absence of a listening app, just in case one comes along later.

How useful is this, really? Not sure. But a neat idea nonetheless...

[BI lazy]

could be used as honeypot next to a strong secured dmz. the haxxors won't believe it and gnash teeth.

[Candy]

Somehow... it won't work as good as you are now thinking it will... Connecting using TCP makes for a lot of overhead. Even if you discard everything, allowing connections everywhere allows for nice synflooding. Consider somebody sending 65535 packets with a SYN, and you waiting for up to 60 seconds before dumping 64k TCP connection slots (of at least 4k or something each, that is 256M memory). Not a good plan.

Still, allowing people to connect allows them to fingerprint your computer. The best situation is a closed & an open port, with only open you can still get a lot of information. In the internet-situation, where everybody can only feel around, not look, it's best if they cannot feel you are there. If you are stealth on every port, they will not be able to hack you.

[zloba]

but it's a great way to make sure the outside has no information about what, if anything, is going on inside.

unless they do a protocol-specific probe (http request), or the protocol responds with a greeting to start with. (such as ftp, smtp)
that is to say, either your service is available to the outside world, with all risks involved, or you are "dead to the world", with only outgoing connections.

How useful is this, really? Not sure. But a neat idea nonetheless...

imho it could be somewhat useful when a service is being restarted, then it could tell OS to keep the listening socket open and hold the connections.. but only when specifically requested. what good will this do if this port was never going to be used to start with? and what if the service exists, but won't come up for some time - would the clients be willing to sit there and wait until that happens? (or would it be easier for everyone to handle a reject)

There's a problem of what about the data that was sent before the app came up, but perhaps you could buffer a reasonable amount of information, even in the absence of a listening app, just in case one comes along later.

i believe it's already taken care of in TCP's buffering and flow control logic. a specific amount gets buffered, and then the client is notified to wait until further notice (until some data is consumed) before sending any more. not sure about details though.

and, like Candy said, accepting all ports means creating more opportunities for dos. you can run out of memory due to per-connection allocated resources and buffering, and/or have your network module slowed down by sorting through thousands of useless connections.. and if you are doing sanity checking, you'll have a whole lot more to worry about.