Date: Mon, 20 Dec 1999 17:03:15 -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.991220164739.11821B-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.9912202251130.41418-100000@ws-ilmar.ints.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Dec 1999, Ilmar S. Habibulin wrote: > 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. I'm contemplating adding a trustedbsd mailing list for discussing introducing these features into FreeBSD (and possibly other BSD's), which would give a good discussion ground for things possibly too OS-specific (such as patches) for posix1e, but too detailed for -security. I haven't set this up yet, but probably I should. > > 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. ;-) The EA code is working, but is not committed, only the interface. I'll try to make the EA code on UFS available soon, but I updated the VOP interface for the commit but haven't pushed those (minor) changes back into the running codebase. Because it's not clear (see below) that the current backing arrangement is the right eventual one, my conclusion was that I wouldn't commit that for the timebeing, although I might commit hooks so it can be used as a kld at some point. > > 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? I agree that is a problem, and have been giving it a lot of thought. I think the only real answers that maintain consistency are: - Transaction-capable file system layering - Supporting EA's as meta-data directly in FFS The first would be quite hard to do, and involve rewriting a lot of FS code, so I'll leave this one for the time being. The second is more feasible, and probably equiv to the Linux integration route, except that we'd hopefully get support into softupdates which could be responsible for maintaining consistency. However, this would probably bound effective EA size limits to one disk block per inode, which is fine. I figured that the file-based arrangement is enough to get us off the ground for all the other code waiting on it, and also standardizes the interface for other file systems capable of extended attributes (HPFS, etc). The nice thing about this arrangement is it can be introduced without modifying the base file system, or renewfs'ing, unlike the modified UFS structures or layering solutions. All the techniques I've seen described for layering ACLs into FFS lose out on consistency, and require advance intent to introduce ACLs--fine in the real world, but not so good for experimentation of the sort we want to do at this point. > > > 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. Yes. I haven't really looked at implementing MAC in detail, but would be interested in pluggable policy behavior, if it were possible--I.e., you kldload the policy you want, and the hooks are all there throughout the code using the same calls... > > > 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. I believe that the posix solution is not very flexible. What it sounds like you're looking for is what my tokens and tokend provided -- the ability to attach representations of policy and crypto material to processes in a way configurable by a runtime policy, and transfer those rights. However, POSIX.1e does provide a starting point, and some standardization. Ideally in the long run we'd implement something more general and useful than POSIX.1e, but allow the POSIX.1e interface to manipulate process rights as a subset. This may not be possible, so we might have to abandon at some point. > > 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. Yes, although possibly only for operations that would be expensive anyway--I'll have to think on it further. If you're willing to introduce a more fine grained access control solution per-object as opposed to per-executable or per-principal, the way to do it might be a /rights file system which provides a namespace for kernel objects, and the administrator can apply ACLs to names in the namespace to set rights for the objects. I.e., setfacl "user:www:r" /rights/kern/ipc/ip/tcp/80 which would allow the uid for www to bind tcp 80 for listening. > > 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. Yes, that's probably easiest. My UFS EA support optimizes for a fixed-size structure per attribute name, which is great for things like ACLs, Capabilities, MAC labels, etc. > > 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. See above with /rightfs, asigning kernel objects file system-addressable names so that fs label and acl management tools can be used. Optionally to be unmounted when going multiuser, although I don't see that as strictly necessary. A general purpose way for consistently assigning access controls to kernel objects. Many other frontends could be imagined--sysctl pushing them into the kernel, etc, but I like the idea of using the POSIX.2c tools on it. > > 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. Yes--my goal was to get things moving, as the problem really seemed to be that we were blocked on disk support for security labels of various sorts. Now we can move onto the more interesting thigns, such as adapting userland software to handle these correctly, tailoring MAC algorithms, boot sequences, and so on. 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.991220164739.11821B-100000>