New fs to control access to system resources

Hi,

this is a new file system to control access to system resources. Currently it controls access to inet_bind() with ports < 1024 only.

With this patch, there's no need anymore to run internet daemons as root. You can individually configure which user/program can bind to ports below 1024.

For example, you can say, user www is allowed to bind to port 80 or user mail is allowed to bind to port 25. Then, you can run apache as user www and sendmail as user mail. Now, you don't have to rely on apache or sendmail giving up superuser rights to enhance security.

To use this, you need to mount the file system and do a chown on the appropriate ports:

# mount -t accessfs none /mnt
# chown www /mnt/net/ipv4/bind/80
# chown mail /mnt/net/ipv4/bind/25
...

You can grant access to a group for individual ports as well. Just say:

# chgrp lp /mnt/net/ipv4/bind/515
# chown g+x /mnt/net/ipv4/bind/515

... and you're done.

This patch is against 2.4.14, but it applies with offsets to 2.4.17 and 2.5.2 as well. However, I have built and tested 2.4.14 only.

Now, I would like to here from you, whether you find this useful or not, have any suggestions, objections ... please tell me. Of course, comments on the code are welcome too :-).

Thanks for your time.

Regards, Olaf.

diff -X dontdiff -urN v2.4.14/Documentation/Configure.help linux/Documentation/Configure.help
@@ -19179,6 +19179,34 @@
   To use this option, you have to check that the "/proc file system
   support" (CONFIG_PROC_FS) is enabled, too.
 
+Accessfs support (EXPERIMENTAL)
+CONFIG_ACCESS_FS
+  This is a new file system to control access to system resources.
+  Currently it controls access to bind() with ports < 1024 only.
+
+  With this file system, there's no need anymore to run internet daemons
+  as root. You can individually configure which user/program can bind to
+  ports below 1024.
+
+  For example, you can say, user www is allowed to bind to port 80 or
+  user mail is allowed to bind to port 25. Then, you can run apache as
+  user www and sendmail as user mail. Now, you don't have to rely on
+  apache or sendmail giving up superuser rights to enhance security.
+
+  To use this file system, you need to mount the file system somewhere
+  and do a chown on the appropriate ports:
+
+  # mount -t accessfs none /mnt
+  # chown www /mnt/net/ipv4/bind/80
+  # chown mail /mnt/net/ipv4/bind/25
+
+  You can grant access to a group for individual ports as well. Just say:
+
+  # chgrp lp /mnt/net/ipv4/bind/515
+  # chown g+x /mnt/net/ipv4/bind/515
+
+  If you're unsure, say N.
+
 #
 # A couple of things I keep forgetting:
 #   capitalize: AppleTalk, Ethernet, DOS, DMA, FAT, FTP, Internet, 

diff -X dontdiff -urN v2.4.14/fs/Config.in linux/fs/Config.in
@@ -78,6 +78,8 @@
 tristate 'UFS file system support (read only)' CONFIG_UFS_FS
 dep_mbool '  UFS file system write support (DANGEROUS)' CONFIG_UFS_FS_WRITE $CONFIG_UFS_FS $CONFIG_EXPERIMENTAL
 
+dep_bool 'Accessfs support (EXPERIMENTAL)' CONFIG_ACCESS_FS $CONFIG_EXPERIMENTAL
+
 if [ "$CONFIG_NET" = "y" ]; then
 
    mainmenu_option next_comment

diff -X dontdiff -urN v2.4.14/fs/Makefile linux/fs/Makefile
@@ -64,6 +64,7 @@
 subdir-$(CONFIG_REISERFS_FS)	+= reiserfs
 subdir-$(CONFIG_DEVPTS_FS)	+= devpts
 subdir-$(CONFIG_SUN_OPENPROMFS)	+= openpromfs
+subdir-$(CONFIG_ACCESS_FS)	+= accessfs
 
 
 obj-$(CONFIG_BINFMT_AOUT)	+= binfmt_aout.o

diff -X dontdiff -urN v2.4.14/fs/accessfs/Makefile linux/fs/accessfs/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the linux accessfs routines.
+#
+
+O_TARGET := accessfs.o
+obj-y := inode.o
+export-objs := inode.o
+
+include $(TOPDIR)/Rules.make

