Re: Questions and suggestions

[bousch@topo.matups.fr (Thierry Bousch)]

Hello Elias,

> 1: Shouldn't all process files (in /proc) should have 644, not 600. So
> that any user can get full information on them?

This would be a security hole, since it would allow you to read all
memory attached to a process (and maybe plaintext passwords, for
instance). On the other hand, there should be some publicly available
information, like the running time and the amount of used memory, but it
isn't the case. Therefore, programs like `ps' and `top' should be made
setuid-root (which causes other security problems, of course).

> 2: A nice thing would be if you could change the mode-bits on the
> TOS-filesystem-directories (i.e. u:/c), otherwise, it is impossible to
> create a secure system. Since any user cn change, for example, teh
> mint.cnf file. I would like to set these directories to 700.

Julian Reschke has submitted a patch for MiNT 1.10, allowing chmod and
chown on TOS partitions; it works fine, and should be included in MiNT 1.11.

> 3: There are a number of system calls that _need_ to be superuser-only.
> The most important of these are of course Super() and Supexec(), because
> as long as any user can execute this instruction, the system can't be
> secure. Other super-only instructions include Dsp_Reset, Dsp_LoadProg,
> Jenabit, Setexec and other system calls that can crash the system.

The problem is that Supexec() is used in the startup code of the MiNT
libraries, to scan the cookie jar and determine whether MiNT is running.
Making Supexec() a privileged instruction would break all existing
gcc-compiled programs. 

> 4: For these things to work, we need a working setuid-flag of course. I
> was told that the setuid-flag is not yet implented, it it coming?

It is implemented and has been working for a long time.

> 6: What about implementing a SysV-style sticky-bit on directories? On
> SysV, when the sticky bit is set on a directory, you can't delete files
> in it even if you have write permission on the directory. You must have
> write permission to the file itself also.

Torsten Scherer has submitted a patch to handle the sticky bit in the
kernel, but this patch hasn't been integrated into MiNT. It worked,
anyway... Note that the RAMFS filesystem implements the sticky bit (as
well as the setgid bit) for directories.

> 8: Should a line be terminated by LF or CR/LF? Personally I don't like
> CR/LF. A good example is the lf-flag (in stty). There is no way that I
> can disable lf->cr/lf mapping because mintlib outputs the cr itself! And
> it's difficult to open stdout/stderr in binary mode.

This is a problem with the library, not with MiNT: the CRMODE flag only
applies to tty's. If you want all files (especially stdin and stdout) to
be opened in binary mode, you should add the following line in one of
your .c files:

	int __default_mode__ = _IOBIN;

> 9: There should be some kind of history for Setexec so that killing a
> process which changes the vbl-routine does not crash when killed.

This is tricky. A tentative solution would be to look for dangling
routines when a process terminates (i.e. routines which start in freed
space), and unlink them; but it would require to scan all interrupt and
exception vectors, and to follow them along the XBRA chain. Problems can
occur if this process, instead of hooking to an existant vector,
_installs_ a new interrupt routine (for instance, a printer spooler
could activate the Centronics interrupt source); maybe we could install
a `void' routine, which wouldn't do anything except reset the
appropriate MFP in-service-interrupts bits and return? Or simply ignore
this condition, after all people are not supposed to kill spoolers...

A more elegant solution would be to have an additional xbra_install()
system call, so that the kernel could be informed about new vectors;
these vectors would be automagically removed on termination (maybe
calling a user-defined "destructor" to remove the vector properly, if
this removing doesn't only consist in unlinking a hook, but maybe
resetting some MFP state, say). Comments?

Thierry.