Camia wrote:I'm not a SElinux expert, so i used audit2allow command to allow these but i'm not sure if this is the right thing to do.
Looking for some expert advise.
SELinux is a mandatory access control security system that sits below traditional security.
What i am trying to say is that, most of the time, having SELinux on is better than not
So with that in mind, let me just say that this is the right thing to do.
However: Its not not the best thing to do.
What the bet thing to do is, depends on your requirements.
But let me just give a few quick pointers:
when stuff "writes" , or "creates" pay extra attention
when stuff "read" try to determine what it means for that process to be able to read that resource
Now i will briefly touch on your policy sinppets
- Code: Select all
module postfix 1.0;
require {
type var_t;
type procmail_t;
class file { read getattr open };
}
#============= procmail_t ==============
allow procmail_t var_t:file { read getattr open };
I do not know which file the process running in the procmail_t domain is reading, but if the file doesnt have any sensitive information
then allowing this is probably harmless. However the question is whether that target file should have been labeled with the var_t type in the first place
- Code: Select all
module sendmailpanel 1.0;
require {
type sendmail_t;
type var_t;
type system_mail_t;
type usr_t;
class file { write append };
}
#============= sendmail_t ==============
#!!!! This avc is allowed in the current policy
allow sendmail_t usr_t:file { write append };
#!!!! This avc is allowed in the current policy
allow sendmail_t var_t:file write;
#============= system_mail_t ==============
allow system_mail_t usr_t:file append;
allow system_mail_t var_t:file write;
The ones above are sub-optimal. usr_t type files are supposed to be readonly. these processes try to write to content that is
labeled with a readonly type, the same goes for the var_t type file. Rather than allowing your type to write append readonly type files, it would have been better if you labeled these objects more appropriatly (give then a writable type or a private type
also a note here that usr_t is a type for /usr and generic content in there. Try to avoid operations on generic content if possible/feasible since chances are that most stuff in /usr, and /var is generic , so by allowing interaction on generic content types you allow access to many files from a selinux point of view
- Code: Select all
module zendcache 1.0;
require {
type initrc_tmp_t;
type httpd_sys_script_t;
type tmp_t;
class file { setattr read lock write getattr unlink open append };
}
#============= httpd_sys_script_t ==============
allow httpd_sys_script_t initrc_tmp_t:file { getattr setattr };
#!!!! The source type 'httpd_sys_script_t' can write to a 'file' of the following types:
# httpd_sys_rw_content_t, httpd_tmp_t, httpdcontent
allow httpd_sys_script_t tmp_t:file { setattr read lock write getattr unlink open append };
the first rule above ( where the target is initrc_tmp_t) is not such a big problem because the target type is not a generic type and its not writing to it. It is however setting the attribute of that file. Chances are that there isnt a much better solution than the one you did
The second rule though, is sub-optimal. tmp_t is generic type for stuff in /tmp and /var/tmp , /usr/tmp . again avoid operation on generic types
on top of that, confined processes arent able to creates files with the generic tmp_t type. So it probably shouldnt have been there in the first place, or it was created by an unconfined process. Whatever the case, your webapp is trying to append, write to it and it wants to delete it . This signals to me that this webapp might have been able to create this file earlier ( it probably shouldh ave beenable to do so)
--------------------------------------------------------------------------
- Code: Select all
module deliverquota 1.0;
require {
type var_t;
type procmail_t;
class file { write create unlink link append };
class dir { write remove_name add_name };
}
#============= procmail_t ==============
#!!!! The source type 'procmail_t' can write to a 'dir' of the following types:
# var_spool_t, user_home_t, var_log_t, mail_home_rw_t, user_home_dir_t, mail_spool_t, tmp_t, nfs_t
allow procmail_t var_t:dir { write remove_name add_name };
allow procmail_t var_t:file { write create unlink link append };
-------------------
here are process running in the procmail_t domain is trying to create , and delete a file in a directory with the generic var_t type for /var and /srv. This is suboptimal, and it would probably been better if you are able to tell the process to create the file in a dir that iswritable to procmail_t type processes. Even if that is not possible then its still suboptimal to do this because your allowing the processes to create files with generic var_t type. In this case it would probably have been better to tell selinux that if procmail_t type processes create files in var_t type directories that the type of the to be created file should transition from var_t to some private type.
that way you wouldnt have to allow your procmail_t type process to write generic var_t files and you would add some protection to the file
------------------------------------------------------
- Code: Select all
module rc_actions 1.0;
require {
type tmp_t;
type usr_t;
type httpd_t;
type ndc_t;
type named_t;
class file { read ioctl append };
}
#============= httpd_t ==============
allow httpd_t tmp_t:file { read ioctl append };
#!!!! This avc is allowed in the current policy
allow httpd_t usr_t:file append;
#============= named_t ==============
allow named_t usr_t:file append;
#============= ndc_t ==============
allow ndc_t tmp_t:file { read append };
allow ndc_t usr_t:file append;
Thus is the same as a bove. its suboptimal to allow a process to "append" to read only file types (usr_t) or to append to generic tmp_t files
both usr_t/tmp_t types are generic by allowing your process to append to them, you allow it to append to more files than strictly needed
-----------------------------------------------------------------------
- Code: Select all
module sendmail 1.0;
require {
type httpd_sys_script_t;
type devlog_t;
type usr_t;
type sendmail_t;
type var_t;
class capability { setuid setgid };
class sock_file write;
class file { write append };
}
#============= httpd_sys_script_t ==============
allow httpd_sys_script_t devlog_t:sock_file write;
allow httpd_sys_script_t self:capability { setuid setgid };
#============= sendmail_t ==============
allow sendmail_t usr_t:file { write append };
allow sendmail_t var_t:file write;
apart from the last two rules which i explained earlier, the first two rules are suboptimal as well because the httpd_sys_script_t type is a generic process type for cgi scripts
so by allowing this you effectively give generic cgi scripts more permissions ( permission to write to syslog and to use getuid/setgid)
it would have been better to create a private cgi script domain for this webapp, so that you could give those permissions only to this cgi app and not all the other generic cgi scripts on the system
But again, what you did was better than no selinux at all.
if not optimal but its something.
to make it optimal you need to invest in learning how to communicate with selinux yourself rather than using the audit2allow translator
that way you can express yourself more clearely.
but also to make it optimal you need to learn the characteristics of the policy you are using
its the same with the law. if you want to make sure you arent breaking it. then you need to learn/userstand the law. because if you dont know the rules then you dont know how to play by the rules
