Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/Ensuring security of my QNX installation/List of Posts
Forum Topic - Ensuring security of my QNX installation: (8 Items)
   
Update
ICT Tegema(deleted)
12/02/2015 9:28 AM
post115162
Ensuring security of my QNX installation   
I am currently reviewing the status of our QNX installation in terms of security and hackability and I am running into 
problems.

1. SSH connection by using RSA keys.
I want to secure my SSH connection by enforcing users to use a RSA key. For this, I have modified /etc/ssh/sshd_config 
on the target and changed the following lines:

RSAAuthentication yes
PubkeyAuthentication yes

and I did place my public key in /home/<USER>/.ssh/authorized_keys.
Inetd and Random are running.

However, when I connect to my target through Putty I get the message "Server refused our key". Can somebody say what I'm
 missing here? Is there any way to get log files from the SSH daemon?

2. Access rights of auto-start application
Once QNX is started, the IFS auto-start script in /.boot/ will run an executable that is located in a location that can 
be modified by non-root users. Note that placing the application by non-root users is a requirement for the system. Will
 this application get root-user access rights when called from my startup script? If so, this feels like a security 
thread to me. Is there any way I can set the access rights of the auto-started application to a user with less 
privileges?

Many thanks in advance.

Best regards,
Edward
Sean Boudreau(deleted)
12/02/2015 10:38 AM
post115165
Re: Ensuring security of my QNX installation   
Make sure the perms are correct:

# chmod 700 ~/.ssh
# chmod 600 ~/.ssh/known_hosts


On Wed, Dec 02, 2015 at 09:28:51AM -0500, ICT Tegema wrote:
> I am currently reviewing the status of our QNX installation in terms of security and hackability and I am running into
 problems.
> 
> 1. SSH connection by using RSA keys.
> I want to secure my SSH connection by enforcing users to use a RSA key. For this, I have modified /etc/ssh/sshd_config
 on the target and changed the following lines:
> 
> RSAAuthentication yes
> PubkeyAuthentication yes
> 
> and I did place my public key in /home/<USER>/.ssh/authorized_keys.
> Inetd and Random are running.
> 
> However, when I connect to my target through Putty I get the message "Server refused our key". Can somebody say what 
I'm missing here? Is there any way to get log files from the SSH daemon?
> 
> 2. Access rights of auto-start application
> Once QNX is started, the IFS auto-start script in /.boot/ will run an executable that is located in a location that 
can be modified by non-root users. Note that placing the application by non-root users is a requirement for the system. 
Will this application get root-user access rights when called from my startup script? If so, this feels like a security 
thread to me. Is there any way I can set the access rights of the auto-started application to a user with less 
privileges?
> 
> Many thanks in advance.
> 
> Best regards,
> Edward
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post115162
> To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com
Sean Boudreau(deleted)
12/02/2015 10:45 AM
post115166
Re: Ensuring security of my QNX installation   
Rather:

# chmod 700 ~/.ssh
# chmod 644 ~/.ssh/authorized_keys

You  might also want to add a 'umask 022' to your ~/.profile.
ICT Tegema(deleted)
12/03/2015 10:37 AM
post115181
Re: Ensuring security of my QNX installation   
Hi Sean,

Thank you for your reply.

I have tried:
# chmod 700 /root/.ssh
# chmod 644 /root/.ssh/authorized_keys
# umask 022 /root/.profile

But it did not work. Still my key is refused.

Note that I want to login under my root account and that the option "PermitRootLogin yes" is set in sshd_config.

What to try next?

Many thanks in advance!
Sean Boudreau(deleted)
12/03/2015 1:00 PM
post115189
Re: Ensuring security of my QNX installation   
And those file are owned by root:root?
Those setting work for me.

Does running '/usr/sbin/sshd -d' provide any
insight?

On Thu, Dec 03, 2015 at 10:37:34AM -0500, ICT Tegema wrote:
> Hi Sean,
> 
> Thank you for your reply.
> 
> I have tried:
> # chmod 700 /root/.ssh
> # chmod 644 /root/.ssh/authorized_keys
> # umask 022 /root/.profile
> 
> But it did not work. Still my key is refused.
> 
> Note that I want to login under my root account and that the option "PermitRootLogin yes" is set in sshd_config.
> 
> What to try next?
> 
> Many thanks in advance!
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post115181
> To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com
ICT Tegema(deleted)
12/04/2015 3:50 AM
post115208
Re: Ensuring security of my QNX installation   
Hi Sean,

Thank you again for your reply. Yes, everthing under /root is owned by root.

