In the default configuration the root folder is world-writable. This means
anyone may delete any folder or file in it, including /bin and /.boot!
To make the system a bit more secure and|or fool-proof one has two options:
I’m not sure if the first option does not have any adversary side to it,
so I did try to do “chmod a=rwxt /”. Nothing have broke so far.
Tony.
Tony <mts.spb.suxx@mail.ru> wrote:
In the default configuration the root folder is world-writable. This means
anyone may delete any folder or file in it, including /bin and /.boot!
Actually, you’ll probably find that can’t happen.
/.boot and /.altboot (as well as /.bitmap and /.inodes) can not be removed
from the filesystem.
/bin is a directory, and can not be removed until all contents of it are
removed, and /bin is not writeable by other, therefor, the contents can’t
be removed, therefor /bin can’t be removed.
Still /tmp looks like it could be removed if / has o+w, and that could
have unfortunate side-effects.
To make the system a bit more secure and|or fool-proof one has two options:
- removing the write permission for “others”;
Probably not a bad idea, anyway. In fact, look at the / for most of the
systems around here that are (still) running QNX4, they all seem to have
knocked down the write bit for other.
David Gibbs
QNX Training Services
dagibbs@qnx.com
On 6 Jan 2005 14:25:50 GMT, David Gibbs <dagibbs@qnx.com> wrote:
To make the system a bit more secure and|or fool-proof one has two
options:
- removing the write permission for “others”;
Probably not a bad idea, anyway.
Does this mean you do NOT advise using sticky bit?
Tony.
On 6 Jan 2005 14:25:50 GMT, David Gibbs <dagibbs@qnx.com> wrote:
In the default configuration the root folder is world-writable. This
means anyone may delete any folder or file in it, including /bin and
/.boot!
Actually, you’ll probably find that can’t happen.
/.boot and /.altboot (as well as /.bitmap and /.inodes) can not be
removed from the filesystem.
It will suffice to somehow touch or damage the /.license file to make me
enough headache…
(Actually I did not try this at home! But the possibility in itself makes
me anxious.)
I think of making all the users’ folders belong to root, put the sticky
bit on them on, let users access their’s folders via group permissions.
Then all the security related files like ~/.kshrc, ~/.profile ans SSH-1’s
~/.ssh (belonging to root now) would be protected more adequately then by
just disciplining the users…
Tony.
PS
Yes, QNX4 is a special purpose OS. If one wants the absolute level of
security - he should choose FreeBSD or some OS intended to confront the
perils of modern Internet environment (loosing the hard-realtime
properties on the way).
But still, if theese little tricks help making QNX4 installation more
robust against human and|or software error - why not to try them?!
Tony <mts.spb.suxx@mail.ru> wrote:
On 6 Jan 2005 14:25:50 GMT, David Gibbs <> dagibbs@qnx.com> > wrote:
To make the system a bit more secure and|or fool-proof one has two
options:
- removing the write permission for “others”;
Probably not a bad idea, anyway.
Does this mean you do NOT advise using sticky bit?
Well, it is an undocumented feature of the filesystem under QNX4.
I don’t know of any particular problems with it, but I also can’t
recommend it. And removing write permision should make the sticky
bit irrelevant.
David Gibbs
QNX Training Services
dagibbs@qnx.com
Tony <mts.spb.suxx@mail.ru> wrote:
On 6 Jan 2005 14:25:50 GMT, David Gibbs <> dagibbs@qnx.com> > wrote:
In the default configuration the root folder is world-writable. This
means anyone may delete any folder or file in it, including /bin and
/.boot!
Actually, you’ll probably find that can’t happen.
/.boot and /.altboot (as well as /.bitmap and /.inodes) can not be
removed from the filesystem.
It will suffice to somehow touch or damage the /.license file to make me
enough headache…
Yup. A world-writable / introduces many possible headaches.
I think of making all the users’ folders belong to root, put the sticky
bit on them on, let users access their’s folders via group permissions.
Then all the security related files like ~/.kshrc, ~/.profile ans SSH-1’s
~/.ssh (belonging to root now) would be protected more adequately then by
just disciplining the users…
Not what I would recommend. The normal (and expected) way is for each
user to own their home directory.
I’m not sure how your scheme helps vs the incorrect modification of a
file’s contents vs using normal user ownership permissions. Are you
thinking each user would be in a different group? You can do that
anyway – though it loses the level of groups that might share something.
David Gibbs
QNX Training Services
dagibbs@qnx.com
On 7 Jan 2005 17:44:45 GMT, David Gibbs <dagibbs@qnx.com> wrote:
I think of making all the users’ folders belong to root, put the sticky
bit on them on, let users access their’s folders via group permissions.
Not what I would recommend. The normal (and expected) way is for each
user to own their home directory.
Well, the shere fact that user IS ABLE to remove root-owned read-only
…profile file in his folder and replace it with whatever he wants -
strikes me! The same (or even worse) happens if user (or an intruder on
user’s behalf) is able to modify his SSH-1 keys…
(SSH-1 is not considered secure any more, SSH-2 allows to hide user’s keys
in user-inaccessible folder, but for performance reasons I use SSH-1 on
the installation. I know - it is not 100% paranoid, but an embedded system
rarely is CPU-rich, one has to go for the compromises…)
Are you thinking each user would be in a different group?
You can do that anyway – though it loses the level of groups that might
share something.
No, I test an environment where the users are grouped according to their
intended relationships with root-owned-sticky_bited home directories. So
far it did not encounter any inconviniencies.
The /home/user folder is “chmod root:usergroup drwxrwx–T” (the “other’s”
bits may be set to ones taste, keeping sticky bit ON).
Tony.
Tony <mts.spb.suxx@mail.ru> wrote:
On 7 Jan 2005 17:44:45 GMT, David Gibbs <> dagibbs@qnx.com> > wrote:
I think of making all the users’ folders belong to root, put the sticky
bit on them on, let users access their’s folders via group permissions.
Not what I would recommend. The normal (and expected) way is for each
user to own their home directory.
Well, the shere fact that user IS ABLE to remove root-owned read-only
.profile file in his folder and replace it with whatever he wants -
strikes me!
Actually, the .profile in his home directory is INTENDED to be modified
by each user. If you want stuff that is NOT so modified, you should be
using /etc/profile instead.
The $HOME/.profile that is put there during creation is a default one.
At startup, if the shell is a login shell, it will parse & execute:
/etc/profile
$HOME/profile
$ENV
The /etc/profile is intended to be the global, system wide,
non-user-modifiable stuff. The $HOME/profile is intended to
be the place for user-modifiable changes, it is where a user
is expected to start changing their login environment.
$HOME/profile usually specifies a ENV (traditional $HOME/.kshrc)
for further processing.
If you need to have per-user non-changeable customizations of the
shell, you would need to setup something that /etc/profile would
invoke… maybe a line in /etc/profile like:
… /etc/users_config/$LOGNAME.sh
The same (or even worse) happens if user (or an intruder on
user’s behalf) is able to modify his SSH-1 keys…
(SSH-1 is not considered secure any more, SSH-2 allows to hide user’s keys
in user-inaccessible folder, but for performance reasons I use SSH-1 on
the installation. I know - it is not 100% paranoid, but an embedded system
rarely is CPU-rich, one has to go for the compromises…)
I don’t know enough to comment on SSH-1 keys.
David Gibbs
QNX Training Services
dagibbs@qnx.com