diff -X dontdiff -urN v2.4.14/include/linux/accessfs_fs.h linux/include/linux/accessfs_fs.h
@@ -0,0 +1,38 @@
+/* -*- mode: c -*- */
+#ifndef	__accessfs_fs_h_included__
+#define	__accessfs_fs_h_included__	1
+
+/* Copyright (c) 2001 Olaf Dietsche
+ *
+ * $Log$
+ */
+
+#include	<linux/fs.h>
+
+struct access_attr {
+	uid_t	uid;
+	gid_t	gid;
+	mode_t	mode;
+};
+
+struct accessfs_entry {
+	char	*name;
+	struct list_head	hash;
+	struct list_head	siblings;
+	ino_t	ino;
+	struct access_attr	*attr;
+};
+
+struct accessfs_direntry {
+	struct accessfs_entry	node;
+	struct accessfs_direntry	*parent;
+	struct list_head	children;
+	struct access_attr	attr;
+};
+
+extern int	accessfs_permitted(struct access_attr *p, int mask);
+extern struct accessfs_direntry	*accessfs_make_dirpath(const char *name);
+extern void	accessfs_register(struct accessfs_direntry *dir, const char *name, struct access_attr *attr);
+extern void	accessfs_unregister(struct accessfs_direntry *dir, const char *name);
+
+#endif

diff -X dontdiff -urN v2.4.14/net/ipv4/af_inet.c linux/net/ipv4/af_inet.c
@@ -116,6 +116,9 @@
 #if defined(CONFIG_NET_RADIO) || defined(CONFIG_NET_PCMCIA_RADIO)
 #include <linux/wireless.h>		/* Note : will define WIRELESS_EXT */
 #endif	/* CONFIG_NET_RADIO || CONFIG_NET_PCMCIA_RADIO */
+#ifdef CONFIG_ACCESS_FS
+#include <linux/accessfs_fs.h>
+#endif
 
 struct linux_mib net_statistics[NR_CPUS*2];
 

@@ -467,6 +470,10 @@
 	return(0);
 }
 
+#ifdef CONFIG_ACCESS_FS
+static struct access_attr bind_to_port[PROT_SOCK];
+#endif
+
 /* It is off by default, see below. */
 int sysctl_ip_nonlocal_bind;
 

@@ -503,7 +510,11 @@
 		return -EADDRNOTAVAIL;
 
 	snum = ntohs(addr->sin_port);
+#ifdef CONFIG_ACCESS_FS
+	if (snum && snum < PROT_SOCK && !accessfs_permitted(&bind_to_port[snum], MAY_EXEC))
+#else
 	if (snum && snum < PROT_SOCK && !capable(CAP_NET_BIND_SERVICE))
+#endif
 		return -EACCES;
 
 	/*      We keep a pair of addresses. rcv_saddr is the one

@@ -1101,6 +1112,21 @@
 	}
 }
 
+#ifdef CONFIG_ACCESS_FS
+static void	accessfs_init(void)
+{
+	struct accessfs_direntry *dir = accessfs_make_dirpath("net/ipv4/bind");
+	int i;
+	for (i = 1; i < PROT_SOCK; ++i) {
+		char	buf[sizeof("1023")];
+		bind_to_port[i].uid = 0;
+		bind_to_port[i].gid = 0;
+		bind_to_port[i].mode = S_IXUSR;
+		sprintf(buf, "%d", i);
+		accessfs_register(dir, buf, &bind_to_port[i]);
+	}
+}
+#endif
 
 /*
  *	Called by socket.c on kernel startup.  

@@ -1197,6 +1223,11 @@
 	proc_net_create ("tcp", 0, tcp_get_info);
 	proc_net_create ("udp", 0, udp_get_info);
 #endif		/* CONFIG_PROC_FS */
+
+#ifdef CONFIG_ACCESS_FS
+	accessfs_init();
+#endif
+
 	return 0;
 }
 module_init(inet_init);

Having to set the permissions like this on each boot seems a bit painful. Why not have permissions persistence like devfs has?

				Regards,

					Richard....
Permanent: [email protected]
Current:   [email protected]

In article <[email protected]>,

Maybe you could abstract that persistency from devfs and move it into a general layer that other filesytems can also use.

Wichert.

  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| [email protected]                   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

I suggested that last week in another thread (about Yet Another Virtual FS), and heard a deafening silence. I'm not sure if it's easier to provide a general layer, or to just make things available via devfs. Having a general layer implies multiple persistence daemons (aka devfsd), one for each virtual FS with persistence.

I was hoping to start some discussion about this, but it seems people care more about Aunt Tilly :-)

I'm sure some people will scream at the top of their lungs against the idea of making other information available via devfs, but maybe some of those screams will be muffled once I release v2.0 of the devfs core (that's the one where the internal tree is ripped out and the dcache is used instead: should be a big code reduction). At least with v1.9 of the devfs core all known races have been removed, so hopefully that softens the resistance :-)

				Regards,

					Richard....
Permanent: [email protected]
Current:   [email protected]

Hi,

Well, for me it's a small script running at boot time. So, there's no pain at all, unless planning or thinking in advance qualifies as pain ;-).

