Robert Bailey wrote:
> Nah, don't care about serving at admin_low. I have read many TX docs
> that imply that local zones can't share NFS as a server though (due
> to local zones not having the necessary tcp stack access/permissions).
You are misinformed. Although standard Solaris doesn't support sharing
directories belonging to non-global zones, TX does allow this. I seem to
answer this question on this alias about once a week. There is a dfstab
file for each zone. Although the administration, sharing and and NFS
service runs place in the global the share is labeled with the
corresponding zone's label. From the client's side, you must mount it
using the IP address of the global zone.
>
> In the end, all I want is to use TX to add extra restrictions on
> sharing NFS to non-tx systems and TX systems.
> If you don't mind, what are the options?
As Jarrett said, we don't allow unlabeled clients to make requests at
the admin_low label. That is an administrative label, and the unlabeled
client is not sufficiently trusted. Similarly, we don't allow such
clients to ssh into the global zone. If you want to NFS serve an
unlabeled client you must assign it a label above admin_low. If you want
the unlabeled client to be able to mount read-write via NFS, it must
have the same label as the zone corresponding to the dfstab that
contains that share.
--Glenn
>
>
> On Apr 21, 2007, at 5:57 PM, jarrett lu wrote:
>
>> Bob,
>>
>> TX NFS server can serve non-tx clients, but it can't server them
>> at the admin_low label. The restriction is intentional. We didn't
>> feel comforable about having non-tx clients accessing TX NFS
>> server global zone files. In your environment, must the client
>> run in admin_low default label?
>>
>> BTW, the following code in nfs4_srv.c restricts the service:
>>
>> static nfsstat4
>> do_rfs4_op_lookup(char *nm, uint_t buflen, struct svc_req *req,
>> struct compound_state *cs)
>> {
>> [...] if (!blequal(&l_admin_low-
>> >tsl_label, clabel)) {
>> if (!do_rfs4_label_check(clabel, vp,
>> DOMINANCE_CHECK))
>> { error
>> = EACCES;
>> goto err_out;
>> }
>> } else {
>> /*
>> * We grant access to admin_low label clients
>> * only if the client is trusted, i.e. also
>> * running Solaris Trusted Extension.
>> */
>> [...]
>> tp = find_tpc(ipaddr, addr_type, B_FALSE);
>> if (tp == NULL || tp->tpc_tp.tp_doi !=
>> l_admin_low->tsl_doi || tp-
>> >tpc_tp.host_type !=
>> SUN_CIPSO) {
>> error = EACCES;
>> goto err_out;
>> }
>> [...]
>> }
>>
>> Jarrett
>>
>>
>> Robert Bailey wrote:
>>
>>> Folks,
>>>
>>> I'm trying to setup a secured build server using TX. I have TX up
>>> and running fine, but run into a problem when sharing an NFS mount
>>> from the Global ADMIN_LOW to a non-tx system. The non-tx system
>>> has a net label of admin_low. Any thoughts?
>>>
>>> global and client are admin_low for files.
>>>
>>> Heres the client:
>>>
>>> tnctl -h 192.168.15.78:admin_low
>>>
>>> tninfo -h 192.168.15.78
>>> IP address= 192.168.15.78
>>> Template = admin_low
>>> I'm wondering if it could be an MLP setting - don't quite have my
>>> head around TX yet.
>>> Here's some details
>>>
>>> All: no LDAP, just files
>>>
>>> *TX System:*
>>> hostname: gw1, dns: gw1.dynlab.net
>>>
>>> cat /etc/security/tsol/tnzonecfg
>>> global:ADMIN_LOW:1:111/tcp;111/udp;515/tcp;631/*tcp**;2049*/tcp;
>>> 6000-6003/tcp:6000-6003/tcp
>>> foo:0x0002-08-08:0::
>>> bar:0x000a-08-08:0::
>>>
>>> cat /etc/dfs/dfstab
>>> share -F nfs -o
>>> rw=tserver:tserver.dynlab.net:rlbserver,root=tserver:tserver.dynlab.n
>>> et /scratch
>>> share -F nfs -o
>>> rw=tserver:tserver.dynlab.net:rlbserver,root=tserver:tserver.dynlab.n
>>> et /share/install
>>>
>>> # Yea, Word Write is just for testing - no need for soap box ;)
>>> root owner with 700/770 same issue.
>>>
>>> ls -l /share/
>>> total 3
>>> drwxrwxrwx 2 me sys 2 Apr 21 12:30 install
>>>
>>> /etc/default/nfs settings, all others are defaults - I changed the
>>> range to just nfs v4 because of this issue. Same problems using
>>> defaults.
>>>
>>> NFSD_LISTEN_BACKLOG=32
>>> NFSD_PROTOCOL=ALL
>>> NFSD_SERVERS=16
>>> LOCKD_LISTEN_BACKLOG=32
>>> LOCKD_SERVERS=20
>>> LOCKD_RETRANSMIT_TIMEOUT=5
>>> GRACE_PERIOD=90
>>> NFS_SERVER_VERSMIN=4
>>> NFS_SERVER_VERSMAX=4
>>> NFS_CLIENT_VERSMIN=4
>>> NFS_CLIENT_VERSMAX=4
>>> NFS_SERVER_DELEGATION=on
>>>
>>> svcs -a|grep nfs
>>> disabled 13:51:43 svc:/network/nfs/client:default
>>> online 13:51:56 svc:/network/nfs/cbd:default
>>> online 13:51:57 svc:/network/nfs/status:default
>>> online 13:51:57 svc:/network/nfs/mapid:default
>>> online 13:51:57 svc:/network/nfs/nlockmgr:default
>>> online 13:51:58 svc:/network/nfs/rquota:default
>>> online 13:52:00 svc:/network/nfs/server:default
>>>
>>> *Non-TX System:*
>>> hostname: tserver, dns: tserver.dynlab.net
>>>
>>> # showmount -e gw1
>>> export list for gw1:
>>> /scratch tserver,tserver.dynlab.net,rlbserver
>>> /share/install tserver,tserver.dynlab.net,rlbserver
>>>
>>> Both cd /net/gw1/share/install and mount -F nfs gw1:/share/ install
>>> /foo fail. Tried with DNS name, fail.
>>> Both systems same DNS but NFS Domain set at default value
>>>
>>> mount -F nfs gw1.dynlab.net:/share/install /mnt
>>> nfs mount: mount: /mnt: Permission denied
>>>
>>> *Supplemental info:*
>>>
>>> Strange, but I tried the inverse using the client as a server to
>>> the TX and the mounting worked - same nfsd settings.
>>> Also note that the net label is working, I can ssh back and forth.
>>>
>>> Thoughts?
>>>
>>> ---------------------------------------------------------------------
>>> ---
>>>
>>> _______________________________________________
>>> security-discuss mailing list
>>> security-discuss at opensolaris.org
>>>
>>
>
> _______________________________________________
> security-discuss mailing list
> security-discuss at opensolaris.org
