小さな問題トレンドマイクロredirfsモジュール

最近読ん一つの問題、メッセージキューを作成することができますが、プロパティを取得することはできません、エラーが返されないメッセージ、：EBADF不正なファイルディスクリプタ

RBIの後、このプロセスに確認しました：

SYSCALL_DEFINE3（mq_getsetattr、mqd_t、mqdes、
         CONST  構造体 mq_attrの__user * 、u_mqstat、
         構造体 mq_attr __user * 、u_omqstat）
{ 
    int型RET。
    構造体mq_attr mqstat、omqstat。
    構造体のfd F;
    構造体のinode *のiノード。
    構造体 mqueue_inode_info * 情報。

    もし（！u_mqstat = NULL）{
         場合（copy_from_user（＆mqstat、u_mqstat、はsizeof（構造体mq_attr）））
             のリターン - EFAULT。
        もし（mqstat.mq_flags＆（〜O_NONBLOCK））
             リターン - EINVAL; 
    } 

    F = （mqdesによって）fdget;
     IF（！{f.file）
        RET = - EBADF;
         GOTO  OUT ; 
    } 

    iノード = file_inode（f.file）;
     IF（そう（f.file-> f_op =＆！mqueue_file_operations））{誤った結果として、--------このブランチを行く
        RET = - EBADF;
         GOTOはout_fput; 
    }

この分岐判断は、メッセージキューであることから、その後、[ファイル] - > [f_opはmqueue_file_operationsする必要がありますので、それは、また、問題ありません理にかなっています。

静的 INT do_dentry_open（構造体ファイル*のF、
               INT（*オープン）（構造体 iノード*、構造体のファイル* ）、
               CONST  構造体のcred * CRED）
{ 
... F - 

    > f_op = fops_get（inode-> i_fop）。
}

alloc_inodeプロセスによると：

静的 構造体（iノード*のalloc_inode 構造体 super_block * SB）
{ 
。。。。

    IF （そうもない（inode_init_always（SB、iノード）））{ 
。。。。
} 

のInt inode_init_always（構造体 super_block SB *、構造体のinode * iノード）
{ 
... 
    iノード - > i_op =＆のempty_iops; ----------のデフォルト設定
    inodeを - > i_fop =＆no_open_fops; --- ----初期設定のデフォルト
... 
}

通常の状況ではmq_open - > mqueue_create - > mqueue_get_inodeがでます

inode-> i_fop =＆mqueue_file_operations。

場合do_dentry_openは、対応F-> f_op = fops_get（inode-> i_fop）なるように、

それは通常通りfile.f_opです。

構造体file.f_op ffff883f53079500 
  f_op = 0xffffffff81690fa0 <mqueue_file_operations>

mqueue_file_operations = $ 1 = {
所有者= 0x0の、
llseek = 0xffffffff811e00d0 <default_llseek>、
読み取り= 0xffffffff81278220 <mqueue_read_file>、
書き込み= 0x0の、
aio_read = 0x0の、
aio_write = 0x0の、
READDIR = 0x0の、
ポール= 0xffffffff812781a0 <mqueue_poll_file>、
unlocked_ioctl = 0x0の、
compat_ioctl = 0x0の、
のmmap = 0x0の、
オープン= 0x0の、
フラッシュ= 0xffffffff812790f0 <mqueue_flush_file>、
リリース= 0x0の、
FSYNC = 0x0の、
aio_fsync = 0x0の、
fasync = 0x0の、
ロック= 0x0の、
sendpage = 0x0の、
get_unmapped_area = 0x0の、
check_flags = 0x0の、
群れ= 0x0の、
splice_write = 0x0の、
splice_read = 0x0の、
{
setlease = 0x0の、
__UNIQUE_ID_rh_kabi_hide5 = {
setlease = 0x0の
}、
{<いいえデータフィールド>}
}、
fallocate = 0x0の、
show_fdinfo = 0x0の
}

：次のように異常な状況下で、file.f_op

構造体 file.f_op 0xffff883e8d075b00 
  f_op = 0xffff883ba95251b8

構造体file_operations {
所有者= 0x0の、
llseek = 0xffffffff811e00d0 <default_llseek>、
= 0xffffffff81278220 <mqueue_read_file>、読み取り
書き込み= 0xffffffffa04e97f0 <rfs_write>、-------------- redirfs模块修改的
aio_read = 0x0の、
aio_write = 0x0の、
READDIR = 0x0の、
世論調査= 0xffffffff812781a0 <mqueue_poll_file>、
unlocked_ioctl = 0x0の、
compat_ioctl = 0x0の、
のmmap = 0xffffffffa04e9380 <rfs_mmap>、--------------- redirfs模块修改的
オープン= 0xffffffffa04ea3a0 <rfs_open>、--------------- redirfs模块修改的
フラッシュ= 0xffffffff812790f0 <mqueue_flush_file>、
リリース= 0xffffffffa04e9d50 <rfs_release>、--------- redirfs模块修改的
にfsync = 0x0の、
aio_fsync = 0x0の、
fasync = 0x0の、
= 0x0の、ロック
sendpage = 0x0の、
get_unmapped_area = 0x0の、
check_flags = 0x0のは、
= 0x0の、群れ
splice_write = 0x0の、
= 0x0のsplice_readを、
{
setlease = 0x0の、
__UNIQUE_ID_rh_kabi_hide5 = {
setleaseは= 0x0の
}、
{<いいえデータフィールド>}
}、
fallocate = 0x0の、
show_fdinfo = 0x0の
}

このモジュールは、redirfsに変更され、トレンドマイクロでは、通常のファイルのオープン、ちょうどfile.f_opをチェックし、そのサービスをフィルタリングするために使用されるように見えるカーネルモジュールは、NULLされていないが、msgqueueの詳細です検査、要件を満たしていないにつながります。

lsmodのは| grepを- 私はredirfs 
redirfs                 79430   1 gschの

はlsmod | grepのを- 私はgsch 
gsch                    93171   8 
redirfs                 79430   1 gsch 


redirfs探し
の/ opt / ds_agentを/ 3.10。0 - 229.11。1 .el7.x86_64 / redirfs.ko

この問題が、傾向は、直接この問題を回避するsys_call_table最も暴力的な方法を変更するために使用することができます。

0xffffffffa0514cf0 <gsch_write_hook_fn>
  0xffffffffa0516a80 <gsch_open_hook_fn>
  0xffffffffa05158a0 <gsch_close_hook_fn>
  0xffffffffa0514dd0 <gsch_pwrite64_hook_fn>
  0xffffffffa0514ec0 <gsch_writev_hook_fn>
  0xffffffffa0515a80 <gsch_dup2_hook_fn>
  0xffffffffa05149a0 <gsch_exit_hook_fn>
  0xffffffffa0514fa0 <gsch_unlink_hook_fn>
  0xffffffffa0514940 <gsch_getpgid_hook_fn>
  0xffffffffa0514a20 <gsch_exit_group_hook_fn>

しかし、これはsys_call行わ多くの機能カーネルモジュールを変更すると、そのようなバグのロード順の存在により、すべてのこれらの年後、明らかにあまりにも侵襲的です。

この仮定は、我々は補助機能redirfs完了するには、このフィルタを使用することで、それを変更する方法をすべきですか？判決のmqueue_file_operationsのかなりの数は、ポインタを置くので裁判官は、それを削除しました

MQを開始し、ほぼすべてのシステムコールを改ざんする必要がある、それは良い方法は、それからフィルタリングこのファイルタイプは、バック問題、なぜmsgqueueトレンドの原点に、存在しないようですか？

ます。https：//www.cnblogs.com/10087622blog/p/10983946.htmlで再現

小さな問題トレンドマイクロredirfsモジュール

おすすめ