なにゆえ、そのような CD が作りたいのでしょうか？
デフォルトユーザからも管理権限を剥奪すると言うことは、それなりに使いづらいものになってしまうと思いますが・・・。
具体的にどのような用途(業務？)に使いたいのかを、差し支えない範囲でお書きになってはいかがでしょう。

一般ユーザには、事前に管理者がインストール及び設置を行い、それようの(制限された)ユーザを作成し(もしくは、ActiveDirectoryなどを参照するようにして)、利用者にはそれを使わせる　というのが一般的な方法かと思います。なぜ、そこにデフォルトユーザの話や、インストールの時の話しが絡んでくるのか　という点も説明があると、より希望に沿ったような回答が得られるのではないでしょうか。
# この辺は、Ubuntuだからどう、ということは無いと思います。

・Ubuntuの設定変更の不可
・制限されたユーザの消去or改変の不可

root権限が必要なので設定の変更は出来ないです。

・PC本体へのファイルダウンロードの不可

ユーザーのホーム以外は出来ないはずですが、ダウンロードの禁止は難しいかも。
インターネット接続の禁止なら大丈夫と思います。
この辺も、例えばファイルの保存を全面的に禁止するとかで対応するなど、千差万別なので具体的にユーザーは「PCを使って何をするのか」（＊＊を禁止するではなくて、＊＊のみ実行できる）の情報も有った方が良いかも。

「システム」→「システム管理」→「ユーザーとグループ」新規ユーザーを作成します。
「詳細設定」をクリック、「ユーザーの権限」タブを開き「システムの管理者である」にチェックを入れて終了。


パネル右上の「電源アイコン」に新規ユーザーが表示されているのでクリックしてログイン。

端末を開き
$ sudo nautilus /etc

ウィンドウが開きます、ここから先は全て同一ウィンドウで行って下さい。

新しいフォルダを作成して名前を「skel.backup」(何でも良い)とする。
skelフォルダを開いて「表示(V)」をクリック、「隠しファイルを表示する」にチェック。
全てを選択して「skel.backup」にペースト(張り付け)。
「システム」→「システム管理「→」「ユーザーとグループ」
ファイルブラウザ（ウィンドウ）の上部の上向きの矢印をクリックして'/'ディレクトリに移動して「home」→「ユーザー名」のフォルダを開きます。

ユーザー名は現在ログインしている新規に作成したユーザー名です。
書いていることが分かりにくければ端末から、
$ sudo nautilus $HOME


「デスクトップ」や「ダウンロード」等のフォルダが有りますので次の作業を全てのフォルダに行います。
右クリックで「プロパティ」を選択して「アクセス権」タブを開きます。
「所有者」「グループ」「その他」のアクセス権を全て「アクセスのみ」に変更します。

「表示(V)」をクリック、「隠しファイルを表示する」にチェック。
全てを選択してコピー。

ファイルブラウザ（ウィンドウ）の上部の上向きの矢印を2度クリックして'/'ディレクトリに移動して「etc」→「skel」のフォルダを開きます。
($ sudo nautilus /etc/skel )

skelフォルダに先程コピーした物を張り付け（プロパティを変更したフォルダ＆ファイル）。
同名のファイルを上書きするかどうか聞かれたら、全て上書き。

ログアウトしてインストールユーザーに戻ります。

「システム」→「システム管理」→「ユーザーとグループ」を開き、先程作成したユーザーを削除します。
削除する時に設定ファイルを残すかどうかの選択が有るので全て削除。


次回から作成するユーザーのホームは実行権限が無いホームが適用されます。

「詳細設定」をクリック、「高度な設定」タブを開きシェル(S)を「/bin/rbash」に変更します。



さて、これでどこまで望んでいる物に近づいたのかな（違う方向だったりして）？
もっと違う方法が有るかもしれませんが、、、、う〜ん、分かりません。

LiveCD、LiveDVD、LiveUSBをつかって、記憶ストレージは取り外す。
…なんて対処じゃ駄目？書けるから問題なのでしょ？
結構な制限をかけた上、アカウントは別で必要なんだろうか？
出力先がWebベースだったら端末側はブラウザが動けばいいだけで、そのWeb経由のシステムの方でアカウントなり管理すればいいんじゃないかと。
端末固有の設定は減るから楽できるように思うけども。
どの程度の処理をするかよるけれど、場合によっては光学ドライブだけでも十分なこともあるだろうし。
インストールしないといけない理由もあったりするんだろうか？

