perlモジュールはだいたいインストール方法変わらないので、SBoのスクリプトのバージョンだけ書き換えでなんとかなるかな
perlモジュールはだいたいインストール方法変わらないので、SBoのスクリプトのバージョンだけ書き換えでなんとかなるかな
$ ls /var/lib/pkgtools/packages | grep _SBo$ | grep perl | wc -l
26
時計メーカーが出してるNTPサーバーとか置きたいけど、お高い上にNICT以上の精度が出るわけでもないと思うので保留
びわそーしゃるのTOTPなんか時々失敗するなと思ったら、25secもずれてた
あー、どっちかっていうと、smb://とかのURLっぽいやつをよろしくやってくれるサービスって方が正しいのか(ふわふわ
gvfsってファイルマネージャからリムーバブルディスクマウントしたりするサービスじゃなかったっけ
若干問題があるとすると、カードリーダーが繋がってると、SmartCard挿さってなくても、GPGがそっち見に行っちゃうらしく、YubiKeyが使えなくなること
PGP SmartCardに秘密鍵書き込んでる夢見たけど、起きたらFactory Resetしただけだった
ANDROID CONCEPT - ゆうぐれさんぽうぇぶ！ - BOOTH - https://booth.pm/ja/items/3815076
# slackpkg show-changelog
Wed Apr 27 21:43:51 UTC 2022
patches/packages/curl-7.83.0-x86_64-1_slack15.0.txz: Upgraded.
This update fixes security issues:
OAUTH2 bearer bypass in connection re-use.
Credential leak on redirect.
Bad local IPv6 connection reuse.
Auth/cookie leak on redirect.
これか
というか、SuExecが有効だから、ユーザーのcgi-binが侵害されれば、apacheユーザーの権限どころか、ユーザー自身の権限で自由に動けるわけですし
この場合、apacheユーザーは全ユーザーの少なくともホームディレクトリにはアクセス出来るし、umask=0022の場合、パスさえ分かればホームディレクトリ以下の任意のファイルが読めることになる
https://wiki.archlinux.jp/index.php/%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E5%88%B6%E5%BE%A1%E3%83%AA%E3%82%B9%E3%83%88#.E3.82.A6.E3.82.A7.E3.83.96.E3.82.B5.E3.83.BC.E3.83.90.E3.83.BC.E3.81.AB.E3.83.97.E3.83.A9.E3.82.A4.E3.83.99.E3.83.BC.E3.83.88.E3.81.AA.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.81.AE.E5.AE.9F.E8.A1.8C.E6.A8.A9.E9.99.90.E3.82.92.E4.B8.8E.E3.81.88.E3.82.8B
先週ぐらいに悩んでた、ApacheのUserDirとホームディレクトリのパーミッションの問題、これで良い気がする
お仕事忙しい時、寝る前に飲む疲労回復系のドリンクよく飲んでたんだけど、これって結局ビタミン補給だよな……って思って、ビタミン剤飲んで寝る習慣になった
suexecの実行ユーザーチェックを迂回出来る場合の対策で、そもそも実行ユーザーのグループ以外はsuexecを実行できないようにする感じ
Apacheのwebサイトにあるアドバイスに従って、
chgrp apache /usr/sbin/suexec
chmod 4750 /usr/sbin/suexec
もやってる
> AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
おっけー
実はパスワード忘れてアクセス手段がないので、amelia.loquat.moeを落として、HDD引っこ抜いて更新します
とりあえず残ってる4/6までのログにはadmin.cgiへのアクセスはなし
一応、XSSは手前にあるmodsecurityで弾いてくれるはずですが
JVN#59576930: ぜろちゃんねるプラスにおけるクロスサイトスクリプティングの脆弱性 - https://jvn.jp/jp/JVN59576930/
This account is not set to public on notestock.
This account is not set to public on notestock.
ログの書き込み量が結構多いので、これだけ何とかしないといけなそうだけども
明日の朝起きて、サーバーが何かヤバいことになってなければ、とりあえず良しとする
そういえば、とりあえず投稿は受信出来てるのは確認できるけれど、このサーバーの投稿が送信出来てるかどうかは確認してない
daemonコマンドでバックグラウンド動作も完璧になったので、完璧です
こういう時に、別インスタンスにアカウントがあった方が良いかも、となる
で、更にビルドスクリプトのconfigureオプションに--with-uuid=osspを追加する必要がある
PG_EXTENSIONS=ALL でpg_trgmはビルドされるけど、uuid_osspの方は更にlibrareis/uuidが必要
Pleroma使う場合、pg_trgmとuuid_osspの拡張機能が必要だけど、SlackBuildそのままだとこの辺がビルドされない
localはpeer認証なので、これでPleroma実行ユーザーだけが安全、高速にデータベースに接続出来る
Pleroma - Postgres間をUnixソケットで繋ぐの出来た
Pleromaのビルド済みバイナリ使おうとしたら、なんかエラーが出た
とりあえずうちのサーバーは入れるにしても身内だけなので、諦めてumask 0022でhttpdから見られるようにして、どうしても見られたくないファイルは各自でパーミッション変えてねってことにする
とりあえずなんか難しい仕組みで動いてるっぽいことは分かったので、ここまでにしておこう
だと思っていたんだけど、少なくとも今見た感じでは、httpdをユーザー毎にユーザーの権限で起動することで、その制限を回避してる、っぽい
そして、大抵の場合、httpdは専用のユーザーで動いてるので、ホームディレクトリ内のファイル、例えば~/www/index.htmlみたいなのにアクセスするには読み取り権限が必要
httpdがホームディレクトリの所有者以外で動いてる場合は、その他読み取り権限がないとだめ
あと、ユーザーの権限でhttpdが動いてる
だからホームのパーミッションが0700でも見えるのか
プラン毎にサーバーが違うようなことが書いてあった気がするから、そういうのもあるかもしれない
シェルログインしてみたけど、こっちの環境だとrwx------だった
@kmy_myun そんな感じー
レンタルサーバーは複数のユーザーがひとつのサーバーを共有する都合上、どこかには共有してるユーザーの一覧が必要になるのよ
@kmy_myun こればかりは仕方なし……。
さくらに限らず、他のサーバーでもCGI置けるところなら、見ようと思えば見られる気もするし
で、私は他人のホームディレクトリが覗きたいわけでは勿論なくて、同じようなことを自分のサーバーでやろうとした場合の懸念点に対して、「ちゃんと」設定されたサーバーがどうやって対処しているかに興味があるだけ
@kanade_lab
確認ありがとうございます。
rwx---r-xだけ見ると中身まで見えそうですが、見えないんですね……。
何かしらの方法で所有者以外はアクセスできないように制限かけてるみたいですね。
/home/xxxはホームディレクトリなのであんまり他人から見えて欲しくない(umask 0027にしたい)、一方でその他ユーザーに最低限検索権限(o+x)は与えないと、httpdからアクセス出来ないという
@kanade_lab
あー、やっぱり見えますよね、そこから更に/home/他人のIDの中が見えるのかが気になってます。
見えないと多分コンテンツを公開できないのですが、一方で他人のホームが見えちゃって良いのかという部分もあり……
さくらとかでシェルログイン付きのサーバー借りて、どうやって管理してるか見てみれば良いのか
じゃあ、ホームディレクトリのアクセス権を制限しつつUserDirで公開するのは難しいのか
> S_IXUSR (00100)
> 所有者による実行 (execute) / 検索 (search) (「検索」はディレクトリに対して適用されるもので、 そのディレクトリ内のエントリーへアクセスできるかを意味する)
https://linuxjm.osdn.jp/html/LDP_man-pages/man2/chmod.2.html
ホームディレクトリのパーミッションが0750とかだとhttpdからアクセス出来無い……？
あとIMAPでSTARTTLS必須にしてるのが理解出来なくてそのまま認証通そうとして拒否られてるっぽいのとか
sshdで公開鍵認証必須にしてるのにパスワード認証でやって来て門前払いされてるとか
ただ、現状だと攻撃が成立してない場合が多くて、そもそもfail2banに引っ掛かることがあんまりない
スマホからサーバーにアクセス出来るようになったので、暇つぶしが出来る
FTPSとSFTPってどっちが先なんだろうと思ったら、どっちも1997っぽい
STARTTLS付きのFTPはFTPSなのか
その場合、待ち受けは21なのか990なのか
こんな感じのことを自動で出来れば良いはず
# mkdir -pv /srv/ftp/jail/$USER/$USER
# mount --bind /home/$USER /srv/ftp/jail/$USER/$USER
# chroot /srv/ftp/jail/$USERどうしても書き込み可能で安全にchrootさせたい場合は、ユーザー毎に2階層のディレクトリにして、1階層目は書き込み権限無くした上で、1階層目にchrootさせれば良いかな？
chrootする目的はログイン後にホームディレクトリより上の階層にアクセスさせない為だけど、うちのサーバーの場合は、シェルアクセスも許可してるから、あんまりそこに拘る理由はないことに気付いた
chrootした後、余計なことする前に一般ユーザーに権限落とせたりはしないんだろうか
で、サーバーはroot権限で動いてたりするから、最悪の場合はrootでの任意コード実行が出来ちゃう
chrootした後のディレクトリにetc/nsswitch.confみたいなファイルを置くことで、libcとかが/etc/nsswitch.confとして読み込んで、そこから更に、lib/libnss_*.soみたいなライブラリが動的にロードされる、みたいなことが出来るかららしい
FTPサーバー(vsftpd)で書き込み可能なディレクトリにchrootするように設定すると警告が出るんだけど、それがなんでって話
security - vsftp: why is allow_writeable_chroot=YES a bad idea? - Server Fault - https://serverfault.com/questions/743949/vsftp-why-is-allow-writeable-chroot-yes-a-bad-idea
1. PAM有効化してリビルドする
2. デフォルトでPAMが有効になってる別のパッケージを使う
FTPサーバーにログイン出来なくて半日ぐらい頭捻ってたけど、そもそもPAMが無効でビルドされてた
サーバーにポートスキャンかけたらSMTPだけ開いてなくて、なんでだと思ったら、クライアントの回線で規制掛かってるのか
そもそもSlackwareは公式で提供されてるのがMariaDBしかないのよね
fail2ban動かしてるけど、アタックが来ないせいで効いてるのか分からん
SASL認証とか、Submission関係は後でやろう、ミスってた場合怖いし
どっかのメルマガ→Twitter→Play Storeでアプリのダウンロードが3つぐらいされて、ネットワークエラーで止まってた
明日か明後日あたりで、構築と動作確認して、問題なさそうなら置き換え作業って感じかな
ほぼ全部の設定がhttpd.confに書いてあって戸惑うなどしたけど
多分この状態でssh開いたら、大変な気がするのでfail2ban入れるまでは我慢……
メールにせよhttpdにせよ、OS上にユーザー情報(もっと言えばホームディレクトリ)が無いと不便なんですもの
せっかくLDAP環境構築したのに、ほぼ全部のサービスがnss-pam-ldapd経由でアクセスしていて、これローカルユーザーでも良かったのでは？ってなってる
本来はこういう風に表示される(これはsystrayじゃないやつだけど)
あー、ひとつ思い当たるとすると、uim-toolbar-gtk-systrayの複数アイコンが上手く表示できないのが昔あった、今も同じかは分からない
Slackware 15.0(x86_64)
Xfce 4.16
UIM 1.8.8
で使えてる
それまでは繋がらないけど、Postfixとdovecotの設定でもしようか
ルーターの手前にスイッチングハブ置いて、そっから直接PPPoEで繋ごう、ファイアウォールはサーバーに任せよう
スパゲッティ状態のネットワークにサーバー足そうとしたら想像以上に苦労して泣いてる
今日の夢は延々と
$ getent passwd
の結果と睨めっこする夢だった
Postfix - OpenDKIM間をUNIXドメインソケットでやり取りさせようとしたら微妙に躓いてた
回線繋ぎ替えるとwww.loquat.moeに繋がらなくなるというなやみ
前に組んだ時はメールサーバーだけのサーバーだったから、virtual配送だったけど、今回はごちゃまぜサーバーだから、各ユーザーのホームディレクトリにlocal配送でも良さそうな気がしてる
まー、すぐ使うわけでもないし、後から追加できるだろうから、とりあえずナシでも良いっか
kdb5_ldap_utilがkdc.confから設定拾ってない疑惑
なんかkerberosの構築もそんな難しくなさそうだからとりあえずやってみる
nscdも設定した方が良いかなと思ったけど、LDAPがローカルにあるんだしとりあえずは不要だな
5本も要らないけど、必要になった時にまた2000円払うのはなんだかななので
GrapheneOSを信頼するんであれば、それが提供するSandbox機能も信頼すべきな気はする
まー、そんなこと言ったらvendor周りとかどうなのよって話なんだけども
プロプライエタリなサービスがバックグラウンドで動いてるのはなんとなく嫌というのはある
GrapheneOSとしては適切にアクセス制限したGMSをそのまま使えば良いじゃんって感じなんだと思うけども
