Difference between revisions of "User:Jecurrey"
From Linux-VServer
(New page: Just need somewhere to frame these questions: My host has only hardware programs running, such as mdadm and the vservers stuff...except ssh. == NFS Server in a vserver == I ended up run...) |
(X-server and nfs-kernel-server in vserver... can a write to /proc be allowed?) |
||
| Line 5: | Line 5: | ||
== NFS Server in a vserver == | == NFS Server in a vserver == | ||
| − | I ended up running the script | + | I ended up running the script /etc/init.d/nfs-kernel-server |
vnamespace -e 1011 chroot /var/lib/vservers/entropy /bin/bash /etc/init.d/nfs-kernel-server start | vnamespace -e 1011 chroot /var/lib/vservers/entropy /bin/bash /etc/init.d/nfs-kernel-server start | ||
| − | with portmap, statd, running in the vserver. | + | with portmap, statd, started and running normally in the vserver. |
Problem is that the shell script /etc/init.d/nfs-kernel-server writes to files in /proc/fs/nfsd/ | Problem is that the shell script /etc/init.d/nfs-kernel-server writes to files in /proc/fs/nfsd/ | ||
| − | Also /proc/net/rpc/ - | + | Also added /proc/net/rpc/ - otherwise you'll get no nfsstat, and other misinformation. |
Changed /etc/vservers/.defaults/apps/vprocunhide [[User:Jecurrey#vprocunhide]] | Changed /etc/vservers/.defaults/apps/vprocunhide [[User:Jecurrey#vprocunhide]] | ||
| Line 20: | Line 20: | ||
*exportfs | *exportfs | ||
| − | While it works,,, something isn't quite right, as I am getting the nfs server not responding on the clients, but they do boot with the nfs drive. | + | While it works,,, something isn't quite right, as I am getting the nfs server not responding on the clients, which then OKs, but they do boot with the nfs drive. |
| − | (and some of it may just be nfs stuff, I changed all my mounts around, and added a pile of --binds, so the clients wouldn't need to. | + | (and some of it may just be nfs stuff, and the fact that all my MB and NIC changed, and I changed all my mounts around, and added a pile of --binds, so the clients wouldn't need to. |
== X server == | == X server == | ||
Why, I isolate things as much as possible... especially user stuff. Update are easier. Security wasn't the first reason...because I've pretty much given access to much of the hardware. | Why, I isolate things as much as possible... especially user stuff. Update are easier. Security wasn't the first reason...because I've pretty much given access to much of the hardware. | ||
required /proc/bus/ - orignally pci, but with mice and other stuff, just let it have the whole. | required /proc/bus/ - orignally pci, but with mice and other stuff, just let it have the whole. | ||
and I added a pile of CAPS.. which I need to reduce (but I got tired of it not working so I put the whole lot in :-P ) | and I added a pile of CAPS.. which I need to reduce (but I got tired of it not working so I put the whole lot in :-P ) | ||
| − | CAP_FOWNER | + | |
| − | CAP_FSETID | + | CAP_FOWNER |
| − | CAP_SETPCAP - I've been running tcpdump from this vserver... | + | CAP_FSETID |
| − | CAP_NET_BIND_SERVICE - X binds high, I don't if this is only for privilledged or all, also the NFS server has a random series of ports plus 111 for portmapper, a 2049 mountd | + | CAP_SETPCAP - I've been running tcpdump from this vserver... |
| − | CAP_NET_BROADCAST - samba... but it seems to work fine without this, not so without 127.0.0.1, then it can't talk to itself. | + | CAP_NET_BIND_SERVICE - X binds high, I don't if this is only for privilledged or all, also the NFS server has a random series of ports plus 111 for portmapper, a 2049 mountd |
| − | CAP_NET_RAW - (dhcp, bind, which are in another vserver) | + | CAP_NET_BROADCAST - samba... but it seems to work fine without this, not so without 127.0.0.1, then it can't talk to itself. |
| − | CAP_IPC_LOCK | + | CAP_NET_RAW - (dhcp, bind, which are in another vserver) |
| − | CAP_IPC_OWNER | + | CAP_IPC_LOCK |
| − | CAP_SYS_RAWIO - I think X... | + | CAP_IPC_OWNER |
| − | CAP_SYS_CHROOT - some irrelevant service did this.. which I haven't removed. (a recend bind9 installation I did, did a change root, but not my local installation, its already vserver'd) | + | CAP_SYS_RAWIO - I think X... |
| − | CAP_SYS_PTRACE - gone... | + | CAP_SYS_CHROOT - some irrelevant service did this.. which I haven't removed. (a recend bind9 installation I did, did a change root, but not my local installation, its already vserver'd) |
| − | CAP_SYS_NICE - X-server (is it dysfunctional if not given) | + | CAP_SYS_PTRACE - gone... |
| − | CAP_SYS_RESOURCE - (dhcp, bind, which are in another vserver) | + | CAP_SYS_NICE - X-server (is it dysfunctional if not given) |
| − | CAP_SYS_TIME - ntp, I have this commonly in the host, but considering past exploits, a vserver sounds better. | + | CAP_SYS_RESOURCE - (dhcp, bind, which are in another vserver) |
| − | CAP_SYS_TTY_CONFIG - if this is pty...then X, if it console... then X ha. | + | CAP_SYS_TIME - ntp, I have this commonly in the host, but considering past exploits, a vserver sounds better. |
| + | CAP_SYS_TTY_CONFIG - if this is pty...then X, if it console... then X ha. | ||
Almost want a windows firewall user inquiry thingie for these... it hit the wall, and asks the user... can "program X" diddle your network? | Almost want a windows firewall user inquiry thingie for these... it hit the wall, and asks the user... can "program X" diddle your network? | ||
How would you go about putting a wrapper on the violations? | How would you go about putting a wrapper on the violations? | ||
| Line 50: | Line 51: | ||
== vprocunhide == | == vprocunhide == | ||
diff files /usr/lib/util-vserver/defaults/vprocunhide-files | diff files /usr/lib/util-vserver/defaults/vprocunhide-files | ||
| − | 2c2 | + | 2c2 |
| − | < /proc/net/rpc/ | + | < /proc/net/rpc/ |
| − | --- | + | --- |
| − | > -/proc/net/rpc/ | + | > -/proc/net/rpc/ |
| − | 12d11 | + | 12d11 |
| − | < /proc/bus/ | + | < /proc/bus/ |
| − | 18,19d16 | + | 18,19d16 |
| − | < /proc/fs/ | + | < /proc/fs/ |
| − | < /proc/fs/nfsd/ | + | < /proc/fs/nfsd/ |
I thought I only needed nfsd... need to delete that /proc/fs | I thought I only needed nfsd... need to delete that /proc/fs | ||
| − | Question: is there a way to have per XID a /proc hiding spec, much like bcapablities? I really only want these in their respective | + | Question: is there a way to have per XID a /proc hiding spec, much like bcapablities? I really only want these in their respective boxes. |
There is new built in localhost handling. I was adding an extra lo 127.0.0.1/8 interface with localhost defined for the troublesome programs like samba. | There is new built in localhost handling. I was adding an extra lo 127.0.0.1/8 interface with localhost defined for the troublesome programs like samba. | ||
What is suggested now. | What is suggested now. | ||
Latest revision as of 06:52, 3 September 2008
Just need somewhere to frame these questions:
My host has only hardware programs running, such as mdadm and the vservers stuff...except ssh.
[edit] NFS Server in a vserver
I ended up running the script /etc/init.d/nfs-kernel-server
vnamespace -e 1011 chroot /var/lib/vservers/entropy /bin/bash /etc/init.d/nfs-kernel-server start
with portmap, statd, started and running normally in the vserver. Problem is that the shell script /etc/init.d/nfs-kernel-server writes to files in /proc/fs/nfsd/ Also added /proc/net/rpc/ - otherwise you'll get no nfsstat, and other misinformation. Changed /etc/vservers/.defaults/apps/vprocunhide User:Jecurrey#vprocunhide
Almost forgot. the kernel modules must be loaded by the host...really only nfsd.. it will bring the rest with modprobe.
- nfsd
- lockd
- nfs_acl
- auth_rpcgss
- sunrpc
- exportfs
While it works,,, something isn't quite right, as I am getting the nfs server not responding on the clients, which then OKs, but they do boot with the nfs drive. (and some of it may just be nfs stuff, and the fact that all my MB and NIC changed, and I changed all my mounts around, and added a pile of --binds, so the clients wouldn't need to.
[edit] X server
Why, I isolate things as much as possible... especially user stuff. Update are easier. Security wasn't the first reason...because I've pretty much given access to much of the hardware. required /proc/bus/ - orignally pci, but with mice and other stuff, just let it have the whole. and I added a pile of CAPS.. which I need to reduce (but I got tired of it not working so I put the whole lot in :-P )
CAP_FOWNER CAP_FSETID CAP_SETPCAP - I've been running tcpdump from this vserver... CAP_NET_BIND_SERVICE - X binds high, I don't if this is only for privilledged or all, also the NFS server has a random series of ports plus 111 for portmapper, a 2049 mountd CAP_NET_BROADCAST - samba... but it seems to work fine without this, not so without 127.0.0.1, then it can't talk to itself. CAP_NET_RAW - (dhcp, bind, which are in another vserver) CAP_IPC_LOCK CAP_IPC_OWNER CAP_SYS_RAWIO - I think X... CAP_SYS_CHROOT - some irrelevant service did this.. which I haven't removed. (a recend bind9 installation I did, did a change root, but not my local installation, its already vserver'd) CAP_SYS_PTRACE - gone... CAP_SYS_NICE - X-server (is it dysfunctional if not given) CAP_SYS_RESOURCE - (dhcp, bind, which are in another vserver) CAP_SYS_TIME - ntp, I have this commonly in the host, but considering past exploits, a vserver sounds better. CAP_SYS_TTY_CONFIG - if this is pty...then X, if it console... then X ha.
Almost want a windows firewall user inquiry thingie for these... it hit the wall, and asks the user... can "program X" diddle your network? How would you go about putting a wrapper on the violations?
I am surprized that X didn't need mknod... maybe because it had already been running... so its might be a one shot.
ntp, X-server, nfs-kernel-server are in this vserver for now,,, the X-server will be split out to isolate the mass quantities of user applications.
[edit] vprocunhide
diff files /usr/lib/util-vserver/defaults/vprocunhide-files
2c2 < /proc/net/rpc/ --- > -/proc/net/rpc/ 12d11 < /proc/bus/ 18,19d16 < /proc/fs/ < /proc/fs/nfsd/
I thought I only needed nfsd... need to delete that /proc/fs
Question: is there a way to have per XID a /proc hiding spec, much like bcapablities? I really only want these in their respective boxes.
There is new built in localhost handling. I was adding an extra lo 127.0.0.1/8 interface with localhost defined for the troublesome programs like samba. What is suggested now.
