Date: Mon, 20 Dec 1999 23:23:18 +0300 (MSK) From: "Ilmar S. Habibulin" <ilmar@ints.ru> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: development team <devel@mx.nkm.lt>, freebsd-security@freebsd.org Subject: Re: capabilities Message-ID: <Pine.BSF.4.21.9912202251130.41418-100000@ws-ilmar.ints.ru> In-Reply-To: <Pine.BSF.3.96.991220133516.11821A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Dec 1999, Robert Watson wrote: > (I've added freebsd-security into the CC field to keep the world abreast > of our progress, btw) I wanted to cc my letters to posix. ;-) Ok, let it be security. > > 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 hope so, but i think that Intel PIIX4 is supported. Maybe it is BIOS setup problem, continue searching. and reading -current. ;-) > 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 I thought that it's already working, did not have the time to examine the code. So i will read posix againg, waiting for yours commits. ;-) > 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 :-). And have you thought about intergrity problems after crashes. Storing EA in a separate file is not identical to storing quotas in separate file, because of different sizes of data. EA data size is infinity (theoretically). So what should we do after crash while changing some of EA? > > 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. I think that CAPs is more interesting to the community. MAC is very specific access control mechanism, even integrity MAC based on Biba model. > > 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). I was upset by realizing that. I thought CAPs are something like WinNT priveleges, that are managed through user account manager. POSIX CAPs are privileges, that are managed through the fs execute permision. I don't what is better. Time will show. > 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 This is a verrry complex solution. I think it will impact performance dramatically. > 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 I what to use linux caps extention. So 32 bits are for posix caps plus 31 bits - for system specific. > 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 Good idea, but if we will implement MAC, then every system object (not only fs object) should have label. And if it have no label, then it should have system_high. And administrator must change this value - set MAC label for an object. > 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. I think that the fact of initial EA support is great. And we will develop it by common efforts. 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.4.21.9912202251130.41418-100000>