Glen,
Thanks it was the nfs4 configuration. I didn't realize that the NFS4
domain default was to the dns name. Forcing it early in the build
process resolved it.
Jarrett,
The 2049 port needs to be set in the Fifth Field of tnzonecfg
otherwise the client gets a RPC: Program not registered error when
trying to mount the directory.
Not sure why, if this is a bug, or if I should remove it from the
Forth Field. Setting 2049/tcp in the fifth while removing from the
forth field works - well, I haven't noticed anything broken yet ;)
Thanks again folks. I'm putting together a summary to help others
with this. Will post here when complete.
On Apr 23, 2007, at 2:22 AM, Jarrett Lu wrote:
> Robert Bailey wrote:
>> First off, you guys rock!
>>
>> I have NFS sharing off to the systems desired. There's one last
>> question though.. in case you couldn't guess ;)
>> I'm trying to share off the mount with root defined instead of
>> nobody. Mostly because these will be temporary install mounts to
>> upgraded the clients to TX.
>>
>> TX# cat /zone/ZONENAME/etc/dfs/dfstab
>> share -F nfs -o sec=sys,rw=192.168.15.78,root=192.168.15.78 /
>> export/install
>>
>> SOL10# mount -o sec=sys nfs://192.168.15.78/zone/ZONENAME/root/
>> export/install /mnt2
>> SOL10# ls -l /mnt2
>> -rw-------- 1 nobody nobody 0 Apr 23 2007 testfoo
>
> Your 'share' command looks correct. I'm not sure why the "root="
> option didn't
> take effect. Can I ask you to try to mount using serv:/path, i.e.
> 192.168.15.78:/zone/...,
> instead of the NFS URL format and see if it makes any difference?
>>
>>
>> I can mount fine now from X.78 but it keeps showing up as user
>> nobody. Is this a TX restriction?
>>
>> Oh, for those interested, to get this to work I needed to adjust
>> the default txzonecfg to have shared access to port 2049
>>
>> cat /etc/security/tsol/txzonecfg
>> global:ADMIN_LOW:1:111/tcp;111/udp;515/tcp;631/tcp;2049/tcp;
>> 6000-6003/tcp:6000-6003/tcp;*2049/tcp*
>
> ^^^^^^
> 2049/tcp is present already. No need to add a duplicate.
>
> Thanks.
>
> Jarrett
>
>
>>
>>
>>
>> On Apr 21, 2007, at 8:33 PM, Glenn Faden wrote:
>>
>>> 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))
>>>>> { erro
>>>>> r = 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.dynl
>>>>>> ab.n et /scratch
>>>>>> share -F nfs -o
>>>>>> rw=tserver:tserver.dynlab.net:rlbserver,root=tserver:tserver.dynl
>>>>>> ab.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 <mailto:security-
>>>>>> discuss at opensolaris.org>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> security-discuss mailing list
>>>> security-discuss at opensolaris.org <mailto:security-
>>>> discuss at opensolaris.org>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> ---
>>
>> _______________________________________________
>> security-discuss mailing list
>> security-discuss at opensolaris.org
>>
>
>