Seriously, this is a first cut. If there is real demand, I'll try to come up with something. But I think, this will be a job for system administrators or distribution builders. So, maybe a shell script with fixed permissions will be sufficient. We will see.

First of all, I want to see, wether people like it at all or come up alternative ideas.

Regards, Olaf.

Olaf,

After applying your patch to 2.5.2, my named wouldn't start up (it couldn't bind to port 921)

The below patch seems to have fixed that, and I think is probably the right thing to do.

Index: net/ipv4/af_inet.c
===================================================================
RCS file: /mnt/white/cvsroot/linux/net/ipv4/af_inet.c,v retrieving revision 1.2

diff -u -r1.2 af_inet.c
@@ -511,7 +511,7 @@
 
 	snum = ntohs(addr->sin_port);
 #ifdef CONFIG_ACCESS_FS
-	if (snum && snum < PROT_SOCK && !accessfs_permitted(&bind_to_port[snum], MAY_EXEC))
+	if (snum && snum < PROT_SOCK && !accessfs_permitted(&bind_to_port[snum], MAY_EXEC) && !capable(CAP_NET_BIND_SERVICE))
 #else
 	if (snum && snum < PROT_SOCK && !capable(CAP_NET_BIND_SERVICE))
 #endif

Hello all,

I'm not sure if this is the place to ask this particular question - if not, my apologies ....

I am working on optimizing some software and would like to be able to measure how long an instruction takes (down to the clock cycle of the CPU). I recall reading somewhere about a kernel time measurement called a "Jiffy" and figured that it would probably apply to this.

If anyone has any tips on how to figure out how to do this I'd really appreciate it.

Thanks!

Mark

Jiffies are quite coarse-grained. On x86 you want the rdtsc instruction, while on ppc you want mfrtcu/mfrtcl or mftbu/mftb depending on the version of the chip. These are used as inline assembly, and if you do a google search you should be able to find code snippets.

Chris

Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: [email protected]

For Intel.......

Assemble this as rdtsc.S

.data
lastl: .long 0
lasth: .long 0
.text
.align 8
.globl tim
.type tim@function

#
# Return the CPU clock difference between successive calls. #
tim: pushl %ebx
rdtsc
movl lastl, %ebx # Get last low longword
movl lasth, %ecx # Get last high longword
movl %eax, lastl # Save current low longword
movl %edx, lasth # Save current high longword
subl %ebx, %eax # Current - last
sbbl %ecx, %edx # Same with borrow
popl %ebx
ret
.end

Your code:

/* Really extern long long tim(void); */
extern long tim(void); /* Good enough */

main()

{
    long total_cycles;

    (void)tim();      /* Grab starting time */
    process();        /* Do your code */
    total_cycles = tim();

}

gcc -o tester main.c rdtsc.S

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

I was going to compile a list of innovations that could be attributed to Microsoft. Once I realized that Ctrl-Alt-Del was handled in the BIOS, I found that there aren't any.

Hi Ben,

I just managed to build and boot 2.5.2 plus my patch. My named starts without any problem. So, sorry can't reproduce it here.

This sounds weird. Normally, named binds to port 53 and some high unprivileged port for replies from other DNS servers. Do you have some 'listen-on' and/or 'query-source' statements in your named.conf? If you do, just change permissions of /mnt/net/ipv4/bind/921 appropriately.

[...]

The port 53 bindings happen without problem.

BINDv9 has a lightweight resolver service which runs on port 921 - this is not enabled by default, and when it is enabled, seems to start up later on in the startup process.

Add the single line:
lwres {};
in your named.conf and it will be enabled.

Taking capabilities away seems to break backwards compatibility.

And I'm not entirely sure it *is* equivalent to chown root/chmod u+x - that is how /mnt/accessfs/net/ipv4/bind appeared and my named couldn't bind to 921.

Ben

Ben Clifford     [email protected]     GPG: 30F06950
Job Required in Los Angeles - Will do most things unix or IP for money.
http://www.hawaga.org.uk/resume/resume001.pdf

Ok, I'm running BINDv8 right now.

I'll think about this. I haven't heard about a working system or tools, which use capabilities yet. So I thought, nobody would see a difference.

I will investigate this further. Seems, I need to install BINDv9 to reproduce this problem.

Regards, Olaf.

However, rdtsc will completely change how your decoders fill, how busy your execution units are, it will interfere with every singe stage in the CPU from the fetch logic to the retirement and write buffer.

Your cycle will not behave "as usual" if you put rdtscs around it.

I usually put an rdtsc in the very beginning of a routine, and an rdtsc at the end. Then I have the assembly following the last rdtsc increment a counter in an array (after a bounds check). The index in the array is the number of clock cycles I spent.

