Greetings -
I have been testing BackupPC for my small office network, with BackupPC running from its own VM. The backups created by BackupPC are being put on a seperate mounted LVM partition (/bkupdata), rather than at /var/lib/BackupPC for the standard installation. I followed the BackupPC documentation for doing this, and everything was testing fine. I extended the logical volume and filesystem containing the /bkupdata partition to allow more room for all the expected backups after testing was completed. When I rebooted after extending the filesystem, I noticed that SELinux was doing a relabel on the filesystem. I didn't think anything of it until a few hours later when I accessed the BackupPC web interface and couldn't see the previous backups. After a fair amount of research about potential BackupPC specific causes, I was able to determine that the issue was SELinux related.
1. Everything worked properly (with the non-standard backup location) before the reboot and SELinux relabel. 2. Temporarily turning SELinux off (setenforce=0), and everything works again. 3. Turning SELinux on (setenforce=1), and I get errors from BackupPC web interface
I posted to the BackupPC mailing list yesterday, but have no responses from anyone with SELinux expertise, so I thought I should take my issue here. So in summary, here is what I have:
Backups are being stored on separate partition, not standard for BackupPC: /bkupdata
Standard BackupPC storage location: /var/lib/BackupPC
SELinux context on standard BackupPC storage location: [root@bacteria BackupPC]# pwd /var/lib/BackupPC [root@bacteria BackupPC]# ls -Z drwxr-x---. backuppc backuppc system_u:object_r:var_lib_t:s0 cpool drwxr-x---. backuppc backuppc system_u:object_r:var_lib_t:s0 pc drwxr-x---. backuppc backuppc system_u:object_r:var_lib_t:s0 pool drwxr-x---. backuppc backuppc system_u:object_r:var_lib_t:s0 trash
Current SELinux context on my BackupPC storage location: [root@bacteria bkupdata]# pwd /bkupdata [root@bacteria bkupdata]# ls -Z drwxr-x---. backuppc root system_u:object_r:default_t:s0 cpool drwx------. root root system_u:object_r:default_t:s0 lost+found drwxr-x---. backuppc root system_u:object_r:default_t:s0 pc drwxr-x---. backuppc root system_u:object_r:default_t:s0 pool drwxr-x---. backuppc root system_u:object_r:default_t:s0 trash
And one of the test clients backup location: [root@bacteria jab-opti755]# pwd /bkupdata/pc/jab-opti755 [root@bacteria jab-opti755]# ls -Z drwxr-x---. backuppc backuppc system_u:object_r:default_t:s0 0 drwxr-x---. backuppc backuppc system_u:object_r:default_t:s0 1 drwxr-x---. backuppc backuppc system_u:object_r:default_t:s0 2 drwxr-x---. backuppc backuppc system_u:object_r:default_t:s0 3 drwxr-x---. backuppc backuppc system_u:object_r:default_t:s0 4 drwxr-x---. backuppc backuppc system_u:object_r:default_t:s0 5 -rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 backups -rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 backups.old -rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 backups.save -rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 LOCK -rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 LOG.032013 -rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 XferLOG.0.z -rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 XferLOG.1.z -rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 XferLOG.2.z -rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 XferLOG.3.z -rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 XferLOG.4.z -rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 XferLOG.5.z -rw-r-----. backuppc backuppc system_u:object_r:default_t:s0 XferLOG.bad.z.old
In reviewing my SELinux contexts listed above, I noticed that the group assignment for the directories under /bkupdata is root. I have subsequently changed them to backuppc, and shutdown the backuppc service, shutdown and restarted the http service, then restarted the backuppc service. The same errors persist after this change, so the issue was not just with an incorrect group setting.
Here is a representative sample of the SELinux audit messages that are occurring:
----
time->Thu Mar 14 13:35:51 2013
type=SYSCALL msg=audit(1363293351.295:27283): arch=c000003e syscall=2 success=no exit=-13 a0=1437b70 a1=0 a2=1b6 a3=3c1711dbe0 items=0 ppid=1813 pid=4379 auid=4294967295 uid=496 gid=48 euid=496 suid=496 fsuid=496 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="BackupPC_Admin." exe="/usr/bin/perl" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1363293351.295:27283): avc: denied { read } for pid=4379 comm="BackupPC_Admin." name="backups" dev=vdd1 ino=4218673 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file
----
time->Thu Mar 14 13:35:51 2013
type=SYSCALL msg=audit(1363293351.292:27282): arch=c000003e syscall=2 success=no exit=-13 a0=1437b10 a1=0 a2=1b6 a3=3c1711dbe0 items=0 ppid=1813 pid=4379 auid=4294967295 uid=496 gid=48 euid=496 suid=496 fsuid=496 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="BackupPC_Admin." exe="/usr/bin/perl" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1363293351.292:27282): avc: denied { read } for pid=4379 comm="BackupPC_Admin." name="LOCK" dev=vdd1 ino=4194307 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file
----
time->Thu Mar 14 13:36:01 2013
type=SYSCALL msg=audit(1363293361.526:27285): arch=c000003e syscall=4 success=no exit=-13 a0=1630140 a1=1569130 a2=1569130 a3=21 items=0 ppid=1806 pid=4400 auid=4294967295 uid=496 gid=48 euid=496 suid=496 fsuid=496 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="BackupPC_Admin." exe="/usr/bin/perl" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1363293361.526:27285): avc: denied { getattr } for pid=4400 comm="BackupPC_Admin." path="/bkupdata/pc/jab-opti755/backups" dev=vdd1 ino=4218673 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file
----
I have read through the RedHat SELinux users guide and understand from this and looking at the above messages that my target context is probably not what it should be for this. I am hoping someone can guide me to get this corrected in a proper way without making a blanket permissive policy. Also I would like to make sure that if I have to expand my partition again, I don't want to have to go through the same pain of discovering the problem, or have it fixed so that the problem doesn't re-occur. If any additional information is needed please let me know.
Please CC me directly on any replies as I am only subscribed to the daily digest. Thanks.
Jeff Boyce Meridian Environmental www.meridianenv.com
On Fri, 2013-03-15 at 16:14 -0700, Jeff Boyce wrote:
In reviewing my SELinux contexts listed above, I noticed that the group assignment for the directories under /bkupdata is root. I have subsequently changed them to backuppc, and shutdown the backuppc service, shutdown and restarted the http service, then restarted the backuppc service. The same errors persist after this change, so the issue was not just with an incorrect group setting.
Here is a representative sample of the SELinux audit messages that are occurring:
The AVC denials all have some things in common:
1. the source type of the operation is httpd_t 2. the target type of the operation is default_t
httpd_t is the webserver process type.
default_t is a special type. This type is assigned to locations unknown to SELinux.
In this case SELinux is not aware of your exotic "/bkupdata" mountpoint.
Everything on a system is classified using types. That way SELinux knows if and what access it should grant to any given source.
So what you should do is, you should classify /bkupdata and the content in there by assigning it an appropriate type.
You should use the existing type for this.
So basically you should look at a existing location that is similar to your new location and consider using the same type.
There is a command that makes it easy to "clone" file contexts but it has its limits (you cannot nest them and so use them wisely)
I will give you one very simple example:
lets say that the /bkupdata is really just the same as /var but just in a exotic location. That would mean that you could clone the file contexts for /var and use them on /bkupdata as well.
man semanage has an example of how to use the fcontext uquivalent functionality:
# semanage fcontext -a -e /var /bkupdata # restorecon -R -v /bkupdata
That will make the contexts of bkupdata equivalent to that of /var
Remember though that you cannot nest them.
Its up to you to find the appropriate types to use. I do not know the properties of your /bkupdata location.
I can see a backup directory and i also see that httpd_t is trying to access content on your /bkupdata mountpount.
You may be able to fix this by just using the backupc_var_lib_t ( i am not even sure if that type exists) type for the whole mountpount:
semanage fcontext -a -t backuppc_var_lib_t "/bkupdata(/.*)?" restorecon -R -v -F /bkupdata
time->Thu Mar 14 13:35:51 2013
type=SYSCALL msg=audit(1363293351.295:27283): arch=c000003e syscall=2 success=no exit=-13 a0=1437b70 a1=0 a2=1b6 a3=3c1711dbe0 items=0 ppid=1813 pid=4379 auid=4294967295 uid=496 gid=48 euid=496 suid=496 fsuid=496 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="BackupPC_Admin." exe="/usr/bin/perl" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1363293351.295:27283): avc: denied { read } for pid=4379 comm="BackupPC_Admin." name="backups" dev=vdd1 ino=4218673 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file
time->Thu Mar 14 13:35:51 2013
type=SYSCALL msg=audit(1363293351.292:27282): arch=c000003e syscall=2 success=no exit=-13 a0=1437b10 a1=0 a2=1b6 a3=3c1711dbe0 items=0 ppid=1813 pid=4379 auid=4294967295 uid=496 gid=48 euid=496 suid=496 fsuid=496 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="BackupPC_Admin." exe="/usr/bin/perl" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1363293351.292:27282): avc: denied { read } for pid=4379 comm="BackupPC_Admin." name="LOCK" dev=vdd1 ino=4194307 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file
time->Thu Mar 14 13:36:01 2013
type=SYSCALL msg=audit(1363293361.526:27285): arch=c000003e syscall=4 success=no exit=-13 a0=1630140 a1=1569130 a2=1569130 a3=21 items=0 ppid=1806 pid=4400 auid=4294967295 uid=496 gid=48 euid=496 suid=496 fsuid=496 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="BackupPC_Admin." exe="/usr/bin/perl" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1363293361.526:27285): avc: denied { getattr } for pid=4400 comm="BackupPC_Admin." path="/bkupdata/pc/jab-opti755/backups" dev=vdd1 ino=4218673 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file
I have read through the RedHat SELinux users guide and understand from this and looking at the above messages that my target context is probably not what it should be for this. I am hoping someone can guide me to get this corrected in a proper way without making a blanket permissive policy. Also I would like to make sure that if I have to expand my partition again, I don't want to have to go through the same pain of discovering the problem, or have it fixed so that the problem doesn't re-occur. If any additional information is needed please let me know.
Please CC me directly on any replies as I am only subscribed to the daily digest. Thanks.
Jeff Boyce Meridian Environmental www.meridianenv.com
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Dominick -
Thanks for the education. Your advice was following the direction I was thinking to go, but that gave me confirmation that I was making the right decision. In the end I checked to see if there was a specific file context for BackupPC (#seinfo -t will list all the type contexts available). Since there was not a specific file context for BackupPC, I elected to apply the same context that is at the default BackupPC file storage location to my non-standard location at /bkupdata. So in the end this was solved by applying the following two commands:
#semanage fcontext -a -e /var/lib/BackupPC /bkupdata #restorecon -R -v /bkupdata
I then rebooted the system just to make sure that everything checks out after a reboot, and it works as expected. Thanks for your assistance.
Jeff Boyce Meridian Environmental www.meridianenv.com
----- Original Message ----- From: "Dominick Grift" dominick.grift@gmail.com To: "Jeff Boyce" jboyce@meridianenv.com Cc: "SELinux Fedora List" selinux@lists.fedoraproject.org Sent: Saturday, March 16, 2013 1:55 AM Subject: Re: Issue with SELinux and BackupPC backup directory at non-standard location
On Fri, 2013-03-15 at 16:14 -0700, Jeff Boyce wrote:
In reviewing my SELinux contexts listed above, I noticed that the group assignment for the directories under /bkupdata is root. I have subsequently changed them to backuppc, and shutdown the backuppc service, shutdown and restarted the http service, then restarted the backuppc service. The same errors persist after this change, so the issue was not just with an incorrect group setting.
Here is a representative sample of the SELinux audit messages that are occurring:
The AVC denials all have some things in common:
- the source type of the operation is httpd_t
- the target type of the operation is default_t
httpd_t is the webserver process type.
default_t is a special type. This type is assigned to locations unknown to SELinux.
In this case SELinux is not aware of your exotic "/bkupdata" mountpoint.
Everything on a system is classified using types. That way SELinux knows if and what access it should grant to any given source.
So what you should do is, you should classify /bkupdata and the content in there by assigning it an appropriate type.
You should use the existing type for this.
So basically you should look at a existing location that is similar to your new location and consider using the same type.
There is a command that makes it easy to "clone" file contexts but it has its limits (you cannot nest them and so use them wisely)
I will give you one very simple example:
lets say that the /bkupdata is really just the same as /var but just in a exotic location. That would mean that you could clone the file contexts for /var and use them on /bkupdata as well.
man semanage has an example of how to use the fcontext uquivalent functionality:
# semanage fcontext -a -e /var /bkupdata # restorecon -R -v /bkupdata
That will make the contexts of bkupdata equivalent to that of /var
Remember though that you cannot nest them.
Its up to you to find the appropriate types to use. I do not know the properties of your /bkupdata location.
I can see a backup directory and i also see that httpd_t is trying to access content on your /bkupdata mountpount.
You may be able to fix this by just using the backupc_var_lib_t ( i am not even sure if that type exists) type for the whole mountpount:
semanage fcontext -a -t backuppc_var_lib_t "/bkupdata(/.*)?" restorecon -R -v -F /bkupdata
time->Thu Mar 14 13:35:51 2013
type=SYSCALL msg=audit(1363293351.295:27283): arch=c000003e syscall=2 success=no exit=-13 a0=1437b70 a1=0 a2=1b6 a3=3c1711dbe0 items=0 ppid=1813 pid=4379 auid=4294967295 uid=496 gid=48 euid=496 suid=496 fsuid=496 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="BackupPC_Admin." exe="/usr/bin/perl" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1363293351.295:27283): avc: denied { read } for pid=4379 comm="BackupPC_Admin." name="backups" dev=vdd1 ino=4218673 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file
time->Thu Mar 14 13:35:51 2013
type=SYSCALL msg=audit(1363293351.292:27282): arch=c000003e syscall=2 success=no exit=-13 a0=1437b10 a1=0 a2=1b6 a3=3c1711dbe0 items=0 ppid=1813 pid=4379 auid=4294967295 uid=496 gid=48 euid=496 suid=496 fsuid=496 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="BackupPC_Admin." exe="/usr/bin/perl" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1363293351.292:27282): avc: denied { read } for pid=4379 comm="BackupPC_Admin." name="LOCK" dev=vdd1 ino=4194307 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file
time->Thu Mar 14 13:36:01 2013
type=SYSCALL msg=audit(1363293361.526:27285): arch=c000003e syscall=4 success=no exit=-13 a0=1630140 a1=1569130 a2=1569130 a3=21 items=0 ppid=1806 pid=4400 auid=4294967295 uid=496 gid=48 euid=496 suid=496 fsuid=496 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="BackupPC_Admin." exe="/usr/bin/perl" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1363293361.526:27285): avc: denied { getattr } for pid=4400 comm="BackupPC_Admin." path="/bkupdata/pc/jab-opti755/backups" dev=vdd1 ino=4218673 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file
I have read through the RedHat SELinux users guide and understand from this and looking at the above messages that my target context is probably not what it should be for this. I am hoping someone can guide me to get this corrected in a proper way without making a blanket permissive policy. Also I would like to make sure that if I have to expand my partition again, I don't want to have to go through the same pain of discovering the problem, or have it fixed so that the problem doesn't re-occur. If any additional information is needed please let me know.
Please CC me directly on any replies as I am only subscribed to the daily digest. Thanks.
Jeff Boyce Meridian Environmental www.meridianenv.com
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
When trying to perform an sftp operation we encounter a failure even in permissive mode. The syslogs during the failure are as follows
Mar 18 23:43:45 den-ccm-pub authpriv 3 sshd: pam_selinux(sshd:session): conversation failed Mar 18 23:43:45 den-ccm-pub authpriv 4 sshd: pam_selinux(sshd:session): No response to query: Would you like to enter a security context? [N] Mar 18 23:43:45 den-ccm-pub authpriv 3 sshd: pam_selinux(sshd:session): Unable to get valid context for sftpuser Mar 18 23:43:45 den-ccm-pub authpriv 6 sshd: pam_unix(sshd:session): session opened for user sftpuser by (uid=0) Mar 18 23:43:45 den-ccm-pub authpriv 6 sshd: User child is on pid 5853 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug3: mm_request_receive entering Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: PAM: establishing credentials Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: permanently_set_uid: 500/500 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug2: set_newkeys: mode 0 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug2: set_newkeys: mode 1 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: Entering interactive session for SSH2. Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug2: fd 4 setting O_NONBLOCK Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug2: fd 6 setting O_NONBLOCK Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: server_init_dispatch_20 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: server_input_channel_open: ctype session rchan 0 win 2097152 max 32768 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: input_session_request Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: channel 0: new [server-session] Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug2: session_new: allocate (allocated 0 max 10) Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug3: session_unused: session id 0 unused Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: session_new: session 0 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: session_open: channel 0 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: session_open: session 0: link with channel 0 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: server_input_channel_open: confirm session Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: server_input_global_request: rtype no-more-sessions@openssh.com want_reply 0 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug3: Wrote 52 bytes for a total of 2801 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: server_input_channel_req: channel 0 request env reply 0 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: session_by_channel: session 0 channel 0 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: session_input_channel_req: session 0 req env Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug2: Setting env 0: LANG=en_US.UTF-8 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: server_input_channel_req: channel 0 request subsystem reply 1 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: session_by_channel: session 0 channel 0 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: session_input_channel_req: session 0 req subsystem Mar 18 23:43:45 den-ccm-pub authpriv 6 sshd: subsystem request for sftp Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: subsystem: exec() internal-sftp Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug3: mm_audit_run_command entering command internal-sftp Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug3: mm_request_send entering: type 62 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug3: mm_request_receive_expect entering: type 63 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug3: monitor_read: checking request 62 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug3: mm_answer_audit_command entering Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug2: session_new: allocate (allocated 0 max 10) Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug3: session_unused: session id 0 unused Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug1: session_new: session 0 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug3: mm_request_send entering: type 63 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug3: mm_request_receive entering Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug3: mm_request_receive entering Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug2: fd 3 setting TCP_NODELAY Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug2: fd 9 setting O_NONBLOCK Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug2: fd 8 setting O_NONBLOCK Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug3: Copy environment: SELINUX_ROLE_REQUESTED= Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug2: fd 11 setting O_NONBLOCK Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug3: Copy environment: SELINUX_LEVEL_REQUESTED= Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug3: Copy environment: SELINUX_USE_CURRENT_RANGE= Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug3: channel 0: close_fds r -1 w -1 e -1 c -1 Mar 18 23:43:45 den-ccm-pub authpriv 7 sshd: debug3: Wrote 88 bytes for a total of 2889 Mar 18 23:43:45 den-ccm-pub authpriv 6 sshd: ssh_selinux_copy_context: setcon failed with Invalid argument Mar 18 23:43:45 den-ccm-pub authpriv 2 sshd: fatal: xfree: NULL pointer given as argument
The OpenSSH version on the system is openssh-clients-5.3p1-70.el6.x86_64 openssh-5.3p1-70.el6.x86_64 openssh-server-5.3p1-70.el6.x86_64
Here are the semanange login and user details
[root@den-ccm-sub1 remoteadmin]# semanage login -l
Login Name SELinux User MLS/MCS Range
__default__ unconfined_u s0-s0:c0.c1023
administrator admin_u s0-s0:c0.c1023
ccmservice specialuser_u s0
drfkeys specialuser_u s0
drfuser specialuser_u s0
informix specialuser_u s0
pwrecovery specialuser_u s0
remoteadmin remotesupport_u s0-s0:c0.c1023
root unconfined_u s0-s0:c0.c1023
sftpuser specialuser_u s0
system_u system_u s0-s0:c0.c1023
[root@den-ccm-sub1 remoteadmin]# semanage user -l
Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles
admin_u user s0 s0-s0:c0.c1023 sysadm_r system_r git_shell_u user s0 s0 git_shell_r guest_u user s0 s0 guest_r remotesupport_u user s0 s0-s0:c0.c1023 sysadm_r system_r root user s0 s0-s0:c0.c1023 sysadm_r system_r specialuser_u user s0 s0 sysadm_r system_r staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r sysadm_u user s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r unconfined_r unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0 user_r xguest_u user s0 s0 xguest_r
Here is the sshd process context system_u:system_r:sshd_t:s0-s0:c0.c1023 root 5012 1 0 Mar18 ? 00:00:00 /usr/sbin/sshd system_u:system_r:sshd_t:s0-s0:c0.c1023 root 30383 1 0 Mar18 ? 00:00:00 sshd: remoteadmin [priv] system_u:system_r:sshd_t:s0-s0:c0.c1023 668 30448 30383 0 Mar18 ? 00:00:00 sshd: remoteadmin@pts/0
Is this a known issue?
Thanks, Anamitra
On Tue, 2013-03-19 at 07:19 +0000, Anamitra Dutta Majumdar (anmajumd) wrote:
When trying to perform an sftp operation we encounter a failure even in permissive mode. The syslogs during the failure are as follows
Is this a known issue?
Thanks, Anamitra
This seems to be a default_context/pam issue.
Pam and SSH are not able to determine the login context for your user it seems.
Did you create a /etc/selinux/targeted/context/users/specialuser_u file with the appropriate default contexts?
On a slightly unrelated note:
It seems that the chroot/sftp functionality is broken.
One no longer logs in as chroot_user_t. Either this has changed or its broken.
If it has changed then why is there still policy for chroot_user_t?
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On 03/19/2013 09:57 AM, Dominick Grift wrote:
On Tue, 2013-03-19 at 07:19 +0000, Anamitra Dutta Majumdar (anmajumd) wrote:
When trying to perform an sftp operation we encounter a failure even in permissive mode. The syslogs during the failure are as follows Is this a known issue?
Thanks, Anamitra
This seems to be a default_context/pam issue.
Pam and SSH are not able to determine the login context for your user it seems.
Did you create a /etc/selinux/targeted/context/users/specialuser_u file with the appropriate default contexts?
Yes, how does this file look?
Also what does
# rpm -q selinux-policy
On a slightly unrelated note:
It seems that the chroot/sftp functionality is broken.
One no longer logs in as chroot_user_t. Either this has changed or its broken.
If it has changed then why is there still policy for chroot_user_t?
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Hi Miroslav,
Thanks for the prompt response.
I do not see a specialuser_u file at the location you specified.
All I see are the following
drwxr-xr-x. 2 root root 4096 Feb 4 13:55 . drwxr-xr-x. 4 root root 4096 Mar 5 12:19 .. -rw-r--r--. 1 root root 253 Nov 9 2011 guest_u -rw-r--r--. 1 root root 389 Nov 9 2011 root -rw-r--r--. 1 root root 514 Nov 9 2011 staff_u -rw-r--r--. 1 root root 578 Nov 9 2011 unconfined_u -rw-r--r--. 1 root root 353 Nov 9 2011 user_u -rw-r--r--. 1 root root 307 Nov 9 2011 xguest_u
And here are the versions of the selinux-policy rpm. [root@den-ccm-pub users]# rpm -qa | grep selinux-policy selinux-policy-targeted-3.7.19-126.el6.noarch selinux-policy-3.7.19-126.el6.noarch
Thanks, Anamitra
On 3/19/13 6:10 AM, "Miroslav Grepl" mgrepl@redhat.com wrote:
On 03/19/2013 09:57 AM, Dominick Grift wrote:
On Tue, 2013-03-19 at 07:19 +0000, Anamitra Dutta Majumdar (anmajumd) wrote:
When trying to perform an sftp operation we encounter a failure even in permissive mode. The syslogs during the failure are as follows Is this a known issue?
Thanks, Anamitra
This seems to be a default_context/pam issue.
Pam and SSH are not able to determine the login context for your user it seems.
Did you create a /etc/selinux/targeted/context/users/specialuser_u file with the appropriate default contexts?
Yes, how does this file look?
Also what does
# rpm -q selinux-policy
On a slightly unrelated note:
It seems that the chroot/sftp functionality is broken.
One no longer logs in as chroot_user_t. Either this has changed or its broken.
If it has changed then why is there still policy for chroot_user_t?
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
selinux@lists.fedoraproject.org
-
Anamitra Dutta Majumdar -
Dominick Grift -
Jeff Boyce -
Miroslav Grepl