ただ、堅牢さってのは「誰が運用するか」によるとおもうし、設定で回避した場合、運用者は少なくとも制限を回避しようとする利用者よりも優秀であることは必須なのだけど大丈夫なのかな？
用途としてはシンクライアントでも入れた方が良さそうな気はするのだけど。

Crush による投稿:

用途としてはシンクライアントでも入れた方が良さそうな気はするのだけど。

＞＞Crushさん返信ありがとうございます。
ご指摘の通りだと思います。
シンクライアントを入れるという考え方も有効だと思います。
今回はインストールCDから通常インストールし、制限をかけたユーザを作成する事が目標にしています。
インストールCDのみで解決できない場合は、シンクライアントを入れるという手法をとりたいと思います。
私の考えの中にシンクライアントという考えも、知識もほとんど無かったので、こういった意見は非常に参考になります。ありがとうございます。

あーーー、、、、(続き)
例えば制限が施されたシェル「rbash」はコマンド「chsh」でユーザーが変更できますのでそれも制限しなければいけません。

それってパーミッションはコピーされるが、所有者は新しく作成されたユーザになって Nautilus で簡単に権限を変えることが出来るということになると思います。

そこから先も実行してね。（作業途中での経過、もしくは中断すればその通りですので最後まで実行してください）

Linux/Unixのシステムやそこで動くプログラムの多くは、ユーザのホームに設定ファイルを作成したり、それを変更できたりすることを前提に考えているものが多いので、ホームディレクトリ以下に書き込みできなくすると、なにかとトラブルの種になるのではないかと思います。そもそも所有者が自分であればモードの変更もできてしまいます。

あまり筋の良い手とは思いませんが、quotaをギリギリを狙って、ちょっと大きなファイルは置けないぐらいに設定してみるとか。
# ブラウザのキャッシュとかでトラブりそうな気はします。

まずは、達成したい目標を明確にする(再定義?)するところから始めた方がよいかも知れません。
使用者は全員guestアカウントで使用するような形式を考えているのか、
使用者毎にアカウントを発行するのか、
各PCに使用者毎にホームを作成するのか、
NFSとかを考えているのか、
そもそも使用者にホームディレクトリを(極力)使わせたくないのか、
PCの使用目的はなんであるのか、
インターネットからファイルをダウンロードさせたくないというところの真意はなんであるか、
極端な話ブラウザやメールを使う時点でなにかしらかはダウンロードしているわけで、ネットワークに接続しないというのは解に成り得るのか、
他にもあるかも知れませんが、ぱっと思いつくのはそんなところです。

aufs でパッケージを検索したら fsprotect を見つけました．

$ apt-cache show fsprotect
This is a set of scripts that make immutable the root and other filesystems.
Using aufs they pack a tmpfs filesystem and the filesystem forcing
changes to be written to the tmpfs.
.
The root filesystem is protected by an initramfs script. Other filesystems
are protected by an init script. All protected filesystems become read-only
ensuring their immutability even on power-offs.
.
This can be used for public computers to prevent damage or changes.

hir0 による投稿:

あーーー、、、、(続き)
例えば制限が施されたシェル「rbash」はコマンド「chsh」でユーザーが変更できますのでそれも制限しなければいけません。

>>hir0さん
返信ありがとうございます。
・rbashという制限つきのシェルを作成する。
・ログインシェルを変更することすらも制限をかける。
シェルから制限つきのユーザを作るという方法もあるのですね。
勉強になります。

Crush による投稿:

大事なことは「本来の目的の実現」で「それを想定し最初に思いついたことの実現」じゃないんだけども。
乗り越えられてしまうリスクと利便性はどちらが優先されるべきなんだろう？

＞＞Crushさん
返信ありがとうございます。
本来の目的の実現は最優先されるべきだと思います。
自分には無い知識・手法・考え方を教えていただくべく、皆さんに助けを求めています。
乗り越えられてしまうリスクと利便性についてどちらが優先されるべきかについては、現在の私の乏しい知識では判断することはできないと思っています。
今は、目的の実現のために可能性を広め、Ubuntuについての知識を深める時期だと思っています。