After running the function some thousands of times, you will have a nice histogram in your array, usually with some skewed bell-like curve (you can see many interesting kinds of double/triple bells etc. all depending on your code).

Changing just one or two instructions in the function, then re-running the code and re-plotting the histogram, will displace the peak of the bell curve in some direction. This will tell you how your change affected the code in "typical number of clock cycles".

................................................................
:   [email protected]   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

Woo. :) I've been thinking of making something like this my first kernel project but you beat me to it. Drat. :)

SOCCER PLAYER IN GENITAL-BITING SCANDAL  ---  "It was something between
friends that I thought would have no importance until this morning when
I got up and saw all  the commotion in the news,"  Gallardo told a news
conference. "It stunned me."
Reyes told Marca that he had "felt a slight pinch."

I guess it's time to revise the old Unix saying "everything is a file" to "everything is a file system" =)

Regards: David Weinehall
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\

//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Well it is on a mac (more or less). Resource forks are a mini filesystem. :)

SOCCER PLAYER IN GENITAL-BITING SCANDAL  ---  "It was something between
friends that I thought would have no importance until this morning when
I got up and saw all  the commotion in the news,"  Gallardo told a news
conference. "It stunned me."
Reyes told Marca that he had "felt a slight pinch."

typically logging must also occur as some other user than what the daemon runs as, or else your logs are suspect in any sort of break-in. this is no problem for stuff using syslog, but since that's not the default configuration for apache you might want to put a note in any docs you end up including. one suggestion is piped logging through a setuid logger (setuid to user wwwlogs or something, root not required).

-dean

Right. But that's user space and shouldn't impact the kernel/accessfs. Or did I miss something?

Regards, Olaf.

no kernel impact ... i was just suggesting that any accompanying documentation should be careful to imply that the one change to allow www to open 80 is all that's required to get rid of apache's root privs. i'm just worried folks will blindly chown their logs to www.

-dean

Ok, now I understand your suggestion. Seems, I have to learn a lot more about security. Thanks, I will think about this issue.

Regards, Olaf.

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 - [email protected] - www.devcon.net

What would be nice would be to have a way to restrict access to ports based on IP ex: user1 gets 10.0.0.1 and user2 gets 10.0.0.2.

Gerhard

--
Gerhard Mack

[email protected]

<>< As a computer I find your faith in technology amusing.

At least for the moment I don't think this is necessary.

Keep in mind that accessfs with the current ressource coverage contains only entries which are static after initialization (except for user-initiated permission changes of course), not like devfs where entries are appearing, disappearing and reappearing all the time when modules are loaded/unloaded etc. So a small shell script which sets permissions once after boot should suffice in all cases (one could also write a script which saves permissions on shutdown, to automatically preserve changes made by the admin).

Andreas

       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - [email protected] - www.devcon.net

I don't see this conflicting with what the lsm patch does (with the minor exception of removing the capable() call.) How do you see a conflict here?

This patch looks nice, I like it.

Yet another reason why we should have a bunch of the ramfs functions exported for the rest of the kernel to use :)

thanks,

greg k-h

I don't mean a conflict in the implementation. Clearly it is possible to combine accessfs checks with LSM hooks (indeed, I think this is the only possible way for accessfs until LSM gets authoritative hooks - hey, this could be an example project for "authoritative" advocates :-).

My concern was conceptual: accessfs is just another mechanism for access control to various ressources. As I understand it, LSM is intended to move /all/ access control logic into separate modules with a uniform interface to the kernel, so that you can choose whatever access control mechanism you want (or even rip out all access control, as for example some embedded applications don't need it). Clearly it's a long way until LSM actually gets to this point, but nevertheless it's the overall goal of the whole effort IMHO.

Moving accessfs to use LSM hooks means only changes at the implementation level, no changes of the concept or user interface of accessfs are needed. What I wanted to express was only that the LSM effort may put some constraints on the timeline for kernel inclusion of accessfs ("collide" vs. "conflict" ;-).

I totally agree with that. Maybe I should have expressed it more clearly in my first mail ;-)

Andreas

       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - [email protected] - www.devcon.net

This idea seems to be popular:

http://www.google.com/search?q=sockfs

I must say I like the idea myself.

Well, it's a good idea :-).

Thanks for the pointer.

Regards, Olaf.

The LSM patch's goal is to only _allow_ you do add access control mechanisms to the kernel easily.

This accessfs patch doesn't collide with that goal at all. If it gets accepted into the kernel, people who write LSM based access control modules need to remember to medaite access to the accessfs if they want to. Since the LSM hooks are much lower in the vfs than accessfs, it is a simple thing to add this kind of access mediation.

Hope this helps clear it up a bit.

thanks,

greg k-h