Necesitamos una forma consistente, igualitaria, traspartente, segura por la cual se puedan crear nuevas cuentas en los servidores globales de IMC. Aqui hay algunos puntos que se discuten, que estan aqui para ser elaborados y explorados.

From these points, an Account Process draft is being developed and generalized. Offer whatever insight and modification you can.

Background

In San Fransisco many IMC people (majority of which were from the U.S.) met. I wanted to make it clear there that the method of operation that the tech team had been working under (as a growth of the rapid onslaught of demand and turn-around time) had been growing into a power structure that was unacceptable to the overall organization's (meaning the IMC) core. At that time things got done because certain people had access and certain people knew who to go to in order to get something done, it was a who you know sort of thing, instead of a sustainable process of involvement and transparancy. It was also the tech team making network-wide non-tech decisions. The message was heard and many of the decisions that the tech team had been making, have been organically growing into solid working groups (such as the new-imc working group). However, it is still true that a lot of the technical work gets done through the who-you-know system (which is really akin to the old-boys network), but this is changing. Lets help change this by creating an open and accountable Acceptable Usage Policy for machines that are collectively administered, and a process for account application and access granting.

Up to this point there has been a fairly loose method: a person has to do stuff for a while to get trust before getting an acct - on any box. Generally this means generating trust by doing work, like responding to imc-tech questions, or helping out on IRC, but this often seems to be an inpenetrable barrier to entry. Especially since this ends up meaning that if you know someone, or get to know someone, then you can get in.

Discussion Points

There are actually two related discussions to be had here - Account Creation and Account Deactivation

-- ChristopherMitchell - 06 Jun 2002

Machine usage policies

This email was written by Micah in April 2001. I don't remember if it passed IMC Tech process and was aproved.

