6:14 p.m.
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
3:55 a.m.
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
5:59 p.m.
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(a)gmail.com>
To: "Jeff Boyce" <jboyce(a)meridianenv.com>
Cc: "SELinux Fedora List" <selinux(a)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:
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(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
2:19 a.m.
New subject: SSH issue : ssh_selinux_copy_context: setcon failed with Invalid argument
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(a)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
3:57 a.m.
New subject: SSH issue : ssh_selinux_copy_context: setcon failed with Invalid argument
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
8:10 a.m.
New subject: SSH issue : ssh_selinux_copy_context: setcon failed with Invalid argument
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(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
--
selinux mailing list
selinux(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
11:17 a.m.
New subject: SSH issue : ssh_selinux_copy_context: setcon failed with Invalid argument
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(a)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(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>
> --
> selinux mailing list
> selinux(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
4056
days inactive
4060
days old
selinux@lists.fedoraproject.org
6 comments
4 participants
participants (4)
-
Anamitra Dutta Majumdar -
Dominick Grift -
Jeff Boyce -
Miroslav Grepl