VASD policy
by Vadym Chepkov
Hi,
I noticed just one vasd related entry found it's way into SELinux policy:
# grep vasd ./serefpolicy-3.7.19/policy/modules/system/authlogin.fc
/var/opt/quest/vas/vasd(/.*)? gen_context(system_u:object_r:var_auth_t,s0)
vasd is part of Quest Auth Services and I wonder if somebody already has a
policy defined for it or I have to start from scratch. Quest suggested to
disable SELinux, of cause.
Thanks,
Vadym
9 years, 4 months
priority between file context rules
by Vidalie Hervé
Hi,
I am trying to set contexts on httpd files on a server running CentOS release 6.4 (Final).
The server has several httpd running serving different hosts.
The directory tree is :
/WEBS/client_name/service_name/ contains configuration files, documents to serve, ...
/WEBLOGS/client_name/service_name/ contains httpd logs
/WEBDATA/client_name/service_name/ contains datas
Here are the rules I wrote :
[root@odbfi007v ~]# semanage fcontext -l | grep WEB
/WEBDATA/lost\+found(/.*)? all files system_u:object_r:lost_found_t:s0
/WEBLOGS(/.*) all files system_u:object_r:httpd_log_t:s0
/WEBLOGS/lost\+found(/.*)? all files system_u:object_r:lost_found_t:s0
/WEBS/[^/]+/[^/]+/conf(/.*)? all files system_u:object_r:httpd_config_t:s0
/WEBS/[^/]+/[^/]+/docs(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/WEBS/[^/]+/[^/]+/logs all files system_u:object_r:httpd_log_t:s0
/WEBS/lost\+found(/.*)? all files system_u:object_r:lost_found_t:s0
I would like to set a default type on /WEBS and his subfolders:
semanage fcontext -a -t httpd_sys_content_t '/WEBS(/.*)?'
restorecon -Rv /WEBS*
However, this command sets the type httpd_sys_content_t recursively on everything in /WEBS
What is the priority between file context rules? I thought more precise rules will prevail on others.
Regards,
Hervé
________________________________
Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
9 years, 5 months
Re: back to svn]
by mark
>> From: "Dominick Grift" <dominick.grift(a)gmail.com>
>> On Thu, 2013-11-14 at 17:45 -0500, m.roth(a)5-cent.us wrote:
>>> Dominick Grift wrote:
>>>> On Thu, 2013-11-14 at 17:01 -0500, m.roth(a)5-cent.us wrote:
>>>>> I really don't understand this:
>>>>> CentOS 6.4
>>>>> directory: user_t
>>>>> subdirectory: httpd_sys_content_t
>>>>> file: httpd_sys_content_t
>>>>>
>>>>> (Permissive mode)
>>>>> selinux preventing search access on the subdirectory by httpd.
>>>>>
>>>>> Is this a cascading issue, that selinux doesn't like apache trying to
>>>>> access something under usr_t?
<snip>
>> But you want optimal help then you should enclose the actual avc denial
>>
>> because now its all hearsay. i need to look at the facts to be able to
>> suggest something i can vouch for
Good thought. NOW I'm *really* confused.
ll -Z of the file gives me
-rw-r--r--. <user> <group> system_u:system_r:httpd_sys_content_t:s0 <file>
Meanwhile,
grep avc /var/log/audit/audit.log | grep <filename>
gets me:
<...>
type=AVC msg=audit(1384527075.382:7606586): avc: denied { read } for
pid=1329 comm="httpd" name="<filename>" dev=sdc1 ino=66691074
scontext=unconfined_u:system_r:httpd_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
"Unlabeled_t"?
mark
9 years, 6 months
Monitoring disk storage labeled with svirt_image_t
by Gabriele Pohl
Hi,
I use Munin plugin diskwatch to monitor a KVM-Host
and am getting AVC denials at access to logical volumes
labeled with type "svirt_image_t"
--------- snip ---------
Nov 15 14:33:10 servername setroubleshoot: SELinux is preventing
/usr/bin/perl from getattr access on the blk_file /dev/dm-2. For
complete SELinux messages. run sealert -l
2b08f291-13be-4b09-878a-96cccc4c336d
# sealert -l 2b08f291-13be-4b09-878a-96cccc4c336d
SELinux is preventing /usr/bin/perl from getattr access on the
blk_file /dev/dm-2.
***** Plugin restorecon (99.5 confidence) suggests *************************
If you want to fix the label.
/dev/dm-2 default label should be fixed_disk_device_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /dev/dm-2
--------- snip ---------
I setup the guests disk storage as logical volume.
And all of these are labeled with svirt_image_t as you see here:
# ls -lZ /dev/dm*
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-0
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-1
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-10
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-11
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-12
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-13
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-14
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-15
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-16
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-17
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-18
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-19
brw-rw----. qemu qemu system_u:object_r:svirt_image_t:s0:c119,c1011 /dev/dm-2
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-20
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-21
brw-rw----. qemu qemu system_u:object_r:svirt_image_t:s0:c119,c1011 /dev/dm-3
brw-rw----. qemu qemu system_u:object_r:svirt_image_t:s0:c272,c985 /dev/dm-4
brw-rw----. qemu qemu system_u:object_r:svirt_image_t:s0:c272,c985 /dev/dm-5
brw-rw----. qemu qemu system_u:object_r:svirt_image_t:s0:c224,c455 /dev/dm-6
brw-rw----. qemu qemu system_u:object_r:svirt_image_t:s0:c224,c455 /dev/dm-7
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-8
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-9
Should I really change the label or will that make problems for qemu?
Is it ok to grant access privileges to munin_disk_plugin_t ?
@drjohnson1: Will you then please add the following rules to SELinux
policy of munin-node:
--------------------------------
module diskwatch-pol 1.0;
require {
type svirt_image_t;
type munin_disk_plugin_t;
class blk_file getattr;
}
#============= munin_disk_plugin_t ==============
allow munin_disk_plugin_t svirt_image_t:blk_file getattr;
--------------------------------
Thanks for your advice and kind regards,
Gabriele
9 years, 6 months
SFTP & Chroot
by Jorge Fábregas
Hi,
I just configured the internal-sftp of sshd (with chroot option) but
when I tried to log on as the sftp user I can't. I get the following AVC:
setroubleshoot: SELinux is preventing /usr/sbin/sshd from getattr access
on the directory /var/ftp. For complete SELinux messages...
/var/ftp is a filesystem of its own labeled "public_content_t".
I really have no clue why this doesn't work. Apparently it's something
related to the "internal-sftp" which one needs to use in order to allow
the chroot environment. I could only make it work by enabling the
ssh_chroot_full_access boolean which seems overkill...
Is this boolean the only way to go with internal-sftp ?
Thanks,
Jorge
9 years, 6 months
use_ecryptfs_home_dirs boolean
by AndrewYang
Because Ecryptfs does not support xattr, so a variety of application control type under ecryptfs user home is replaced by ecryptfs_t. In the
serepolicy-3.12.1 version, The 'use_ecryptfs_home_dirs' Boolean control ecyprfs_t type under users encrypted directory. The Boolean control granularity is coarse, such as xserver, Mozilla, chrome applications setting policy, while related to the home user domain gives the
ecryptfs_t object to operate and manage permissions. In the configuration of the ecryptfs_t type to control encrypted user home directory method has following problems :
1> ecryptfs user home directory only ecryptfs_t type, can not be distinguished by type between different applications under the user home
directory, so that use_ecryptfs_home_dirs Boolean control permission is too big.
2> if user home directory add new applications, you will need to supplement the application policy of ecryptfs_t type, while not directly use the existing policy that is used under the unencrypted user home directory.
To solve these problems, I have a idea that we can use 'semanage fcontext' command to realize ecrytfs user home directory and unencrypted user home directory shared control policy.
Actually, using the ecryptfs user home directory is to operate the encrypted directory (/home/.ecryptfs/$USER_NAME/. Pravite) . The files under encrypted directory and ecryptfs mounted point directory (/home/$USER_NAME/) are one to one. With the following commands, the
ecryptfs user home directory (but filenames aren't be encrypted) can be labelled with the unencrypted user home directory security context.
# semanage fcontext -a -e /home/$USER_NAME /home/.ecryptfs/$USER_NAME/.Private# restorecon -RFv /home/.ecryptfs/$USER_NAME/.Private# restorecon -R -v /home/.ecryptfs/
The ecryptfs does not encrypt user home directory filenames and only encypted file contents case, this method can realize to use common user home directory policy, better than the existing 'user_ecryptfs_home_dirs' boolean control.
9 years, 6 months
Another perplexity: lost+found
by mark
CentOS 6.4
I have *no* idea how this happened - I didn't build this box, but I've got
two mounted filesystems, and lost+found on both of them is wrong.
drwx------. root root system_u:object_r:usr_t:s0 lost+found
semanage fcontext -a -t lost_found_t /export/1/lost+found
restorecon -v /export/1/lost+found
ll -Z /export/1
drwx------. root root system_u:object_r:usr_t:s0 lost+found
Clues for the poor?
mark
9 years, 6 months
back to svn
by mark
I really don't understand this:
CentOS 6.4
directory: user_t
subdirectory: httpd_sys_content_t
file: httpd_sys_content_t
(Permissive mode)
selinux preventing search access on the subdirectory by httpd.
Is this a cascading issue, that selinux doesn't like apache trying to
access something under usr_t?
mark
9 years, 6 months
