Right now SecureLVE only protects filesystem.
It is possible to add networking virtualization in the future, given how well network stack is virtualized in linux.
Of course -- it will depend on demand. Though it does start to go into realm of server virtualization which I don\'t like. We might be better off virtualizing IRC servers itself, so that there is just one server, but each \"feels\" like he is running his own instance. I am not too sure about it: due to security issues usually associated with IRC, and due to demand -- it might not be worth it.
Maybe at some point IRCd maintainers will be interested to adopt LVE technology -- and provide such virtualization themselves.

I dont understand how this would be applied to IRCd why you would od this? It makes no sense... I guess get IRCd out of your mind maybe it was a mistake to mention that....

Shell accounts.. SSH access people run processes... customers have a dedicated IP address... If customer A is using customer B\'s dedicated IP address that is a big problem...

It doesnt matter if it is a php script, a perl script, and bot, an ircd ... the customers inside the SecureLVE should only be able to use their assigned IP address... this is true for webhosting as well that allows SSH access for socket based programs.

you would litteraly need every last software desinginer ont he planet to implement LVE into their software which is not going to happen

Really this should be up to the secureLVE Directadmin CP or Cpanel assign dedicated IP to customer with SSH access.... SecureLVE checks this IP and only lets any processes customer launches to bind to their assigned IP address.

It is not really on the full virtualization level, as this is only virtualizing individual customer processes not entire operating systems

Well they would need to be able to bind to their assigned IP address and IP addresses that are considered public non owned IP addresses so something like this could get complicated, I dont know how you would implement it it is beyond my expertise.

If customer needs to run their own server of any type -- they are better off using VPS. It was meant for that.
I know some run it from shared hosting accounts -- but this is a form of abuse as defined by many hosting companies.

And yes, I am sure that at some point developers all over the world will start using LVE or some similar form of technology. We already see some adoption and I am sure we will see more. The technology is pretty generic, but has a lot of potential for any multi-tenant application. We had several server vendors inquiring about it already, and some already implemented it (LiteSpeed for example)

Hmm there seems to be some breakdown in communication here... no its not abusing shared hosts to have things such as socket servers, or running clients that bind to IP\'s...

XML-RPC socket servers are used for exposing web services, and shared hosting customers implement such technologies all the time... Most do it over http socket servers where many programs more efficiently handle it over pure sockets.

Then there is the case of client services that bind to specific IP addresses for authentication purposes... eggdrop bots fall into this category as well

What I was saying is with the literally thousands of client applications bind to IP addresses

we are just asking that securelve enforces which IP addresses these client applications are capable of binding to for their outgoing connections... and yes this has the added benefit of applying to IRCd style services as well...


Think of it this way, you are a shared host... you provide a dedicated IP address to a paying customer, this customer is paying for use of his own private IP address, you also provide ssh access, now customers with ssh access can launch all sorts of clients from their shell and bind them to that other customers dedicated IP address.... now is it fair to that other customer that these other customers are using his IP address? When they attempt to bind to their IP on the same port number they get messages like Address already in use

If you have gone as far as protecting the file system so they are guaranteed privacy and guaranteed ram, and guaranteed cpu why not guarantee them that their IP address is theirs and only theirs as well?

Bottom line is really when giving users ssh access they have access to bind applications to IP addresses and it would be really nice if securelve was able to implement some controls on this as well.

This would also make cloudlinux useful for more than just the web hosting community it would also make it useful with some long needed quality controls in the shell account / BNC hosting / Streaming media / IRC hosting markets

streaming media is another good example, by preventing access to only allowed IP addresses we could effectively give full control stream server shell accounts out without worrying about them using the resources of the other customers...

anyone can tell you a true vps such as xen or openvz is way overboard for these products that belong on a shared server otherwise every hosting company out there would be implementing it...

Cloudlinux is very promising with the launch of LVE and secure LVE wrappers to provide all these types of services with a quality control so one users process cannot take over the system resources and disrupt the other users.

We for one want to switch all of our servers over to cloudlinux securelve from currently in use Virtuozzo because for our business it makes more sense this includes our streaming media servers, our shell account & ircd hosting servers & our web hosting servers.

