nss_ldap without nscd or cached ?
Dear All, I think there is a some architectural issues with the current implementation of nsswitch or nsdispatch(3). Let's assume you want to authenticate against an LDAP database. You will install nss_ldap from port. You configure nss_ldap.conf with binddn and its bindpw. Here comes the problem: 1. If permission of nss_ldap.conf is 0400 since it contains the clear text password of the binddn, then an ordinary user cannot bind to the database and cannot get UID->name information from LDAP database. See output: [EMAIL PROTECTED]> ls -l /home total 6 drwxr-xr-x 3 9027 wheel 512 May 23 17:57 user1 drwxrwxr-x 3 root 9030 512 May 23 15:14 documents drwxr-xr-x 2 9013 9013 512 May 23 15:13 user2 This does not pose problem for programs with root credentials since they can access to LDAP database since they can fetch the password... 2. If you set the permission of nss_ldap.conf to 0444 then, you can access to the LDAP UID database: [EMAIL PROTECTED]> ls -l /home total 6 drwxr-xr-x 3 user1wheel 512 May 23 17:57 user1 drwxrwxr-x 3 root docs512 May 23 15:14 documents drwxr-xr-x 2 user2user2 512 May 23 15:13 user2 However it can generate some security problems since everybody can access to bindpw and potentially the whole LDAP database. I think some kind of solution would be to use nscd or cached (from FreeBSD 7.0) since nscd/cached could be run with root credential (and use 0400) of nss_ldap.conf. And normal users would access via nsdispatch(3) with their own credential. Other solution(?) would be to limit binddn access to read-only (also limiting access only few attributes in LDAP) then exposing the bindpw would not create big problem. However maintenance of LDAP ACI-s could be difficult: nss_ldap attribute mapping and attribute usage should be documented Do you think that cached(8) can be MFC-ed to RELENG_6 from current? Any alternative solution? Maybe in the ports tree? Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nss_ldap without nscd or cached ?
Hello Mohacsi, Dear All, I think there is a some architectural issues with the current implementation of nsswitch or nsdispatch(3). Let's assume you want to authenticate against an LDAP database. You will install nss_ldap from port. You configure nss_ldap.conf with binddn and its bindpw. Here comes the problem: 1. If permission of nss_ldap.conf is 0400 since it contains the clear text password of the binddn, then an ordinary user cannot bind to the database and cannot get UID->name information from LDAP database. See output: [EMAIL PROTECTED]> ls -l /home total 6 drwxr-xr-x 3 9027 wheel 512 May 23 17:57 user1 drwxrwxr-x 3 root 9030 512 May 23 15:14 documents drwxr-xr-x 2 9013 9013 512 May 23 15:13 user2 This does not pose problem for programs with root credentials since they can access to LDAP database since they can fetch the password... 2. If you set the permission of nss_ldap.conf to 0444 then, you can access to the LDAP UID database: [EMAIL PROTECTED]> ls -l /home total 6 drwxr-xr-x 3 user1wheel 512 May 23 17:57 user1 drwxrwxr-x 3 root docs512 May 23 15:14 documents drwxr-xr-x 2 user2user2 512 May 23 15:13 user2 However it can generate some security problems since everybody can access to bindpw and potentially the whole LDAP database. The problem, that you've described seems to be typical for nss_ldap users. I think some kind of solution would be to use nscd or cached (from FreeBSD 7.0) since nscd/cached could be run with root credential (and use 0400) of nss_ldap.conf. And normal users would access via nsdispatch(3) with their own credential. Yes - this is a solution. Other solution(?) would be to limit binddn access to read-only (also limiting access only few attributes in LDAP) then exposing the bindpw would not create big problem. However maintenance of LDAP ACI-s could be difficult: nss_ldap attribute mapping and attribute usage should be documented I think, that limiting binddn access to readonly is the best practice whether you use nscd/cached or not. BTW, what kind of documentation do you need? I can possibly provide the necessary information. Do you think that cached(8) can be MFC-ed to RELENG_6 from current? Any alternative solution? Maybe in the ports tree? The thing is cached(8) requires a lot of changes to libc to be made. So the ports tree is not the solution here. This is also a reason why it's MFCing to RELENG_6 is questionable. There is a lookupd (sysutils/lookupd) daemon in ports, which can be plugged into existing nsswitch implementation and function similar to cached/nscd - but it's quite out of date. Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- With best regards, Michael Bushkov Southern Federal University ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nss_ldap without nscd or cached ?
In the last episode (May 24), Mohacsi Janos said: > I think there is a some architectural issues with the current > implementation of nsswitch or nsdispatch(3). Let's assume you want > to authenticate against an LDAP database. You will install nss_ldap > from port. You configure nss_ldap.conf with binddn and its bindpw. > Here comes the problem: > > 1. If permission of nss_ldap.conf is 0400 since it contains the > clear text password of the binddn, then an ordinary user cannot bind > to the database and cannot get UID->name information from LDAP > database. See output: > > [EMAIL PROTECTED]> ls -l /home > total 6 > drwxr-xr-x 3 9027 wheel 512 May 23 17:57 user1 > drwxrwxr-x 3 root 9030 512 May 23 15:14 documents > drwxr-xr-x 2 9013 9013 512 May 23 15:13 user2 > You should be able to grant the anonymous user read access to user/group names and group membership attributes. That way you can do simple things like name->uid lookups without having to bind at all. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nss_ldap without nscd or cached ?
Hi Michael, On Thu, 24 May 2007, Michael Bushkov wrote: Hello Mohacsi, Other solution(?) would be to limit binddn access to read-only (also limiting access only few attributes in LDAP) then exposing the bindpw would not create big problem. However maintenance of LDAP ACI-s could be difficult: nss_ldap attribute mapping and attribute usage should be documented I think, that limiting binddn access to readonly is the best practice whether you use nscd/cached or not. BTW, what kind of documentation do you need? I can possibly provide the necessary information. I am curious only which ldap attributes will be used I would give access only those attributes in our LDAP servers which is necessary Thanks for your answer. Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SoC: Distributed Audit Daemon project
Hello!
I'm the SoC student who will work on "Distributed Audit Daemon"
project this summer. It was some discussion between me, my mentor
Bjoern Zeeb and Robert Watson about design of
this project. In this message I want to describe preliminary version
of design we're likely to have. Your criticism and comments are
very welcome!
Some general theses first.
1. What this project is about?
The general idea is to make it possible to log auditable events
to remote hosts by secure network transport. Some basic association
is daemon that acts as the server which receives BSM messages and
writes them out to local filesystem. and acts as client which
send BSM messages out.
My initial proposal on this project can be found here:
http://wiki.freebsd.org/DistributedAuditDaemon
2. As I said before initial subject of this project was "Distributed
audit daemon". But after some discussions we had decided that this
project can be done in more general maner. We can perform distributed
logging for any user-space app. At this rate we need to get clean
and general design with good level of abstraction. It seems that
"Distributed logging daemon" is the good name for this project.
(I will refer as "dlogd" to it)
Consider this picture ( Yes, I know that my ASCII art sucks :-) )
'` '-`
|| '-` | Client-specific |
| User-space app | <== | API [2] | ==> | part of |
| [1]| `-' | "dlogd" [3] |
`' `-'
^^
||
||
(network level) [4]
||
||
vv
'-`
'===` | Server-specific |
| File system | < |part of |
| hierarchy [6] | |"dlogd" [5] |
`===' `-'
Now I'll describe processes that will take place according to
this scheme.
[1] <=> [2]: Shared user-space library will incapsulate API.
And I really want to keep real API simple. At this moment
I'm going to have only one function that will mark log file
as "to deliver" (i.e. dlogd_submit("/var/audit/whatever")).
[2] <=> [3]: IPC will be UNIX domain sockets (PF_LOCAL).
Authentication scheme for this is:
(1) Authenticate [3] to [2]. This is reasonably authenticated
by using a trusted name for the local socket, such as
/var/dlogd/socket. Only a process authorized to act as the daemon
will be able to create the socket.
(2) Authenticate [2] to [3]. With UNIX domain sockets, a credential
can be passed on connection, which we should do.
When [3] receives file name logX, it makes symbolic link (it could
be hard to preserve deletion but there're some issues with it) from
logX to /var/dlogd/spool/audit/logX. Every T seconds [3] pushes
spool out to [4] and logs succesful transactions. We can have some
policies here, e.g.
* Transaction fails: if (current_time - log file timestamp) > T_1
then remove log file from spool and log it
* Transaction success: schedule log file removing for T_2 period
[3] <=> [4]: At the network level we're going to use SSL certificates
for authentication.
[4] <=> [5]: We peform certification-based authentication here. And
good point is to use administrator-assigned names here based on it.
(if those corresponds to hostname or IP addresses -- that's fine)
[5] <=> [6]: If authentication went OK we receive log file and log
it to physical filesystem considering client name that we would get
at previous step.
Open questions:
1) Do we need some non-trivial network protocol in [3] <=> [5]
communication or we can just send log file content preceded by
size and name? (For example, server can ask client for missing log
files, or send message that it's alive again after some crash or
something)
2) Do we need some non-trivial API that I mentioned in [1] <=> [2]
step? Non-trivial API could be something like
dlogd_flush("/var/audit");/* Notify of fresh start. */
dlogd_created("/var/audit/whatever"); /* Notify of creation. */
dlogd_submit("/var/audit/whatever"); /* Notify of termination. */
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: System Drops to manual mount root prompt after HDD duplication
I was able to resolve this issue. Another sys-admin pointed out that my boot0cfg had the disk setup in CHS apposed to LBA. See below: |[EMAIL PROTECTED] root]# boot0cfg -v ad0 |# flag start chs type end chs offset size |1 0x80 0: 1: 1 0xa5 1023:254:63 63586067202 | |version=1.0 drive=0x80 mask=0xf ticks=182 |options=nopacket,update,nosetdrv |default_selection=F1 (Slice 1) That's a problem all right: "options=nopacket" means CHS mode. I checked th BIOS which indeed had the drive in CHS mode. I changed it to LBA as well as updated the boot0cfg: #boot0cfg -o packet ad0s1 However I still was dropped into the manual mount root prompt. While I was inspecting the BIOS I noticed that it could not see any drive larger than 130GB and the BIOS was detecting my drive as such. I moved the drive into a different machine and the problem was gone. David David Cramblett wrote: My FreeBSD 5.2.1 server had a 4.5 GB HDD. I decided to upgrade it with a larger drive. I installed a new drive on the second IDE channel which made it ad2, of course, my original drive was ad0. I created a partition, boot loader and matching slices on the new drive. Then I copied the old drive to the new drive using tar. Once finished, I removed the original drive and installed the new one on the primary channel. When I booted up everything appeared normal, but when the system starts to mount "/" it gives no error or warning and just drops to a "Manual mount root specification" prompt. If I type "ufs:ad0s1a" it boots up and everything is perfect. This is the same slice "/" was on the old drive as well. I have tried the following with no success: Checked /etc/fstab boot0cfg -v -B ad0 bsdlabel -B ad0s1 tried booting from a cd, going into post install config, fdisk, and set the partition as bootable, it already was. Since upgrading the hard disk, I have upgraded the system to 5.5 and then to 6.2. This system has been working great for over a week now, just have this boot problem. -- Here is my fstab: /dev/ad0s1b noneswapsw 0 0 /dev/ad0s1a / ufs rw 1 1 -- Output from bsdlabel # bsdlabel ad0s1 # /dev/ad0s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 585018626 10485764.2BSD 2048 16384 28552 b: 10485760 swap c: 5860672020unused0 0 # "raw" part, don't edit -- Output from boot0cfg # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5 1023:254:63 63586067202 version=1.0 drive=0x80 mask=0xf ticks=182 options=nopacket,update,nosetdrv default_selection=F1 (Slice 1) Thanks, David ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Writing a plain text file to disk from kernel space
Comments inline... Dag-Erling Smørgrav wrote: Lawrence Stewart <[EMAIL PROTECTED]> writes: Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: Since you are writing kernel code, I assume you have KDB/DDB in your kernel and know how to use it. I don't know how to use them really. Thus far I haven't had a need for really low level debugging tools... seems that may have changed though! Any good tutorials/pointers on how to get started with kernel debugging? The handbook and FAQ have information on debugging panics. Greg Lehey (grog@) does a tutorial on kernel debugging, you can probably find slides online (or just ask him) For reference, I found what looks to be a very comprehensive kernel debugging reference here: http://www.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf Greg certainly knows the ins and outs of kernel debugging! kio_write probably blocks waiting for the write to complete. You can't do that while holding a non-sleepable lock. So this is where my knowledge/understanding gets very hazy... When a thread blocks waiting for some operation to complete or event to happen, the thread effectively goes to sleep, correct? It depends on the type of lock used, but mostly, yes. Looking at the kio_write code in subr_kernio.c, I'm guessing the lock that is causing the trouble is related to the "vn_lock" function call? What matters is that kio_write() may sleep and therefore can't be called while holding a non-sleepable lock. I don't understand though why the vnode lock would be set up in such a way that when the write blocks whilst waiting for the underlying filesystem to signal everything is ok, it causes the kernel to panic! You cannot sleep while holding a non-sleepable lock. You need to find out which locks are held at the point where you call kio_write(), and figure out a way to delay the kio_write() call until those locks are released. How do I make the lock "sleepable" or make sure the thread doesn't try go to sleep whilst holding the lock? You can't make an unsleepable lock sleepable. You might be able to replace it with a sleepable lock, but you would have to go through every part of the kernel that uses the lock and make sure that it works correctly with a sleepable lock. Most likely, it won't. Thanks for the explanations. I'm starting to get a better picture of what's actually going on. So it seems that there is no way I can call kio_write from within the function that is acting as a pfil output hook, because it blocks at some point whilst doing the disk write, which makes the kernel unhappy because pfil code is holding a non-sleepable mutex somewhere. If you read my other message from yesterday, I still can't figure out why this only happens with outbound TCP traffic, but anyways... I'll have a bit more of a think about it and get back to the list shortly... Cheers, Lawrence ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
