The client suggests but the server chooses. The client sends a list of the cipher suites that it supports (and is willing to use). This list is supposed to be ordered by preference. The server responds by choosing one cipher suite in this list. Well-behaved servers try to follow the preferences of clients, but that's not really mandatory. Ultimately, the server chooses.
At the end of the handshake,
Finished messages are sent, which are encrypted and MACed with the negotiated secrets. The contents of these messages are hash values computed over the complete handshake messages, including the list of cipher suites supported by the client. This means that a MitM cannot alter that list without being caught at some point.
(However, this is not entirely true in the presence of TLS FalseStart: the client could be convinced to send his request with the weakest cipher suite that it supports. But the real weakness here would be that the client is then willing to support a weak cipher suite, not that a MitM attacker has some level of control in the choice of the cipher suite. Even with FalseStart, the external alteration by the attacker will be detected by the server and the request will not be honoured, let alone responded to.)
(SSLv2 did not include the list of cipher suites in its Finished messages and it has been much touted as one of the "big flaws" of SSLv2.)