I see what you mean. Yet, it means those customers will have dedicated IP.
What would I do with customer with shared IP? How should they be treated?

for presentation purposes:

if (ip == \"owned\") {

    

    if (user == \"ipowner\") {



        $bind == true



    } else {



        $bind == false

        raise error;

    }



} else {

    

    $bind == true



} 

in other words, if ip is owned and this is the owner let them bind, otherwise reject with error, if this IP is not owned then let them bind.

To be more specific there is two different types of shared IP addresses... ones marked specifically in the control panel as being shared (these should let anyone bind)

And ones that are attached to the server but are not available in the control panel or apache config (These are also shared and anyone should be able to bind to them)

But not to be confused with IP\'s that are not marked as shared but have not yet been assigned to a user, but they are in the control panel and are in the apache config (because these IP\'s will become owned)...

I personally don\'t have a Cpanel server to see how they handle assigned and shared IP\'s in the configs but I do have directadmin servers and could do some more research on this.

This so far is just brainstorming..

Oh there should also be some sort of reserved list... so the server admin could mark specific IP\'s as not being able to bind to them... for instance say the HSP\'s services ran on a specific IP address and they did not want customers binding to the same IP addresses.

Not to confuse the situation but before you had mentioned the security implications of IRC & IRCd hosting...

One of the biggest problems in this industry is a malacious user signs up for a shell account and then uses an IP for hosting an IRCd server to control a botnet... upstream backbone providers null route the IP address or the IP gets klined from a major network like dalnet or Efent etc.

Typically the user just changes their IP that they bind to and before it comes to your attention they have gotten other customers IP addresses banned.

If cloudlinux was able to implement this security option into securelve the combination of this and the other securelve protections will deliver a new level of service to the industry that has been needed for years.

This is a good point. It should be very easy to prevent some users from binding to any IP at all (but say localhost?)
Letting them to bind to only one IP dedicated to them would be a bit more work -- but it can be done as well. I will add it to our todo list.

I just thought of a way that could give the server admin specific control over which IP addresses the customers could bind to:

/etc/bind.allow
/etc/bind.deny

They could then place all the IP addresses they deemed as shared in the bind.allow list

and put all the reserved ip addresses in the bind.deny


This would give the server admin total control over what IP\'s are allowed and not allowed and make your life easier....

The only magick that would then need to be done, is you would have to check if the user was the owner of an IP and if so allow them to bind even if the IP is not found in the bind.allow, this way they could still bind to their own dedicated IP.

I guess really you, wouldn\'t even need the bind.deny because the logic would be:

1) is the ip in the bind.allow list? if yes allow them to bind

2) if the ip is not in the allow list; is this user the current owner of the IP? if yes allow them to bind

3) else deny and don\'t let them bind.

I will test if that works. Each customer has its own /etc directory, so we can populate this file for each customer. Yet, I have to make sure that all the libraries/etc plays along.

k, thank you...

for directadmin I just dug into where it shows an IP as owned by a specific user:

/usr/local/directadmin/data/users/username/user.conf

the setting in that file is:
ip=72.23.52.42

if the bind.allow list was implemented in each customers /etc dir, they wouldnt be able to modify it correct?

I was thinking more along the lines of a global config file that the server admin sets as the allowed IP\'s

and then their owned ip gets grabbed from their assigned IP\'s in the control panel, otherwise many allow config files could be a pain for the server admin to maintain.

It is owned by root so user will not be able to modify it.
It is still running as user -- it is not a VPS.

Would this mean though if there was 200 user accounts and an admin wanted to add additional \"public non owned IP\'s\" to the /etc/bind.allow they would have to edit this in every single user account or are you saying we edit one allow file for all users?

this is actually easier then you think:
# cd /var/securelve
# for userhome in `ls`; do
# echo NEW_IP >> $userhome/etc/bind.allow
# done

Or something like that.
Yet, basically -- it will be up to control panels (or control panel plugins) to expose it to admin. We might add a script like:
# securelve_ip --add_shared NEW_IP
etc...
Yet, the mechanism looks feasable/configurable. The question is -- will virtualized /etc/bind.allow work...

Nice,

Also I am sure you have already thought of this but it is important to prevent people from binding to the interface: 0.0.0.0

--Stephen