Re: Closing information leaks in jails?

From: Jeremie Le Hen (jeremie_at_le-hen.org)
Date: 08/19/05

  • Next message: Benjamin Lutz: "Re: Closing information leaks in jails?"
    Date: Fri, 19 Aug 2005 11:43:19 +0200
    To: Attila Nagy <bra@fsn.hu>
    
    

    Hi Attila,

    > I'm wondering about closing some information leaks in FreeBSD jails from
    > the "outside world".
    >
    > Not that critical (depends on the application), but a simple user, with
    > restricted devfs in the jail (devfsrules_jail for example from
    > /etc/defaults/devfs.rules) can figure out the following:
    >
    > - network interfaces related data, via ifconfig, which contains
    > everything, but the primary IP address of the interfaces. It seems that
    > alias IPs can be viewed:
    > bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    > options=1a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
    > ether 00:12:79:3d:83:c2
    > media: Ethernet autoselect (100baseTX <full-duplex>)
    > status: active
    > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
    > inet 127.0.0.2 netmask 0xff000000
    >
    > - the arp table via arp, which does contain the above interface
    > addresses. This can be used for example to detect other machines on the
    > same subnet, which communicate with the host machine.
    > - full dmesg output after boot and the kernel buffer when it overflows
    > (can contain sensitive information)
    > - information about geom providers (at least geom mirror list works)
    > - the list of the loaded kernel modules via kldstat
    > - some interesting information about the network related stuff via netstat
    > - information about configured swap space via swapinfo
    > - NFS related statistics via nfsstat
    > - a lot of interesting stuff via sysctl
    >
    > and maybe more, I can't think of currently.
    >
    > Are there any ways to close (some of) these?

    The original paper from phk@ and rwatson@ presenting jails let us
    sound this is a very neat concept. While I agree this is worth adding
    restrictions or features where they are really needed, the jail
    framework tends towards being fairly intrusive in the system.

    Therefore, I think ``hacking'' the source for all the above situations
    is not a good idea, although I agree there may be a need for them.

    What I'm going to say is obvious for most people, but saying it may
    spur on people imagination :-). BSD solutions are known to be smart,
    setting a bandage everywhere we seem to need one is not the appropriate
    way to go. For example, it has been recently dicussed that it would be
    worth having virtual network stacks, in order to have the ability to
    multiplex M jails over N virtual network stacks. The developpement of
    this doesn't even started on newer FreeBSD systems, but it seems
    the new upcoming routing code is going to be modified to handle
    multiple routing tables, in the same way as Linux does it. Andre
    Oppermann is going to publish a paper about its intention towards
    FreeBSD routing code. If you are interested in this, you may want to
    have a look at this (long) subthread [1].

    The problem is actually there are many ways to access kernel
    informations, and this is therefore a hard task to get a common
    security framework which would be simple to use for jail.

    At the moment, you might want to look at the MAC framework from the
    TrustedBSD project. I've never used it but I think it may overcome
    at least some of your concerns.

    Regards,

    [1] http://lists.freebsd.org/pipermail/freebsd-net/2005-August/008027.html

    -- 
    Jeremie Le Hen
    < jeremie at le-hen dot org >< ttz at chchile dot org >
    _______________________________________________
    freebsd-security@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-security
    To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
    

  • Next message: Benjamin Lutz: "Re: Closing information leaks in jails?"

    Relevant Pages

    • Re: jails and multple interfaces
      ... The server has two network interfaces, I am configuring one for host ... All the services running on the host are configured to bind to the host ... I have the jail host's services all binding to the first interfaces ip, ...
      (freebsd-stable)
    • jails and multple interfaces
      ... The server has two network interfaces, I am configuring one for host server to use, and the other with several aliased IPs, one for each of the jail servers. ...
      (freebsd-stable)
    • Re: jails and multple interfaces
      ... > The server has two network interfaces, I am configuring one for host> server to use, and the other with several aliased IPs, one for each of> the jail servers. ...
      (freebsd-stable)
    • Re: How to save the Firewall Zone setup for wireless Interface setting
      ... Run YaST2 again, and setup the card to managed, start on boot, no usercontrol, ... no network manager, and save. ... # setting up a lot of interfaces. ... # Switch on/off debug messages for all network configuration stuff. ...
      (alt.os.linux.suse)
    • Re: load balancing with a failover
      ... The tunnel interfaces have addresses ... from other network though ... Enter configuration commands, one per line. ... 1w0d: RT: delete subnet route to 192.168.128.20/30 ...
      (comp.dcom.sys.cisco)