You can read the whole email and all email in this tread on [[http://lists.indymedia.org/mailman/public/imc-tech/2001-April/003446.html] IMC Tech Malinglist Archives]].

-- PietroFerrari - 10 Jun 2002

Some things I can think of off the top of my head and some things that I pulled from the Debian Machine Usage Policy:

1. Password policy

  a. at the VERY least it should be a non-dictionary word - see NOTE 1.

  b. it should be changed with a certain amount of frequency (we can set up the accounts by using passwd -x which will give the password a certain amount of days which it is valid - this should be a systemwide policy, after MAX days, the password MUST be changed. If we also use the -w option users will get a certain amount of warning, for example if we use -w 7 users will get warnings starting a week before their password is to expire    

  c. in the case of individual accounts, it should not be given out to anyone else

2. Account usage policies

  a. Account expiration - if unused for X amount of time your account will go away/be disabled

  b. Home directory usage - files should not be stored here for a long time and should not take up very much room, old files which take up a lot of room will be subject to deletion for purposes of freeing up drive space.

  c. You may NOT login to the system from a public terminal and leave your session logged in, or let anyone use your login for any reason

  d. If you want to ftp in, you must not ssh in - although this will be resolved soon, I hope

  e. Don't by any willful, deliverate, reckless or unlawful act interfere with the work of other IMCs or jeopordize the integrity of data, networks, equipment, programs, or other stored information

  f. Don't use the IMC facilities for private financial gain, or for commercial purposes, for any work outside of the "officia;" duties or functions of IMC work, without specific discussion and agreement with the rest of the tech group.

  g. Do NOT use IMC facilities for unlawful activities, including, but not limited to, software piracy, hacking, or anything else. Doing so violates 2e.

3. General statements:

  a. Privlege - Access to the IMC machines is a privilege, not a right or a commercial service, and the larger technical group reserves the right to revoke this privilege at any time without prior notice, with proper explanation given.

4. Guarantees - there is NO guarantee of service, although everyone does their best to assure the proper functioning of everything, nothing can be guaranteed.

5. Privacy - If necessary to keep machines working properly, admins reserve the right to modify/edit user files (for example, editting a .forward file because it is causing mail loops), but for any other reason users files are private and not to be altered. Individual users are responsibile for ensuring that permissions on sensitive or private files are set so that others who should not access them cannot. If you have a file in your home directory that is called   WHERE_I_STASHED_A_MILLION_BUCKS_THAT_I_FOUND_ON_THE_STREET and have the read     permissions set so that others can read them, it is your fault, not anyone else's if your cash has been lifted...

6. Disk usage - If you receive an email notification that your homedir is large and that we need more space then please promptly take action. Other techs may find it necessary to clean up exceptionally large space users without warning.

7. Shell:

Please use ssh/scp if at all possible rather than less secure alternatives (rsh, telnet or FTP) - many of these are disabled and wont be enabled. Idle connections can be killed, an idle connection may mean that you are logged in from somewhere and forgot to logout, this compromises our security. Except for certain cases which should be communicated to the tech group try not to idle - if you have a reliably secure situation and need to be idle for a long time, that is fine, just let everone know this and why (for example, I have a console lock and I need to have a login on that runs the postal script to tame postgres, so I always will have one login that is idle).

8. Processes:

  a. Do not run any long running/intense process without previous discussion and agreement with the tech group.

  b. Running servers of any sort (this includes IRC bots) without prior discussion and permission from the tech group is also forbidden.

  c. Avoid running processes that are abusive in CPU or memory. If necessary SAs may reap processes, renice processes or kill them if necessary.

9. WWW pages:

  a. In general, web space on IMC machines is provided for the purpose of working on IMC webpages, or related to the project. Private or commercial pages on IMC machines are not permitted.

  b. Machines which are "mailservers" or otherwise not a webserver should not have webpages or web processes running at all.

10. Content:

    a. Your local IMC is responsible for the content of your WWW pages, including obtaining the legal permission for any works they include and ensuring that the contents of these pages do not violate the laws that apply to the location of the server.

    b. Posts which are posted to your newswire are not your direct responsibility - however it is up to your local IMC to determine what your local editorial policy is (even if it is "We don't have one") and act accordingly. We cannot possibily be responsible for something that someone posts, but issues related to this are your own local responsiblity and determination of how you will deal with it. The larger IMC, or any other individual IMC is NOT responsible for your content, your local IMC is responsible for any defamatory, confidential, secret, commercial, proprietary material on your pages.

    c. You are NOT allowed to, unless specifically contacted by and asked to do so - modify the content on any other IMC site, including posts, your access to the system is for work on your IMC site, many other IMCs would be more than happy if you helped them out, but please find out if they want your help and what help they need/want first. Do not update the code on their site, remove posts, etc. unless there is something obviously broken or someone has contacted your or the tech group (which you are a part of).

    d. You may NOT advertise on your IMC pages, banner ads or any other revenue generating mechanism. Sponsor lists are ok.

    e. You may NOT use the IMC systems, in any way (be it web, email or whatever) to advertise, bulk email, etc.

11. Mail/News:

    a. Using IMC machines for reading mail is NOT ok. We do not have the resources to be an ISP, to store mail and have not allocated for resources relating to reading email or news.

    b. Email should not be received AT any IMC machine - the acceptable email use is to have mail come into the mail server and be sent out from there to some other site where you read email.

    c. Using the machines to send out email is ok, if you need to, but it is recommended again that you use an offsite email program/setup. For discouragement of this no local mail reading/sending utilities will be installed. System mail programs (/bin/mail for example) are available and should be used for the most part in programs and web pages for sending out email, but not really personal email.

If a Developer becomes unreachable for a prolonged time their accounts, data and mail forwarding/filtering/etc may be disabled until they reappear.

12. Abuse - IMC machines may NOT be used for net abuse

Examples of what we consider net abuse:

Chain Letters and Ponzi Pyramid-Selling Schemes

Such messages work (or rather, don't work) in much the same way as their paper-based cousins. The most common example of this in email is MAKE-MONEY-FAST. In addition to being a waste of resources, such messages are illegal in certain countries.

Unsolicited Commercial Email (UCE)

Unsolicited Commercial Email is advertising material received by email without the recipient either requesting such information or otherwise expressing an interest in the material advertised. Since many Internet users use a dial-up connection and pay for their online time, it costs them money to receive email. Receipt of unsolicited commercial advertising therefore costs them money and is particularly unwelcome.

Unsolicited Bulk Email (UBE)

Similar to the above UCE but not attempting to sell anything. Its sole purpose is usually to annoy.

Forged headers and / or Addresses

Forging headers or messages means sending mail such that its origin appears to be another user or machine, or a non-existent machine. It is also forgery to arrange for any replies to the mail to be sent to some other user or machine.

Mail Bombing

Mail bombing is the sending of multiple emails, or one large email, with the sole intent of annoying and / or seeking revenge on a fellow Internet user. It is wasteful of shared Internet resource as well as serving no value to the recipient. Due to the time taken to download it, sending long email to sites without prior agreement can amount to denial of service, or access to email at the receiving site. Note that if binary attachments are added to mail this may increase the size considerably. If prior arrangement has not been made, the mail will be extremely unwelcome.

Denial of Service attacks

Denial of Service is any activity designed to prevent a specific host on the Internet making full and effective use of their facilities. This includes, but is not limited to:

Mail bombing an address in such a way to make their Internet access impossible, difficult, or costly.

Opening an excessive number of mail connections to the same host.

Intentionally sending email designed to damage the receiver's systems when interpreted; for example, sending malicious programs or viruses attached to an email.

Using a smarthost or SMTP relay without authorization to do so.

Mailing List Subscriptions

You must not subscribe anyone, other than a user on your own host, to a mail list or similar service without their permission.

Illegal Content

You must not send via email any item which it is illegal to send or possess.

Breach of Copyright or Intellectual Property

You must not send (via email) or post Copyright material or Intellectual Property unless you have permission to do so.

Excessive Cross-Posting

Simply put, this form of unacceptable behavior occurs when the same article is cross-posted to a large number of unrelated mailing lists.

Excessive Multi-Posting

Simply put, this form of unacceptable behavior occurs when a substantively similar (perhaps differing only in Subject header) article is posted to a large number of unrelated mailing lists.

NOTE 1: Password selection (from the passwd man page)

Compromises in password security normally result from careless password selection or handling. For this reason, you should select a password which does not appear in a dictionary or which must be written down. The password should also not be a proper name, your license number, birth date, or street address. Any of these may be used as guesses to violate system security.

Your password must easily remembered so that you will not be forced to write it on a piece of paper. This can be accomplished by appending two small words together and separating each with a special character or digit. For example, Pass%word.

Other methods of construction involve selecting an easily remembered phrase from literature and selecting the first or last letter from each. An example of this is

    Ask not for whom the bell tolls.

which produces

    An4wtbt.

You may be reasonably sure few crackers will have included this in their dictionary. You should, however, select your own methods for constructing passwords and not rely exclusively on the methods given here.

[huge re-format | all blame HfxBen]

-- GaBa - 06 Jun 2003