On Tue, Jan 15, 2002 at 05:01:11PM +0100, Olaf Dietsche wrote:
>
> this is a new file system to control access to system resources.
> Currently it controls access to inet_bind() with ports < 1024 only.
Just some minor notes from reading the source and docs:
- It somewhat collides with the Linux Security Module project
(http://lsm.immunix.org/). LSM is AFAIK very likely to be included
into kernel somewhere in the 2.5 timeframe, so I don't think your
accessfs in its current form will be included into 2.5. Also I don't
think it will be included into 2.4 some time, as it is rather
intrusive. This doesn't mean that I think your work is bogus, but
you should be warned that you will most likely have to maintain it
as a separate patch at least until you port it to LSM (which
probably will not be possible at least in the first phase of LSM -
read the discussions on "restrictive vs. authoritative hooks" in the
LSM mailinglist archives).
- CAP_NET_BIND_SERVICE is ignored completely. IMHO a process with this
capability should still be able to override the accessfs
permissions, otherwise enabling accessfs will break every setup
where CAP_NET_BIND_SERVICE is already used to give non-root
processes access to low ports. At least this should be mentioned in
the docs (and Configure.help entry!), as it means that you can't mix
the accessfs and the capability approach on a machine (e.g. if one
wants to migrate the services on the machine one for one). It also
breaks any network daemons that already use CAP_NET_BIND_SERVICE
internally (don't know of an example, but maybe there are some out
there).
- chown()ing a port to a uid provides this uid also with the ability
to pass on access privileges to others via chmod(). It could be
argued if it is more sensible to restrict changing privileges to
root (maybe CAP_NET_ADMIN is more appropriate?).
And some wishlist items:
- It would be nice if there were a way to distinguish between TCP and
UDP ports.
- IPv6 support would be nice. This raises the question what will
happen if a process has the privileges to bind a particular port
with IPv6 but not with IPv4 (IPv6 listeners take IPv4 connections
also). Is there any value in distinguishing IPv6 and IPv4 at all,
in particular if IPv6 gets into more widespread use in the future?
- Restricting access to certain high ports would be valuable. For
example many SQL server use those ports, and it would be nice if one
could prevent ordinary user processes from taking over their ports
in case the SQL daemon gets restarted or the like.
At least accessfs is a nice and expandable idea. Keep up the work :-)
Andreas
--
Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
---------------------------------------------------------
+49 521 1365800 - af@devcon.net - www.devcon.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jan 23 2002 - 21:00:17 EST