[zones-discuss] pidentd
Hello, I would like to have users on a zone, but we use pidentd to control some network connections. It seems that pidentd doesn not work on zones as it can't open kmem. Is there any way to make it work ? f.g. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pidentd
[EMAIL PROTECTED] writes: > I would like to have users on a zone, but we use pidentd to control some > network connections. > It seems that pidentd doesn not work on zones as it can't open kmem. > > Is there any way to make it work ? Essentially, no. Opening /dev/kmem in the zone wouldn't be a good thing to do -- there's only one kernel, and that would break the security model. Besides, everything visible via /dev/kmem is just an implementation artifact; anything that depends on it hasn't been designed correctly and may fail at any time as the internal kernel code evolves. The right thing to do is to create a set of stable interfaces to get PID lists for sockets. We don't currently have such a thing in Solaris, but it looks like this is something that other programs (such as lsof) need. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pidentd
James Carlson <[EMAIL PROTECTED]> > Cc: zones-discuss@opensolaris.org > Date: Fri, 04 May 2007 07:04:14 EDT > Subject: Re: [zones-discuss] pidentd >[EMAIL PROTECTED] writes: >> I would like to have users on a zone, but we use pidentd to control some >> network connections. >> It seems that pidentd doesn not work on zones as it can't open kmem. >> >> Is there any way to make it work ? > >Essentially, no. > >Opening /dev/kmem in the zone wouldn't be a good thing to do -- >there's only one kernel, and that would break the security model. >Besides, everything visible via /dev/kmem is just an implementation >artifact; anything that depends on it hasn't been designed correctly >and may fail at any time as the internal kernel code evolves. > >The right thing to do is to create a set of stable interfaces to get >PID lists for sockets. We don't currently have such a thing in >Solaris, but it looks like this is something that other programs (such >as lsof) need. That's a real pain as that prevent us to use zones as hosting servers for users : - we are a school and we just want to identify connections. Starting with mail sending. Zones would break our identification model. It would be real nice if some solution could be found. f.g. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pidentd
> >That's a real pain as that prevent us to use zones as hosting servers for >users : >- we are a school and we just want to identify connections. Starting with mail >sending. >Zones would break our identification model. >It would be real nice if some solution could be found. I've done some work on pidentd prior to the new IP instances code using the ability to intercept calls for all zones in the global zone with the SO_ALLZONES socket option (which may not work anymore after the IP instances putback) In that scenario, there's one pidentd which runs in the global zone and it gets all identd calls for all zones which do not have exclusive IP instances; it is then able to resolve all identd queries but using nameservices relative to the global zone. Casper ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pidentd
[EMAIL PROTECTED] writes: > I've done some work on pidentd prior to the new IP instances code using the > ability to intercept calls for all zones in the global zone with the > SO_ALLZONES socket option (which may not work anymore after the IP > instances putback) Nifty! Not sure about the socket option (should still work ... ?), but IP Instances did nuke the symbols that pidentd was reading out of the kernel, so that utility is now broken. > In that scenario, there's one pidentd which runs in the global zone and it > gets all identd calls for all zones which do not have exclusive IP > instances; it is then able to resolve all identd queries but using > nameservices relative to the global zone. I'd sort of like to know how it does that reliably ... does it fork and enter the zone? In any event, I think that getting something other than /dev/kmem for these sorts of applications (pidentd isn't the only one; there's also lsof and probably ntop as well) would be a _very_ nice thing to have. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pidentd
>Not sure about the socket option (should still work ... ?), but IP >Instances did nuke the symbols that pidentd was reading out of the >kernel, so that utility is now broken. I also have no idea about that option and how it is affected by the IP instances project. I am assuming it is now "per-instance" rather than per-system. >> In that scenario, there's one pidentd which runs in the global zone and it >> gets all identd calls for all zones which do not have exclusive IP >> instances; it is then able to resolve all identd queries but using >> nameservices relative to the global zone. > >I'd sort of like to know how it does that reliably ... does it fork >and enter the zone? It does not resolve names local to the local zones; but it can easily find all the appropriate uids and processes. No different from traditional Solaris with multiple interfaces. >In any event, I think that getting something other than /dev/kmem for >these sorts of applications (pidentd isn't the only one; there's also >lsof and probably ntop as well) would be a _very_ nice thing to have. Yep. But defining an interface is hairy, specially considering locking and performance. Casper ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pidentd
[EMAIL PROTECTED] writes: > >I'd sort of like to know how it does that reliably ... does it fork > >and enter the zone? > > It does not resolve names local to the local zones; but it can easily > find all the appropriate uids and processes. No different from traditional > Solaris with multiple interfaces. Oh. I though that pidentd was supposed to resolve UIDs locally. That's one of the features of the protocol; it provides "here's who *I* think the user is" information back to the requester. > >In any event, I think that getting something other than /dev/kmem for > >these sorts of applications (pidentd isn't the only one; there's also > >lsof and probably ntop as well) would be a _very_ nice thing to have. > > > Yep. But defining an interface is hairy, specially considering locking > and performance. *sigh* -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pidentd
>[EMAIL PROTECTED] writes: >> >I'd sort of like to know how it does that reliably ... does it fork >> >and enter the zone? >> >> It does not resolve names local to the local zones; but it can easily >> find all the appropriate uids and processes. No different from traditional >> Solaris with multiple interfaces. > >Oh. I though that pidentd was supposed to resolve UIDs locally. >That's one of the features of the protocol; it provides "here's who >*I* think the user is" information back to the requester. I did not get around to implementing that bit; it was more a proof-of-concept. It could returns uids in that case as well (should be sufficient for most purposes; in some cases the daemon returns only encrypted uids anyway) >> >In any event, I think that getting something other than /dev/kmem for >> >these sorts of applications (pidentd isn't the only one; there's also >> >lsof and probably ntop as well) would be a _very_ nice thing to have. >> >> >> Yep. But defining an interface is hairy, specially considering locking >> and performance. > >*sigh* It might not be that difficult, as long as we can just use the cred/pid stored in the tcp_t structure and either "trust" that or verify it. Casper ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] A seperate /usr/local/
Hi Bernd, That is interesting, both in good and bad ways. That method weakens the security of the system. For example, if the global zone's root user has /usr/local in its $PATH, a non-global zone root user could insert a trojan horse into an existing script or program in /usr/local. This attack could be used to give the non-global root user access to the root account on the global zone, or execute more subtle actions. In general, unless you are the only user of the system and its zones, you should not give a zone write-access to any files that are used by the global zone's users. Bernd Finger - Sun Germany wrote: Hi, DJR wrote: I installed my zones, in a sparse zone format. question is, is there a way to NOT use /usr/local from the global zone and use a local copy or start with a clean /usr/local on the zone besides in a whole root format where it copies the global over to the zone. I do not want to rebuild the zone if possible, is there any way around this. A way that worked for me is to "escape" the /usr directory using a symbolic link: 1) In the global zone, move /usr/local to /_usr_local (or any other directory in a file system that is not mounted read only in one of the local zones) $ mv /usr/local /_usr_local 2) In the global zone, create a symbolic link that points from /usr/local to the new location: $ ln -s /_usr_local /usr/local $ ls -ld /usr/local lrwxrwxrwx 1 root root 11 May 4 08:10 /usr/local -> /_usr_local 3) In the global zone, create a directory /root/_usr_local for each local zone . As each local zone's /usr is a read only copy of the /usr tree of the global zone, its file /usr/local is a link to a (writable) directory outside of that file system in that zone. -- -- Jeff VICTOR Sun Microsystemsjeff.victor @ sun.com OS AmbassadorSr. Technical Specialist Solaris 10 Zones FAQ:http://www.opensolaris.org/os/community/zones/faq -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] A seperate /usr/local/
Jeff, If there is a link pointing from /usr/local to /_usr_local, this link will be present in each zone and pointing to directory _usr_local in the / file system of that zone only. Example: After logging in to local zone z_01 (with zonepath /zone/z_01) and creating a file /usr/local/test1, there will be a file /_usr_local/test1 in that local zone only. Or, from the global zone's perspective, the only new file on that system will be /zone/z_01/root/_usr_local/test1. Regards, Bernd Jeff Victor wrote: Hi Bernd, That is interesting, both in good and bad ways. That method weakens the security of the system. For example, if the global zone's root user has /usr/local in its $PATH, a non-global zone root user could insert a trojan horse into an existing script or program in /usr/local. This attack could be used to give the non-global root user access to the root account on the global zone, or execute more subtle actions. In general, unless you are the only user of the system and its zones, you should not give a zone write-access to any files that are used by the global zone's users. Bernd Finger - Sun Germany wrote: Hi, DJR wrote: I installed my zones, in a sparse zone format. question is, is there a way to NOT use /usr/local from the global zone and use a local copy or start with a clean /usr/local on the zone besides in a whole root format where it copies the global over to the zone. I do not want to rebuild the zone if possible, is there any way around this. A way that worked for me is to "escape" the /usr directory using a symbolic link: 1) In the global zone, move /usr/local to /_usr_local (or any other directory in a file system that is not mounted read only in one of the local zones) $ mv /usr/local /_usr_local 2) In the global zone, create a symbolic link that points from /usr/local to the new location: $ ln -s /_usr_local /usr/local $ ls -ld /usr/local lrwxrwxrwx 1 root root 11 May 4 08:10 /usr/local -> /_usr_local 3) In the global zone, create a directory /root/_usr_local for each local zone . As each local zone's /usr is a read only copy of the /usr tree of the global zone, its file /usr/local is a link to a (writable) directory outside of that file system in that zone. -- *** Sun Microsystems GmbH Bernd Finger Altrottstr. 31Service Alliance Operations D-69190 Walldorf Phone: +49-6227-356-238 Germany Fax: +49-6227-356-222 mailto:[EMAIL PROTECTED] Blog: http://blogs.sun.com/blogfinger http://www.sun.com/third-party/global/sap/service/support.html Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Marcel Schneider, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pidentd
Oh. I though that pidentd was supposed to resolve UIDs locally. That's one of the features of the protocol; it provides "here's who *I* think the user is" information back to the requester. Of course, that's why I thought IDENT was a fairly bogus mechanism since you're asking the remote system to report on its own users and someone who controls that machine can report whatever their heart desires. Or has the mechanism changed over the years? Has there been any work in the IETF, for example, to try and develop something more useful than identd? dsc ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pidentd
>> Oh. I though that pidentd was supposed to resolve UIDs locally. >> That's one of the features of the protocol; it provides "here's who >> *I* think the user is" information back to the requester. > >Of course, that's why I thought IDENT was a fairly bogus mechanism >since you're asking the remote system to report on its own users and >someone who controls that machine can report whatever their heart >desires. But that's precisely what you want! The people who say that have no clue what it is for: it's to help the owner of the *system running pidentd*; not the person who finds the identd entries in his logs. Casper ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pidentd
[EMAIL PROTECTED] writes: > > Oh. I though that pidentd was supposed to resolve UIDs locally. > > That's one of the features of the protocol; it provides "here's who > > *I* think the user is" information back to the requester. > > Of course, that's why I thought IDENT was a fairly bogus mechanism > since you're asking the remote system to report on its own users and > someone who controls that machine can report whatever their heart > desires. It has its value, you just have to know how to use it. > Or has the mechanism changed over the years? Has there been any work > in the IETF, for example, to try and develop something more useful than > identd? No. The value is this: it provides you a way to ask for a durable but unauthenticated identifier of some sort (doesn't really matter what sort -- it's opaque as far as the receiver is concerned) to associate with that connection. The purpose is for debug and hunting down abusers with cooperating admins. It's no more or less secure than the source port number. In other words, instead of saying "I saw a connection at 2:34PM yesterday from 10.0.0.1:5678, and it looks like he was trying to hack into my system; can you talk to this user?" You can say "I saw a connection at 2:34PM yesterday from 10.0.0.1:5678 from someone your system identifies as 'FooBar,' and it looks like he was trying to hack into my system; can you talk to this user?" If that *remote* admin is himself useful (he may not be) and if he trusts the value from his own IDENT report (he should), then it'll give him an easier time tracking down the offender. If you don't do this, then the only thing that poor remote admin has to go on is the socket parameters, and that's very little data for a multiuser system. It's effectively useless, unless that remote admin is a weirdo who is logging every single packet along with local UID. It all hinges on cooperating system administrators for multiuser systems. If you don't have that, then you have to go to higher layers (using address alone, assuming single-user systems, uRPF, and address assignment that relates to the user) or higher still (service providers). -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pidentd
Le 4 mai 07 à 19:34, [EMAIL PROTECTED] a écrit : Oh. I though that pidentd was supposed to resolve UIDs locally. That's one of the features of the protocol; it provides "here's who *I* think the user is" information back to the requester. Of course, that's why I thought IDENT was a fairly bogus mechanism since you're asking the remote system to report on its own users and someone who controls that machine can report whatever their heart desires. But that's precisely what you want! The people who say that have no clue what it is for: it's to help the owner of the *system running pidentd*; not the person who finds the identd entries in his logs. In our case : several machines with a lot of untrusted users (I mean user who can try to do « nasty » things) it is a real need. The « remote » system is an inner system : a computer in a classroom, a server with a classroom of X terminals... Of course identd is not usefull when somebody connects from the outside world whith his linux box. But can I hope that sun provide some support for such feature in a near future ? I would be happy to demonstrate what zones can do to our students in a secure way. Sharing kmem would not be a good solution to share the same server with students and secure tasks. f.g.___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] how to allow writeable /usr directory on a zone?
HI All, I have a problem in that my application needs to write things to the /usr/lib/* directories. However, on the Zone, it's READ ONLY. Is there anyway I can make the /usr/lib/* a normal rwx directory? Thank you for your help. SB This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pidentd
James Carlson wrote: [EMAIL PROTECTED] writes: I would like to have users on a zone, but we use pidentd to control some network connections. It seems that pidentd doesn not work on zones as it can't open kmem. Is there any way to make it work ? Essentially, no. Opening /dev/kmem in the zone wouldn't be a good thing to do -- there's only one kernel, and that would break the security model. Besides, everything visible via /dev/kmem is just an implementation artifact; anything that depends on it hasn't been designed correctly and may fail at any time as the internal kernel code evolves. The right thing to do is to create a set of stable interfaces to get PID lists for sockets. We don't currently have such a thing in Solaris, but it looks like this is something that other programs (such as lsof) need. One might be able to build an approximation using what is in the recent MIB additions in Nevada (and comming to S10U4) which are in : tcpConnCreationProcess udpCreationProcess sctpAssocPrimProcess (and tcp6, udp6 variants) It would be an approximation since it doesn't handle the case when a socket is handed from one process to another, nor sockets that are used by multiple processes. Note that netstat doesn't display the above. Erik ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Best practice -> mounting file system on local zone
Hello, Can some one shed some light on pros/cons on various ways of mounting a file system onto local zone ? I believe there are four different ways to mount a device/file system on loca zone as per the below url, but it is not very clear how they are different. http://www.sun.com/bigadmin/features/articles/db2_containers.html thanks r This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] how to allow writeable /usr directory on a zone?
You need a "Whole Root Zone" (no sharing) instead of a "Sparse Root Zone"... I think you can control the sharing between the global zone and the non-global zone by using setting "inherit-pkg-dir": http://www.solarisinternals.com/wiki/index.php/Zones Rayson On 5/4/07, Jazz Geek <[EMAIL PROTECTED]> wrote: HI All, I have a problem in that my application needs to write things to the /usr/lib/* directories. However, on the Zone, it's READ ONLY. Is there anyway I can make the /usr/lib/* a normal rwx directory? Thank you for your help. SB This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
