Date: Mon, 20 Dec 1999 13:52:22 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: "Ilmar S. Habibulin" <ilmar@ints.ru> Cc: development team <devel@mx.nkm.lt>, freebsd-security@freebsd.org Subject: Re: capabilities Message-ID: <Pine.BSF.3.96.991220133516.11821A-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.9912202052130.38023-100000@ws-ilmar.ints.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
(I've added freebsd-security into the CC field to keep the world abreast of our progress, btw) On Mon, 20 Dec 1999, Ilmar S. Habibulin wrote: > On Fri, 17 Dec 1999, Robert Watson wrote: > > > Ok, so the good news is that over the past 48 hours, I've gotten commit > > access to the FreeBSD source tree, and that the interfaces for extended > > file system attributes and ACLs have gone into the tree for the 4.0 > > release. On a similarly good front, I have implemented extended > > attributes for UFS on 4.0-CURRENT, which appears to work great at this > > point. I'm still dealing with one deadlock issue, as I store the > > attributes in files off of .attribute in the FS root, and there's a > > locking order issue. They aren't currently fast, but there are lots of > > ways to optimize them and the API should be pretty fixed now. > It's great, i saw the changes. But -current still don't whant to boot at > my working box. :( This new ata driver... Supposedly now 4.0-current is stabilizing. If you're having problems getting your specific drive/controller to work with the ata stuff, I'd go ahead and contact someone.. Either email freebsd-current@, or the drive author. Unfortunately, I don't recall who that is offhand, but it should be listed in the ata source files? I know that providing support for missing chipsets is a priority. I'll be committing VOP_ documentation for the new VOPs, as well as possibly some of the ACL library code in the near future. There are a few bugs I need to wring out, and I made some last-minute change to the VOPs--for example, I no longer have VOP_RMEXTATTR, but instead use VOP_SETEXTATTR with a null uio pointer, in the same style as removing ACLs from files with VOP_SETACL. I hope to have all the documentation/etc committed by the end of the week, and will let you know when it's ready to go, along with the location of the ufs/extattr extensions so that UFS can store extended attributes. I'm trying to decide if this can easily be made a loadable kernel module, but I think it will require applying a patch to ufs/ufs and rebuilding the kernel. Because it backs attributes to seperate files either in the fs or elsewhere, as with quotas, it doesn't require modifying newfs, fsck, or your partitions :-). I haven't finished up the ACL over ExtAttr stuff yet, and hope to do that this after new years, if not before. > > The 4.0 feature freeze is RSN, possibly already happened, which means 4.0 > > should get more and more stable over the next couple of weeks, meaning we > > should probably jump onto that development line, as it has the extended > > attribute interface support and will be close to the branch we'll want to > > commit the capabilities/etc code to. > Ok. I will concentrate on CAPs first, but it will happen only after the > HNY. I'm busy right now. Sounds good--CAP probably has the most immediate appeal, but I'd really like to see MAC :-). MAC is probably a lot more intrusive than CAP, given its nature, but we'll see to what extent there's interest in getting it into the main source tree--I'd love to see it there, but recognize that its intrusiveness may limit that. > It is CAPs' land. I'm reading the POSIX again and again trying to > understand what does capabilities mean and how should i implement them. So > as i understand capabilities are something like SUID/SGID bits. Yes--that's effectively the idea. When you run the executable, it picks up additional privileges above the ones the calling process has, and presumably also you flag that process structure state so that it can't be debugged/etc to acquire the privileges from other processes owned by the same uid--I forget exactly how this works, but it's the same thing that protects setuid processes from attacks of that style (as well as limiting the effect of LD_LIBRARY_PATH, etc -- I think it's a syscall that returns "I'm special or not" to userland so the library loader can check, etc). A bitmask is one way to represent this, although I think it's desirable to consider more extensible systems for naming the capabilities in the long term. For example, you could consider a chain of capabilities, each with a name--i.e., kern.ipc.ip.tcp.80.bind or the like. The short term solution is to add a new 32 bit flag field indicating what the capabilities are for the executable :-). There's also a piece of behavior that removes the setuid bit when binaries are modified.. We might want to abscond with a flag field in the inode to optimze the check for certain key extended attributes that would impact performance (i.e., in the inode have flags EA_HAVE_ACL EA_HAVE_CAP and so on, and if it's set you know to load the attribute and do additional checks, and if not, then not to). Terry Lambert has already expressed strong opposition to consuming flags/etc, but if we're already using a modified UFS it might not hurt. On the other hand, so far I've managed to avoid changing the disk layout and partition format, and would like to continue to do so. It is probably best to accept the performance hit for the time being--there are some plans to alow refcounting in the extended attribute implementation, which would lead to far more effective caching of attribute data, especially relevant with ACLs. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.991220133516.11821A-100000>