Running the SSH daemon in debug mode gave me the following output:

# /usr/sbin/sshd -d
debug1: Config token is protocol
debug1: Config token is logingracetime
debug1: Config token is permitrootlogin
debug1: Config token is passwordauthentication
debug1: Config token is permitemptypasswords
debug1: Config token is subsystem
debug1: HPN Buffer Size: 32768
debug1: sshd version OpenSSH_5.2 QNX_Secure_Shell-20090621
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on 0.0.0.0.
debug1: Server TCP RWIN socket size: 32768
debug1: HPN Buffer Size: 32768
Server listening on 0.0.0.0 port 22.
debug1: fd 4 clearing O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from 192.16.254.1 port 1813
debug1: HPN Disabled: 0, HPN Buffer Size: 32768
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.62
SSH: Server;Ltype: Version;Remote: 192.16.254.1-1813;Protocol: 2.0;Client: PuTTY_Release_0.62
debug1: no match: PuTTY_Release_0.62
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2 QNX_Secure_Shell-20090621-hpn13v6
debug1: permanently_set_uid: 15/6
debug1: MYFLAG IS 1
debug1: list_hostkey_types: ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug1: REQUESTED ENC.NAME is 'aes256-ctr'
debug1: kex: client->server aes256-ctr hmac-sha1 none
SSH: Server;Ltype: Kex;Remote: 192.16.254.1-1813;Enc: aes256-ctr;MAC: hmac-sha1;Comp: none
debug1: REQUESTED ENC.NAME is 'aes256-ctr'
debug1: kex: server->client aes256-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user root service ssh-connection method none
SSH: Server;Ltype: Authname;Remote: 192.16.254.1-1813;Name: root
debug1: attempt 0 failures 0
debug1: Config token is protocol
debug1: Config token is logingracetime
debug1: Config token is permitrootlogin
debug1: Config token is passwordauthentication
debug1: Config token is permitemptypasswords
debug1: Config token is subsystem
Failed none for root from 192.16.254.1 port 1813 ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 1 failures 0
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for root from 192.16.254.1 port 1813 ssh2
debug1: userauth-request for user root service ssh-connection method keyboard-interactive
debug1: attempt 2 failures 1
debug1: keyboard-interactive devs
debug1: auth2_challenge: user=root devs=
debug1: kbdint_alloc: devices ''

What goes wrong here? 

Many thanks in advance!
ICT Tegema(deleted)
12/09/2015 3:42 AM
post115248
Re: Ensuring security of my QNX installation   
So I have tried some things today again and I do believe I have it working now. It seemed that the public keys as 
generated by putty is not accepted by QNX. After removing the ---- BEGIN SSH2 PUBLIC KEY ----, ---- END SSH2 PUBLIC KEY 
---- and comment section and putting the key on one line, the SSH deamon accepts my key.

That means that there is still one question left:
Is my application run with Root access rights when it is started at startup and how secure is this situation?

Background:
My boot script (Located in /.boot/.boot) tries to call an application (located at /foo/bar). Users with non-root access 
rights are able to modify the application at /foo/bar for maintenance purposes. I don't want the user to give root 
access rights. How secure is this situation? If insecure, how to improve the boot procedure for the application?

Thanks in advance!
Sean Boudreau(deleted)
12/09/2015 8:57 AM
post115250
Re: Ensuring security of my QNX installation   
You can see what things are running as with 'pidin user'.
If it's root and doesn't need to be it's not as secure
as it could be.  You can have the app change its own
userid or start it via 'on -u <user> app' or if this
is the script from the build file via the uid / gid
attributes.  eg

[uid=5 gid=5] app

see the docs for mkifs

On Wed, Dec 09, 2015 at 03:42:00AM -0500, ICT Tegema wrote:
> So I have tried some things today again and I do believe I have it working now. It seemed that the public keys as 
generated by putty is not accepted by QNX. After removing the ---- BEGIN SSH2 PUBLIC KEY ----, ---- END SSH2 PUBLIC KEY 
---- and comment section and putting the key on one line, the SSH deamon accepts my key.
> 
> That means that there is still one question left:
> Is my application run with Root access rights when it is started at startup and how secure is this situation?
> 
> Background:
> My boot script (Located in /.boot/.boot) tries to call an application (located at /foo/bar). Users with non-root 
access rights are able to modify the application at /foo/bar for maintenance purposes. I don't want the user to give 
root access rights. How secure is this situation? If insecure, how to improve the boot procedure for the application?
> 
> Thanks in advance!
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post115248
> To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems