Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
David Wagner wrote: > If the attacker gets full administrator-level access on your machine, > there are a gazillion ways the attacker can prevent other admins from > logging on. This patch can't prevent that. It sounds like this patch > is trying to solve a fundamentally unsolveable problem. Tetsuo Handa wrote: > Please be aware that I'm saying "if this filesystem is used with MAC". I'm aware. I'm sticking with my argument. I doubt that any we're likely to see a MAC system that is strict enough to prevent an attacker with administrator access from locking out other admins, and is yet is loose enough to be useful in practice. I think the proposed patch is like sticking a thumb in the dike and is trying to solve a problem that cannot be solved with any reasonable application of effort. I think if the attacker has gotten administrator level, then we'll never be able to prevent the attacker from doing all sorts of bad things we don't like, like locking out other admins. Of course if we have a proposed defense that only stops one particular attack pathway but leaves dozens others open, it's always convenient to say that "the other attack pathways aren't my problem, that's the MAC's business". Sure, if we want to hypothesize the existence of a "magic fairy dust" MAC system that somehow closes every other path via which admin-level attackers could lock out other admins, except for this one pathway, then this patch might make sense. But I see no reason to expect ordinary MAC systems to have that property. Trying to put in place a defense that only prevents on particular attack path, when there are a thousand other ways an attacker might achieve the same ends, does not seem like a good way to go about securing your system. For every one attack path that you shut down, the attacker can probably think up a dozen new paths that you haven't shut down yet. That isn't a good basis for security. Personally, I'd argue that we should learn a different lesson from the attack you experienced. The lesson is not "oh boy, we better shut down this particular way that the attacker misused administrator-level access". I think a better lesson is "let's think about ways to reduce the likelihood that attackers will get administrator-level access, because once the attacker has administrator-level access, the attacker can do a lot of harm". >If MAC(such as SELinux, TOMOYO Linux) allows attackers to >"mount other filesystem over this filesystem", this filesystem is no >longer tamper-proof. >But as long as MAC prevents attackers from mounting other filesystem >over this filesystem, >this filesystem can remain tamper-proof. But the point is that it's not enough just to prevent attackers from mounting other filesystems over this filesystem. I can think of all sorts of ways that an admin-level attacker might be able to prevent other administrators from logging in. If your defense strategy involves trying to enumerate all of those possible ways and then shut them down one by one, you're relying upon a defense strategy known as "blacklisting". Blacklisting has a terrible track record in the security field, because it's too easy to overlook one pathway. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Tetsuo Handa writes: >When I attended at Security Stadium 2003 as a defense side, >I was using devfs for /dev directory. The files in /dev directory >were deleted by attckers and the administrator was unable to login. If the attacker gets full administrator-level access on your machine, there are a gazillion ways the attacker can prevent other admins from logging on. This patch can't prevent that. It sounds like this patch is trying to solve a fundamentally unsolveable problem. A useful slogan: "Don't forbid what you cannot prevent." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
James Morris wrote: >A. Pathname labeling - applying access control to pathnames to objects, >rather than labeling the objects themselves. > >Think of this as, say, securing your house by putting a gate in the street >in front of the house, regardless of how many other possible paths there >are to the house via other streets, adjoining properties etc. > >Pathname labeling and mediation is simply mediating a well-known path to >the object. In this analogy, object labeling would instead ensure that >all of the accessible doors, windows and other entrances of the house were >locked, so that someone trying to break in from the rear alley would >not get in simply by bypassing the front gate and opening any door. > >What you do with AppArmor, instead of addressing the problem, is just >redefine the environment along the lines of "set your house into a rock >wall so there is only one path to it". Harrumph. Those analogies sound good but aren't a very good guide. Let's take a concrete example. Consider the following fragment of a policy for Mozilla: allow ~/.mozilla deny ~ Ignore the syntax; the goal is to allow Mozilla to access files under ~/.mozilla but nothing else under my home directory. This is a perfectly reasonable policy fragment to want to enforce. And enforcing it in the obvious way using pathname-based access control is not a ridiculous thing to do. Yes, in theory, there could always be crazy symlinks or hardlinks from somewhere under ~/.mozilla to elsewhere in my home directory that would cause this policy to behave in ways different from how I desired. In theory. But in practice this is "pretty good": good enough to be useful in the real world. In the real world I don't have any symlinks like that under my ~/.mozilla directory, and I'm not really worried about unconfined processes accidentally creating a symlink under there against my wishes. It'd be good enough for me. Yes, pathname-based models have limitations and weaknesses, but don't overplay them. For some purposes they are a very simple way of specifying a desired policy and they work well enough to be useful -- a darn site better than what we've got today. If your goal is "ease of use" and "better than what many users are using today", it's not an unreasonable approach. Time will tell whether it's the best solution, but it's not obviously wrong. And I think that's the criteria: If you want to argue that the very idea of pathname-based access control so bogus that no approach to pathname-based security should be merged, then you should have to argue that it is obviously wrong and obviously not useful to users. I don't think that burden has been met. >B. Pathname access control as a general abstraction for OS security. This strikes me as a strawman. Pathname-based access control is an abstraction for mediating the *filesystem*. Who says it has to be the way you mediate the network or IPC? >To quote from: > >http://www.novell.com/linux/security/apparmor/ > > "AppArmor gives you network application security via mandatory access > control for programs, protecting against the exploitation of software > flaws and compromised systems. AppArmor includes everything you need to > provide effective containment for programs (including those that run as > root) to thwart attempted exploits and even zero-day attacks." > >This is not accurate in any sense of the term containment of mandatory >access control that I've previously encountered. You bet. The claim you quote is totally bogus. Bad marketers, no biscuit for you. >The fact that it doesn't work as expected does not arise simply from >missing features or being "different". It arises from the design of the >system, which uses a pathname abstraction, where, even if we agree to >ignore issue (1) above, still does not work, because only filesystem >interactions are mediated. Disagree. >The "simple" policy that users can so effortlessly manipulate is simple >because it is wrong, and deliberately so. > >The design of the AppArmor is based on _appearing simple_, but at the >expense of completeness and thus correctness. Based on my experience with Janus, my expectation is the policy isn't going to get that much more complicated when they add mediation of network and IPC access. I suspect it will stay almost as simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
James Morris wrote: >The point is that the pathname model does not generalize, and that >AppArmor's inability to provide adequate coverage of the system is a >design issue arising from this. I don't see it. I don't see why you call this a design issue. Isn't this just a case where they haven't gotten around to implementing network and IPC mediation yet? How is that a design issue arising from a pathname-based model? For instance, one system I built (Janus) provided complete mediation, including mediation of network and IPC, yet it too used a pathname model for its policy file when describing the policy for the filesystem. That seems to contradict your statement. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
I've heard four arguments against merging AA. Argument 1. SELinux does it better than AA. (Or: SELinux dominates AA. Or: SELinux can do everything that AA can.) Argument 2. Object labeling (or: information flow control) is more secure than pathname-based access control. Argument 3. AA isn't complete until it mediates network and IPC. Argument 4. AA doesn't have buy-in from VFS maintainers. Let me comment on these one-by-one. 1. I think this is a bogus argument for rejecting AA. As I remember it, the whole point of LSM was to allow merging multiple solutions and let them compete for users on their merit, not to force the Linux maintainers to figure out which is the best solution. Let a million flowers bloom. 2. This is argument #1 in a different guise and I find it about as weak. Pathname-based access control has strengths and weaknesses. I think users and Linux distributions are in a better position to evaluate those tradeoffs than L-K. Competition is good. 3. This one I agree with. If you want to sandbox network daemons that you're concerned might get hacked, then you really want your sandbox to mediate everything. Right now the security provided by AA (if that's what you are using it for) will be limited by its incomplete mediation, since a knowledgeable motivated attacker who hacks your daemon may be able to use network or IPC to break out of the sandbox, depending upon the network and host configuration. Filesystem mediation alone might be better than nothing, I suppose, if you're worried about script kiddies, but it's certainly not a basis for strong security claims. The state of the art in sandboxing obviously requires complete mediation, and we've known that for a decade. That said, I see filesystem mediation as the hard part. It's the hardest part to implement and get right. It's the hardest part to configure and the hardest part when it comes to designing usable policy languages. And I suspect it's the hardest part to get merged into the Linux kernel. And it often makes sense to start with the hard part. If AA's approach to mediating the filesystem is acceptable, I think AA is 2/3rds of the way to a tool that could be very useful for providing strong security claims. There's a policy decision here: Do maintainers refuse to merge AA until it provides complete mediation? That's a policy matter that's up to the maintainers. I have no opinion on it. However if that is the reason for rejecting AA it seems like it might be appropriate to come to some decision now about whether AA's approach to filesystem mediation is acceptable to Linux developers. I don't think it would be reasonable to tell AA developers to go spend a few months developing network and IPC mediation and then after they do that, to reject the whole thing on the basis that the approach to filesystem mediation is unacceptable. That won't encourage development of new and innovative approaches to security, which doesn't seem like a good thing to me. 4. Way over my head. I'm not qualified to comment on this aspect. I suspect this is the argument that ought to be getting the most serious and thorough discussion, not the irrelevant SELinux-vs-AA faceoff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Stephen Smalley wrote: >On Fri, 2007-06-22 at 01:06 -0700, John Johansen wrote: >> No the "incomplete" mediation does not flow from the design. We have >> deliberately focused on doing the necessary modifications for pathname >> based mediation. The IPC and network mediation are a wip. > >The fact that you have to go back to the drawing board for them is that >you didn't get the abstraction right in the first place. Calling this "going back to the drawing board" board strikes me as an unfair criticism, when the real situation is that in the future the AA folks will need to extend their code to mediate network and IPC (not throw all the current code away and start over from scratch, and not replace big swaths of the current code). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Stephen Smalley wrote: >That would certainly help, although one might quibble with the use of >the word "confinement" at all wrt AppArmor (it has a long-established >technical meaning that implies information flow control, and that goes >beyond even complete mediation - it requires global and persistent >protection of the data based on its properties, which requires stable >and unambiguous identifiers). 1. Yes, that's the usage that has the greatest historical claim, but "confinement" has also been used in the security community to refer to limiting the overt side effects a process can have rather than controlling information flow. The term "confinement" is arguably ambiguous, but I think there is a semi-established meaning that doesn't imply information flow control. 2. This is a can of worms we probably don't want to open. Keep in mind that SELinux doesn't meet definition of confinement in Lampson's original paper, either, because it only restricts overt information flows. SELinux doesn't prevent covert channels, even though Lampson's original paper included them as part of the confinement problem. Yet I don't think it would be reasonable to criticize someone for describing SELinux as a tool for "confinement". I don't know of any practical solution that solves the confinement problem as Lampson envisioned it. I'd recommend making decisions on the basis of whether the mechanisms are useful, rather than whether they solve Lampson's notion of the "confinement" problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Stephen Smalley wrote: >On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote: >> And now, yes, I know AA doesn't mediate IPC or networking (yet), but >> that's a missing feature, not broken by design. > >The incomplete mediation flows from the design, since the pathname-based >mediation doesn't generalize to cover all objects unlike label- or >attribute-based mediation. I don't see anything in the AA design that would prevent an extending it to mediate network and IPC while remaining consistent with its design so far. Do you? It seems to me the AA design is to mediate filesystem access using pathname-based access control, and that says nothing about how they mediate network access. I have built sandboxing tools before, and my experience is that the filesystem mediation is the hardest, gronkiest part. In comparison, mediating networking and IPC is considerably easier. The policy language for mediating access to the network can be pretty simple. The same for IPC. Obviously you shouldn't expect the policy language for networking to use filenames, any more than you should expect the policy languages for filesystems to use TCP/IP port numbers; that wouldn't make any sense. >And the "use the natural abstraction for >each object type" approach likewise doesn't yield any general model or >anything that you can analyze systematically for data flow. I don't see this as relevant to whether AA should be merged. Fight that one in the marketplace for users, not L-K. >> If I restrict my Mozilla to not access my on-disk mail folder, it can't >> get there. (Barring bugs in programs which Mozilla is allowed to run >> unconfined, sure.) > >Um, no. It might not be able to directly open files via that path, but >showing that it can never read or write your mail is a rather different >matter. "Showing that it can never read or write your mail" is not part of AA's goals. People whose goals differ from AA's can use a different tool. No one is forcing you to use AA if it isn't useful to you. I don't see this criticism as relevant to a merger decision. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
[EMAIL PROTECTED] writes: >Experience over on the Windows side of the fence indicates that "remote bad >guys get some local user first" is a *MAJOR* part of the current real-world >threat model - the vast majority of successful attacks on end-user boxes these >days start off with either "Get user to (click on link|open attachment)" or >"Subvert the path to a website (either by hacking the real site or hijacking >the DNS) and deliver a drive-by fruiting when the user visits the page". AppArmor isn't trying to defend everyday users from getting phished or social engineered; it is trying to protect servers from getting rooted because of security holes in their network daemons. I find that a laudable goal. Sure, it doesn't solve every security problem in the world, but so what? A tool that could solve that one security problem would still be a useful thing, even if it did nothing else. I don't find the Windows stuff too relevant here. As I understand it, AppArmor isn't aimed at defending Windows desktop users; it is aimed at defending Linux servers. A pretty different environment, I'd say. Ultimately, there are some things AppArmor may be good at, and there are also sure to be some things it is bloody useless for. My hammer isn't very good for screwing in screws, but I still find it useful. I confess I don't understand the kvetching about AppArmor's goals. What are you expecting, some kind of silver bullet? A question I'd find more interesting is whether AppArmor is able to meet its stated goals, under a reasonable threat model, and with what degree of assurance, and at what cost. But I don't know whether that's relevant for the linux-kernel mailing list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
[EMAIL PROTECTED] wrote: > no, this won't help you much against local users, [...] Pavel Machek wrote: >Hmm, I guess I'd love "it is useless on multiuser boxes" to become >standard part of AA advertising. That's not quite what david@ said. As I understand it, AppArmor is not focused on preventing attacks by local users against other local users; that's not the main problem it is trying to solve. Rather, it's primary purpose is to deal with attacks by remote bad guys against your network servers. That is a laudable goal. Anything that helps reduce the impact of remote exploits is bound to be useful, even if doesn't do a darn thing to stop local users from attacking each other. This means that AppArmor could still be useful on multiuser boxes, even if that utility is limited to defending (some) network daemons against remote attack (or, more precisely, reducing the damage done by a successful remote attack against a network daemon). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Stephen Smalley wrote: >Integrity protection requires information flow control; you can't >protect a high integrity process from being corrupted by a low integrity >process if you don't control the flow of information. Plenty of attacks >take the form of a untrusted process injecting data that will ultimately >be used by a more trusted process with a surprising side effect. I don't agree with this blanket statement. In a number of cases of practical interest, useful integrity protection can be achieved without full information flow control. Suppose you have a malicious ("low integrity") process A, and a target ("high integrity") process B. We want to prevent A from attacking B. One way to do that is to ensure that A has no overt channel it can use to attack process B, by severely restricting A's ability to cause side effects on the rest of the world. This is often sufficient to contain the damage that A can do. Of course, if the intended functionality of the system requires A to communicate data to B, and if you don't trust B's ability to handle that data carefully enough, and if A is malicious, then you've got a serious problem. But in a number of cases (enough cases to be useful), you can provide a useful level of security without needing information flow control and without needing global, persistent labels. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Crispin Cowan wrote: > How is it that you think a buffer overflow in httpd could allow an > attacker to break out of an AppArmor profile? James Morris wrote: > [...] you can change the behavior of the application and then bypass > policy entirely by utilizing any mechanism other than direct filesystem > access: IPC, shared memory, Unix domain sockets, local IP networking, > remote networking etc. [...] > Just look at their code and their own description of AppArmor. My gosh, you're right. What the heck? With all due respect to the developers of AppArmor, I can't help thinking that that's pretty lame. I think this raises substantial questions about the value of AppArmor. What is the point of having a jail if it leaves gaping holes that malicious code could use to escape? And why isn't this documented clearly, with the implications fully explained? I would like to hear the AppArmor developers defend this design decision. When we developed Janus, over 10 years ago, we defended against these attack avenues and protected everything -- not just the filesystem. Systrace does the same, as does Plash. So does Consh, and MapBox, and Ostia, to name a few other examples from the research world. This is standard stuff that is well-documented in the literature, and it seems to me it is necessary before you can claim to have a useful jail. What am I missing? P.S. I think the criticisms that "AppArmor is pathname-based" or "AppArmor doesn't do everything SELinux does" or "AppArmor doesn't do information flow control" are weak. But the criticism that "AppArmor leaves security holes that can be used to escape the jail" seems like a serious criticism to me. Perhaps a change of focus is in order. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Stephen Smalley wrote: >Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM >Vol 16 No 10) means information flow control, which you have agreed >AppArmor does not and cannot provide. Right, that's how I understand it, too. However, I think some more caveats are in order. In all honesty, I don't think SELinux solves Lampson's problem, either. It is useful to distinguish between "bit-confinement" (confining the flow of information, a la Lampson) vs "authority-confinement" (confining the flow of privileges and the ability of the untrusted app to cause side effects on the rest of the system). No Linux system provides bit-confinement, if the confined app is malicious. AppArmor does not provide bit-confinement. Neither does SELinux. SELinux can stop some kinds of accidental leakage of secrets, but it cannot prevent deliberate attempts to leak the secrets that are known to malicious apps. The reason is that, in every system under consideration, it is easy for a malicious app to leak any secrets it might have to the outside world by using covert channels (e.g., wall-banging). In practical terms, Lampson's bit-confinement problem is just not solvable. Oh well, so it goes. A good jail needs to provide authority-confinement, but thankfully, it doesn't need to provide bit-confinement. I don't know enough about AppArmor to know whether it is able to do a good job of providing authority-confinement. If it cannot, then it deserves criticism on those grounds. Often the pragmatic solution to the covert channel problem is to ensure that untrusted apps are never given access to critical secrets in the first place. They can't leak something they don't know. This solves the confidentiality problem by avoiding any attempt to tackle the unsolvable bit-confinement problem. Note that the problem of building a good jail is a little different from the information flow control problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
James Morris wrote: >On Wed, 18 Apr 2007, Crispin Cowan wrote: >> How is it that you think a buffer overflow in httpd could allow an >> attacker to break out of an AppArmor profile? > >Because you can change the behavior of the application and then bypass >policy entirely by utilizing any mechanism other than direct filesystem >access: IPC, shared memory, Unix domain sockets, local IP networking, >remote networking etc. Any halfway decent jail will let you control access to all of those things, thereby preventing an 0wned httpd from breaking out of the jail. (For instance, Janus did. So does Systrace.) Are you saying AppArmor does not allow that kind of control? Specifics would be useful. >Also worth noting here is that you have to consider any limited >environment as enforcing security policy, and thus its configuration >becomes an additional component of security policy. I don't understand what you are saying. Yes, the AppArmor policy file is part of policy. Is that what you mean? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
James Morris wrote: >This is not what the discussion is about. It's about addressing the many >points in the FAQ posted here which are likely to cause misunderstandings, >and then subsequent responses of a similar nature. Thank you. Then I misunderstood, and I owe you an apology. Thank you for your patience and for correcting my mistaken impression. For what it's worth, I agreed with most or all of the comments you made in your original response to the FAQ posted here. I thought they were constructive. What got me to ranting was an email from Karl MacMillan that seemed focused more on debating the merits of AppArmor rather than on improving the FAQ. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
James Morris wrote: >On Tue, 17 Apr 2007, David Wagner wrote: >> Maybe you'd like to confine the PHP interpreter to limit what it can do. >> That might be a good application for something like AppArmor. You don't >> need comprehensive information flow control for that kind of use, and >> it would likely just get in the way. > >SELinux can do this, it's policy-flexible. You can even simulate a >pathame-based policy language with a consequential loss of control: I have no doubt that SELinux can do that, but that has about as much relevance to my point as the price of tea in China does. I can use a screwdriver to drive in a nail into my wall, too, if I really wanted to, but that doesn't mean toolmakers should stop manufacturing hammers. My point is that there are some tasks where it's plausible that AppArmor might well be a better (easier-to-use) tool for the job. I'm inclined to suspect I might find it easier to use AppArmor for this kind of task than SELinux, and I suspect I'm not the only one. That doesn't mean that AppArmor is somehow inherently superior to SELinux, or something like that. No one is claiming that AppArmor is "a better SELinux". It solves a somewhat different problem, and has a different set of tradeoffs. It seems potentially useful. That ought to be enough. The world does not revolve around SELinux. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
James Morris wrote: >I would challenge the claim that AppArmor offers any magic bullet for >ease of use. There are, of course, no magic bullets for ease of use. I would not make such a strong claim. I simply stated that it is plausible that AppArmor might have some advantages in some deployment environments. The purpose of LSM was to enable multiple different approaches to security, so that we don't have to fight over the One True Way to do it. There might not be one best way for all situations. These systems probably have different tradeoffs. Consequently, it seems to me that arguing over whether SELinux is superior to AppArmor makes about as much sense as arguing over whether emacs is superior to vim, or whether Python is superior to Perl. The answer is likely to be "it depends". It's to be expected that SELinux developers prefer their own system over AppArmor, or that AppArmor developers prefer AppArmor to SELinux. (Have you ever seen any new parent who thinks their own baby is ugly?) SELinux developers are likely to have built a system that addresses the problems that seem important to them; other systems might set priorities differently. I think in this case the best remedy is to let many flowers bloom, and let the users decide for themselves. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Karl MacMillan wrote: >My private ssh keys need to be protected regardless >of the file name - it is the "bag of bits" that make it important not >the name. I think you picked a bad example. That's a confidentiality policy. AppArmor can't make any guarantees about confidentiality. Neither can SELinux. If you give a malicious app the power to read your private ssh key, it's game over, dude. (Covert channels, wall banging, and all that.) So don't do that. >Similarly, you protect the integrity of the applications that >need name resolution by ensuring that the data that they read is high >integrity. You do that by controlling data not the file name used to >access the data. That is James point - a comprehensive mechanism like >SELinux allows you to comprehensively protect the integrity of data. I think this argument just misses the point. What you want isn't what AppArmor does. Fine. Nobody is forcing you to use AppArmor. But that doesn't mean AppArmor is useless. There may be people who want what AppArmor has to provide. It sounds like you want a comprehensive information flow control system. That's not what AppArmor provides. If I understand correctly, one thing AppArmor does provide is a way to confine untrusted legacy apps in a restricted jail. That can be useful in some scenarios. Consider, for instance, a web server where untrusted users can upload PHP scripts, and you're concerned that those PHP scripts might be malicious. Maybe you'd like to confine the PHP interpreter to limit what it can do. That might be a good application for something like AppArmor. You don't need comprehensive information flow control for that kind of use, and it would likely just get in the way. Those who want a information flow control system, will probably use SELinux or something like it. Those who want what AppArmor has to offer, might well use AppArmor. They solve different problems and have different tradeoffs. There is room for more than one security tool in the world. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Karl MacMillan wrote: >I don't think that the ease-of-use issue is clear cut. The hard part of >understanding both SELinux policies and AppArmor profiles is >understanding what access should be allowed. [...] >Whether the access is allowed with the SELinux or >AppArmor language seems like a small issue in comparison. Given that I >think it is better to choose the solution that is complete and capable >of meeting the most security concerns. I have a different reaction. Given that the ease of use vs completeness issues are not completely understood, I would think it would make more sense to include both in the kernel. Wasn't that the whole point of the LSM interface, to let competing approaches bloom and compete on their merits? I have to say that I'm not convinced the difference in policy languages is a small issue. I find the SELinux policy language and policy files more or less inscrutable. In comparison, from the AppArmor FAQ, I can imagine that I might be able to understand enough to hack AppArmor policies after 5 minutes of reading a man page. Whether I'm likely to know what the policy ought to be is indeed a tough question, but I can imagine that AppArmor might be more usable than SELinux. Even if SELinux is more "complete" than AppArmor, I might still prefer ease of use over completeness and understandability. And I have to say that the ability to form a mental model of how the system works and understand more or less what it is doing may be useful. I find debugging SELinux problems a bear: I often just end up disabling entire SELinux policies, or turning off SELinux, because I can't understand what it's doing. In comparison, it's plausible that it might be easier for sysadmins to understand what AppArmor is doing, since they don't have to understand labelling and hard-to-read policy files. And the increase in understandability might potentially outweigh the "completeness" issue, in some cases. Ultimately, easier to use and easier to understand tools might better solve security overall, because they are more likely to be used and to be used correctly. Bottom line: I think the comparison regarding ease of use is a bit speculative at this point, but I think there is sufficient reason for thinking that AppArmor might be a useful tool in some deployment environments. >I'd also argue that the typical interface presented to admins (which >doesn't involve writing new policies) is easier for SELinux than with >AppArmor. Most admins do fine with relabeling, changing booleans, and >running audit2allow, which is all that is needed to solve the majority >of SELinux issues. Heh. I had to chuckle at that one: it is pretty far removed from my own personal experience. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/41] AppArmor security module overview
Pavel Machek wrote: > David Wagner wrote: >> There was no way to follow fork securely. > >Actually there is now. I did something similar called subterfugue and >we solved this one. Yes, I saw that. I thought subterfugue was neat. The way that subterfugue was a clever hack -- albeit too clever by half, in my opinion. Dynamically re-writing the program on the fly to insert a trap after the fork() call, right? When the tracer has to do that kind of thing, I find it hard to get confidence that it will be secure. It seems all too easy to imagine ways that the tracee might be able to escape the tracing and break security. There are all sorts of corner cases to think about. What if the program is executing from shared memory? What if there are multiple threads running concurrently? What if the program is executing from a region of memory where a DMA is scheduled to asynchronously write to? Any of those cases could create a race condition (TOCTTOU) where the trap after the fork() gets removed before the program reaches that point of execution. ptrace() seems like a fine answer for a debugger, but I think it's not such a great answer for a security tool where you have to be dead-certain there is no way to escape the sandbox. When I'm relying upon something for security, the last thing you want is to have to go through hairy kludgy kludgy contortions to make up for flaws in the interface. Complexity is the enemy of security. I still think that ptrace() is not the best way to implement this kind of security tool, and I think it's entirely understandable that they did not use ptrace. I do not think it is a fair criticism of AppArmor to say "AppArmor should have used ptrace()". >> Handling of signals is a mess: ptrace overloads the >> signal mechanism to deliver its events, [...] > >We got this solved in linux, I believe. Out of curiousity, how was this solved? It looked pretty fundamental to me. Thanks for your comments... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend][CRYPTO]: RSA algorithm patch
Indan Zupancic wrote: >On Thu, April 12, 2007 11:35, Satyam Sharma wrote: >> 1. First, sorry, I don't think an RSA implementation not conforming to >> PKCS #1 qualifies to be called RSA at all. That is definitely a *must* >> -- why break strong crypto algorithms such as RSA by implementing them >> in insecure ways? > >It's still RSA, that it's not enough to get a complete and secure crypto >system doesn't mean it isn't RSA anymore. Maybe you're right and having >RSA without the rest makes no sense. Yes, Satyam Sharma is 100% correct. Unpadded RSA makes no sense. RSA is not secure if you omit the padding. If you have a good reason why RSA needs to be in the kernel for security reasons, then the padding has to be in the kernel, too. Putting plain unpadded RSA in the kernel seems bogus. I worry about the quality of this patch if it is using unpadded RSA. This is pretty elementary stuff. No one should be implementing their own crypto code unless they have considerable competence and knowledge of cryptography. This elementary error leaves reason to be concerned about whether the developer of this patch has the skills that are needed to write this kind of code and get it right. People often take it personally when I tell them that they do are not competent to write their own crypto code, but this is not a personal attack. It takes very specialized knowledge and considerable study before one can write your own crypto implementation from scratch and have a good chance that the result will be secure. People without those skills shouldn't be writing their own crypto code, at least not if security is important, because it's too easy to get something wrong. (No, just reading Applied Cryptography is not good enough.) My experience is that code that contains elementary errors like this is also likely to contain more subtle errors that are harder to spot. In short, I'm not getting warm fuzzies here. And no, you can't just blithely push padding into user space and expect that to make the security issues go away. If you are putting the RSA exponentiation in the kernel because you don't trust user space, then you have to put the padding in the kernel, too, otherwise you're vulnerable to attack from evil user space code. It is also not true that padding schemes change all the time. They're fairly stable. Pick a reasonable modern padding scheme and leave it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/41] AppArmor security module overview
Pavel Machek wrote: >You can do the same with ptrace. If that's not fast enough... improve >ptrace? I did my Master's thesis on a system called Janus that tried using ptrace for this goal. The bottom line is that ptrace sucks for this purpose. It is a kludge. It is not the right approach. I do not know of any satisfactory way to improve ptrace for this purpose; you have to throw away ptrace and start over. At the time I did the work, ptrace has all sorts of serious problems. Here are some of them. There was no way to follow fork securely. There was no way to deny a single system call without killing the process entirely. Performance was poor, because ptrace context-switches on every read() and write(). Handling of signals is a mess: ptrace overloads the signal mechanism to deliver its events, which in retrospect was a lousy design decision it makes the tracer complex and error-prone and makes it hard to maintain the transparency of tracing. ptrace breaks wait(), and consequently handling wait() and other signal-related system calls transparently and securely is ugly at best. Handling signals is probably feasible but a total mess, and that's the last thing you want in the security-critical part of your system. In addition, ptrace operates at the wrong level of abstraction and forces the user-level tracer to maintain a lot of shadow state that must be kept in sync with state held by the kernel. That's an opportunity for security holes. Also, ptrace has no way to force the tracee to die if the tracer unexpectedly dies, which is risky when using ptrace for security confinement. I haven't checked whether these problems are still present in the current implementation of ptrace, but I'd guess that many probably still are, because many are fundamental consequences of how ptrace works. Before advocating ptrace for this purpose, I encourage you to study some of the relevant literature. Start with Chapter 4 of my Master's thesis. http://www.cs.berkeley.edu/~daw/papers/janus-masters.ps Then, read Tal Garfinkel's paper on system call interposition. http://www.stanford.edu/~talg/papers/traps/abstract.html Then, read about Ostia. http://www.stanford.edu/~talg/papers/NDSS04/abstract.html I think these may change your mind about the suitability of ptrace for this task. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
Samium Gromoff wrote: >[...] directly setuid root the lisp system executable itself [...] Like I said, that sounds like a bad idea to me. Sounds like a recipe for privilege escalation vulnerabilities. Was the lisp system executable really implemented to be secure even when you make it setuid root? Setting the setuid-root bit on programs that didn't expect to be setuid-root is generally not a very safe thing to do. [1] The more I hear, the more unconvinced I am by this use case. If you don't care about the security issues created by (mis)using the lisp interpreter in this way, then like I suggested before, you can always write a tiny setuid-root wrapper program that turns off address space randomization and exec()s the lisp system executable, and leave the lisp system executable non-setuid and don't touch the code in the Linux kernel. That strikes me as a better solution: those who don't mind the security risks can take all the risks they want, without forcing others to take unwanted and unnecessary risks. It's not that I'm wedded to address space randomization of setuid programs, or that I think it would be a disaster if this patch were accepted. Local privilege escalation attacks aren't the end of the world; in all honesty, they're pretty much irrelevant to many or most users. It's just that the arguments I'm hearing advanced in support of this change seem dubious, and the change does eliminate one of the defenses against a certain (narrow) class of attacks. [1] In comparison, suidperl was designed to be installed setuid-root, and it takes special precautions to be safe in this usage. (And even it has had some security vulnerabilities, despite its best efforts, which illustrates how tricky this business can be.) Setting the setuid-root bit on a large complex interpreter that wasn't designed to be setuid-root seems like a pretty dubious proposition to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
Samium Gromoff wrote: >the core of the problem are the cores which are customarily >dumped by lisps during the environment generation (or modification) stage, >and then mapped back, every time the environment is invoked. > >at the current step of evolution, those core files are not relocatable >in certain natively compiling lisp systems. > >in an even smaller subset of them, these cores are placed after >the shared libraries and the executable. > >which obviously breaks when the latter are placed unpredictably. >(yes, i know, currently mmap_base() varies over a 1MB range, but who >says it will last indefinitely -- probably one day these people >from full-disclosure will prevail and it will become, like, 256MB ;-) > >so, what do you propose? The obvious solution is: Don't make them setuid root. Then this issue disappears. If there is some strong reason why they need to be setuid root, then you'll need to explain that reason and your requirements in more detail. But, based on your explanation so far, I have serious doubts about whether it is a good idea to make such core-dumps setuid root in the first place. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
Samium Gromoff wrote: >This patch removes the dropping of ADDR_NO_RANDOMIZE upon execution of setuid >binaries. > >Why? The answer consists of two parts: > >Firstly, there are valid applications which need an unadulterated memory map. >Some of those which do their memory management, like lisp systems (like SBCL). >They try to achieve this by setting ADDR_NO_RANDOMIZE and reexecuting >themselves. > >Secondly, there also are valid reasons to want those applications to be setuid >root. Like poking hardware. This has the unfortunate side-effect of making it easier for local attackers to mount privilege escalation attacks against setuid binaries -- even those setuid binaries that don't need unadulterated memory maps. There's a cleaner solution to the problem case you mentioned. Rather than re-exec()ing itself, the application could be split into two executables: the first is a tiny setuid-root wrapper which sets ADDR_NO_RANDOMIZE and then executes the second program; the second is not setuid-anything and does all the real work. Such a decomposition is often better for security for other reasons, too (such as the fact that the wrapper can drop all unneeded privileges before exec()ing the second executable). Why would you need an entire lisp system to be setuid root? That sounds like a really bad idea. I fail to see why that is a relevant example. Perhaps the fact that such a lisp system breaks if you have security features enabled should tell you something. It may be possible to defeat address space randomization in some cases, but that doesn't mean address space randomization is worthless. It sounds like there is a tradeoff between security and backwards compatibility. I don't claim to know how to choose between those tradeoffs, but I think one ought to at least be aware of the pros and cons on both sides. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Entropy Pool Contents
Continuing the tangent: Henrique de Moraes Holschuh wrote: >On Mon, 27 Nov 2006, Ben Pfaff wrote: >> [EMAIL PROTECTED] (David Wagner) writes: >> > Well, if you want to talk about really high-value keys like the scenarios >> > you mention, you probably shouldn't be using /dev/random, either; you >> > should be using a hardware security module with a built-in FIPS certified >> > hardware random number source. >> >> Is there such a thing? [...] > >There used to exist a battery of tests for this, but a FIPS revision removed >them. [...] The point I was making in my email was not about the use of FIPS randomness tests. The FIPS randomness tests are not very important. The point I was making was about the use of a hardware security module to store really high-value keys. If you have a really high-value key, that key should never be stored on a Linux server: standard advice is that it should be generated on a hardware security module (HSM) and never leave the HSM. If you are in charge of Verisign's root cert private key, you should never let this private key escape onto any general-purpose computer (including any Linux machine). The reason for this advice is that it's probably much harder to hack a HSM remotely than to hack a general-purpose computer (such as a Linux machine). Again, this is probably a tangent from anything related to Linux kernel development. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Entropy Pool Contents
Warning: tangent with little practical relevance follows: Kyle Moffett wrote: >Actually, our current /dev/random implementation is secure even if >the cryptographic algorithms can be broken under traditional >circumstances. Maybe. But, I've never seen any careful analysis to support this or characterize exactly what assumptions are needed for this to be true. Some weakened version of your claim might be accurate, but at a minimum you probably need to make some heuristic assumptions about the sources of randomness and the distribution of values they generate, and you may also need some assumptions that the SHA hash function isn't *totally* broken. If you make worst-case assumptions, I doubt that this claim can be justified in any rigorous way. (For instance, compressing random samples with the CRC process is a heuristic that presumably works fine for most randomness sources, but it cannot be theoretically justified: there exist sources for which it is problematic. Also, the entropy estimator is heuristic and will overestimate the true amount of entropy available, for some sources. Likewise, if you assume that the cryptographic hash function is totally insecure, then it is plausible that carefully chosen malicious writes to /dev/random might be able to reduce the total amount of entropy in the pool -- at least, I don't see how to prove that this is impossible.) Anyway, I suspect this is all pretty thoroughly irrelevant in practice. It is very unlikely that the crypto schemes are the weakest link in the security of a typical Linux system, so I'm just not terribly worried about the scenario where the cryptography is completely broken. It's like talking about whether, hypothetically, /dev/random would still be secure if pigs had wings. >When generating long-term cryptographic private keys, however, you >*should* use /dev/random as it provides better guarantees about >theoretical randomness security than does /dev/urandom. Such >guarantees are useful when the random data will be used as a >fundamental cornerstone of data security for a server or network >(think your root CA certificate or HTTPS certificate for your million- >dollar-per-year web store). Well, if you want to talk about really high-value keys like the scenarios you mention, you probably shouldn't be using /dev/random, either; you should be using a hardware security module with a built-in FIPS certified hardware random number source. The risk of your server getting hacked probably exceeds the risk of a PRNG failure. I agree that there is a plausible argument that it's safer to use /dev/random when generating, say, your long-term PGP private key. I think that's a reasonable view. Still, the difference in risk level in practice is probably fairly minor. The algorithms that use that private key are probably going to rely upon the security of hash functions and other crypto primitives, anyway. So if you assume that all modern crypto algorithms are secure, then /dev/urandom may be just as good as /dev/random; whereas if you assume that all modern crypto algorithms are broken, then it may not matter much what you do. I can see a reasonable argument for using /dev/random for those kinds of keys, on general paranoia and defense-in-depth grounds, but you're shooting at a somewhat narrow target. You only benefit if the crypto algorithms are broken just enough to make a difference between /dev/random and /dev/urandom, but not broken enough to make PGP insecure no matter how you pick your random numbers. That's the narrow target. There are better things to spend your time worrying about. Nothing you say is unreasonable; I'm just sharing a slightly different perspective on it all. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Entropy Pool Contents
Phillip Susi wrote: >David Wagner wrote: >> Nope, I don't think so. If they could, that would be a security hole, >> but /dev/{,u}random was designed to try to make this impossible, assuming >> the cryptographic algorithms are secure. >> >> After all, some of the entropy sources come from untrusted sources and >> could be manipulated by an external adversary who doesn't have any >> account on your machine (root or non-root), so the scheme has to be >> secure against introduction of maliciously chosen samples in any event. > >Assuming it works because it would be a bug if it didn't is a logical >fallacy. Either the new entropy pool is guaranteed to be improved by >injecting data or it isn't. If it is, then only root should be allowed >to inject data. If it isn't, then the entropy estimate should increase >when the pool is stirred. Sorry, but I disagree with just about everything you wrote in this message. I'm not committing any logical fallacies. I'm not assuming it works because it would be a bug if it didn't; I'm just trying to help you understand the intuition. I have looked at the algorithm used by /dev/{,u}random, and I am satisfied that it is safe to feed in entropy samples from malicious sources, as long as you don't bump up the entropy counter when you do so. Doing so can't do any harm, and cannot reduce the entropy in the pool. However, there is no guarantee that it will increase the entropy. If the adversary knows what bytes you are feeding into the pool, then it doesn't increase the entropy count, and the entropy estimate should not be increased. Therefore: - It is safe to allow non-root users to inject data into the pool by writing to /dev/random, as long as you don't bump up the entropy estimate. Doing so cannot decrease the amount of entropy in the pool. - It is not a good idea to bump up the entropy estimate when non-root users write to /dev/random. If a malicious non-root user writes the first one million digits of pi to /dev/random, then this hasn't increased the uncertainty that this attacker has in the pool, so you shouldn't increase the entropy estimate. - Whether you automatically bump up the entropy estimate when root users write to /dev/random is a design choice where you could reasonably go either way. On the one hand, you might want to ensure that root has to take some explicit action to allege that it is providing a certain degree of entropy, and you might want to insist that root tell /dev/random how much entropy it added (since root knows best where the data came from and how much entropy it is likely to contain). On the other hand, you might want to make it easier for shell scripts to add entropy that will count towards the overall entropy estimate, without requiring them to go through weird contortions to call various ioctl()s. I can see arguments both ways, but the current behavior seems reasonable and defensible. Note that, in any event, the vast majority of applications should be using /dev/urandom (not /dev/random!), so in an ideal world, most of these issues should be pretty much irrelevant to the vast majority of applications. Sadly, in practice many applications wrongly use /dev/random when they really should be using /dev/urandom, either out of ignorance, or because of serious flaws in the /dev/random man page. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Entropy Pool Contents
Phillip Susi wrote: >Why are non root users allowed write access in the first place? Can't >the pollute the entropy pool and thus actually REDUCE the amount of good >entropy? Nope, I don't think so. If they could, that would be a security hole, but /dev/{,u}random was designed to try to make this impossible, assuming the cryptographic algorithms are secure. After all, some of the entropy sources come from untrusted sources and could be manipulated by an external adversary who doesn't have any account on your machine (root or non-root), so the scheme has to be secure against introduction of maliciously chosen samples in any event. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: capabilities patch (v 0.1)
David Madore wrote: >I intend to add a couple of capabilities which are normally available >to all user processes, including capability to exec(), [...] Once you have a mechanism that lets you prevent the untrusted program from exec-ing a setuid/setgid program (such as your bounding set idea), I don't see any added value in preventing the program from calling exec(). "Don't forbid what you can't prevent". The program can always emulate the effect of exec() in userspace (for non-setuid/setgid programs) -- doing so is tedious, but nothing prevents a malicious userspace program from implementing such a thing, I think. This is only a comment on forbidding exec(), not on anything else in your proposal. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: understanding Linux capabilities brokenness
David Madore wrote: >This does not tell me, then, why CAP_SETPCAP was globally disabled by >default, nor why passing of capabilities across execve() was entirely >removed instead of being fixed. I do not know of any good reason. Perhaps the few folks who knew enough to fix it properly didn't feel like bothering; it beats me. Messing with capabilities is scary. As far as I can tell, there never was any coherent "design" to the semantics of POSIX capabilities in Linux. It's had a little bit of a feeling of a muddle of accumulated gunk, so unless you understand it really well, it's hard to know what any changes you make are safe. This may have scared people away from fixing it "the right way". But if you're volunteering to do the analysis and figure out how to fix it, I say, sounds good to me. Then again, I'm an outsider. Perhaps someone more involved in the development and maintanence of capabilities knows something that I don't. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fortuna
Theodore Ts'o wrote: >For one, /dev/urandom and /dev/random don't use the same pool >(anymore). They used to, a long time ago, but certainly as of the >writing of the paper this was no longer true. This invalidates the >entire last paragraph of Section 5.3. Ok, you're right, this is a serious flaw, and one that I overlooked. Thanks for elaborating. (By the way, has anyone contacted to let them know about these two errors? Should I?) I see three remaining criticisms from their Section 5.3: 1) Due to the way the documentation describes /dev/random, many programmers will choose /dev/random by default. This default seems inappropriate and unfortunate. 2) There is a widespread perception that /dev/urandom's security is unproven and /dev/random's is proven. This perception is wrong. On a related topic, it is "not at all clear" that /dev/random provides information-theoretic security. 3) Other designs place less stress on the entropy estimator, and thus are more tolerant to failures of entropy estimation. A failure in the entropy estimator seems more likely than a failure in the cryptographic algorithms. These three criticisms look right to me. Apart from the merits or demerits of Section 5.3, the rest of the paper seemed to have some interesting ideas for how to simplify and possibly improve the /dev/random generator, which might be worth considering at some point. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fortuna
Matt Mackall wrote: >On Sat, Apr 16, 2005 at 01:08:47AM +0000, David Wagner wrote: >> http://eprint.iacr.org/2005/029 > >Unfortunately, this paper's analysis of /dev/random is so shallow that >they don't even know what hash it's using. Almost all of section 5.3 >is wrong (and was when I read it initially). Yes, that is a minor glitch, but I believe all their points remain valid nonetheless. My advice is to apply the appropriate s/MD5/SHA1/g substitution, and re-read the paper to see what you can get out of it. The problem is not that the paper is shallow; it is not. The source of the error is likely that this paper was written by theorists, not implementors. There are important things we can learn from them, and I think it is worth reading their paper carefully to understand what they have to offer. I believe they raise substantial and deep questions in their Section 5.3. I don't see why you say Section 5.3 is all wrong. Can you elaborate? Can you explain one or two of the substantial errors you see? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] procfs privacy: misc. entries
Lorenzo Hernández GarcĂa-Hierro wrote: >El lun, 18-04-2005 a las 15:05 -0400, Dave Jones escribiĂł: >> This is utterly absurd. You can find out anything thats in /proc/cpuinfo >> by calling cpuid instructions yourself. >> Please enlighten me as to what security gains we achieve >> by not allowing users to see this ? > >It's more obscurity than anything else. At least that's what privacy >means usually. Well, that's not what the word "privacy" means to me. It seems to me there are plenty of "privacy" issues that are real and legitimate and have nothing to do with obscurity. I agree with Dave Jones. Security through obscurity makes no sense. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fortuna
Jean-Luc Cooke wrote: >The part which suggests choosing an irreducible poly and a value "a" in the >preprocessing stage ... last I checked the value for a and the poly need to >be secret. How do you generate poly and a, Catch-22? Perhaps I'm missing >something and someone can point it out. I don't think you're missing anything. What you say matches my understanding as well. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fortuna
linux wrote: >Thank you for pointing out the paper; Appendix A is particularly >interesting. And the [BST03] reference looks *really* nice! I haven't >finished it yet, but based on what I've read so far, I'd like to >*strongly* recommnd that any would-be /dev/random hackers read it >carefully. It can be found at >http://www.wisdom.weizmann.ac.il/~tromer/papers/rng.pdf Yeah, [BST03] seems worth reading. It has a reasonable survey of some previous work, and is well-written. However, I'm pretty skeptical about [BST03] as a basis for a real-world randomness generator. It assumes that there are only 2^t possible distributions for the source, and the set of possible distributions has been fixed in advance (before the design of your randomness generator is revealed). Consequently, it fails to defend against adaptive attacks. If the attacker can feed in maliciously chosen inputs (chosen after the attacker learns which randomness extraction algorithm you are using), then the BST03 scheme promises nothing. For instance, if you feed in timings of network packets, then even if you don't count them as providing any entropy, the mere act of feeding them into your randomness generator causes their theorems to be clearly inapplicable (since no matter what value of t you pick, the adversary can arrange to get more than t bits of freedom in the network packets he sends you). So I'm not sure [BST03]'s theorems actually promise what you'd want. On the other hand, if you want to take their constructions as providing some intuition or ideas about how one might build a randomness generator, while realizing that their theorems don't apply and there may be no useful guarantees that can be proven about such an approach, I don't have any objections to that view. By the way, another example of work along these lines is http://theory.lcs.mit.edu/~yevgen/ps/2-ext.ps That paper is more technical and theoretically-oriented, so it might be harder to read and less immediately useful. It makes a strong assumption (that you have two sources that are independent -- i.e., totally uncorrelated), but the construction at the heart of their paper is pretty simple, which might be of interest. >Happily, it *appears* to confirm the value of the LFSR-based input >mixing function. Although the suggested construction in section 4.1 is >different, and I haven't seen if the proof can be extended. Well, I don't know. I don't think I agree with that interpretation. Let me give a little background about 2-universal hashing. There is a basic result about use of 2-universal hash functions, which says that if you choose the seed K truly at random, then you can use h_K(X) to extract uniform random bits from a non-uniform source X. (Indeed, you can even reveal K without harming the randomness of h_K(X).) The proof of this fact is usually known as the Leftover Hashing Lemma. One of the standard constructions of a 2-universal hash function is as a LFSR-like scheme, where the seed K is used to select the feedback polynomial. But notice that it is critical that the feedback polynomial be chosen uniformly at random, in a way that is unpredictable to the attacker, and kept secret until you receive data from the source. What /dev/random does is quite different from the idea of 2-universal hashing developed in the theory literature and recounted in [BST03]. /dev/random fixes a single feedback polynomial in advance, and publishes it for the world to see. The theorems about 2-universal hashing promise nothing about use of a LFSR with a fixed feedback polynomial. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fortuna
linux wrote: >3) Fortuna's design doesn't actually *work*. The authors' analysis > only works in the case that the entropy seeds are independent, but > forgot to state the assumption. Some people reviewing the design > don't notice the omission. Ok, now I understand your objection. Yup, this is a real objection. You are right to ask questions about whether this is a reasonable assumption. I don't know whether /dev/random makes the same assumption. I suspect that its entropy estimator is making a similar assumption (not exactly the same one), but I don't know for sure. I also don't know whether this is a realistic assumption to make about the physical sources we currently feed into /dev/random. That would require some analysis of the physics of those sources, and I don't have the skills it would take to do that kind of analysis. > Again, suppose we have an entropy source that delivers one fresh > random bit each time it is sampled. > > But suppose that rather than delivering a bare bit, it delivers the > running sum of the bits. So adjacent samples are either the same or > differ by +1. This seems to me an extremely plausible example. > > Consider a Fortuna-like thing with two pools. The first pool is seeded > with n, then the second with n+b0, then the first again with n+b0+b1. > n is the arbitrary starting count, while b0 and b1 are independent > random bits. > > Assuming that an attacker can see the first pool, they can find n. > After the second step, their uncertainty about the second pool is 1 > bit, the value of b0. > > But the third step is interesting. The attacker can see the value of > b0+b1. If the sum is 0 or 2, the value of b0 is determined uniquely. > Only in the case that b0+b1 = 1 is there uncertainty. So we have > only *half* a bit of uncertainty (one bit, half of the time) in the > second pool. [..] > I probably just don't have enough mathematical background, but I don't > currently know how to bound this leakage. Actually, this example scenario is not a problem. I'll finish the analysis for you. Suppose that the adversary can observe the entire evolution of the first pool (its initial value, and all updates to it). Assume the adversary knows n. In one round (i.e., a pair of updates), the adversary learns the value of b0 + b1 (and nothing more!). In the next round, the adversary learns b0' + b1' -- and so on. How many bits of uncertainty have been added to the second pool in each round? With probability 1/2, the uncertainty of the second pool remains unchanged. With probability 1/2, the uncertainty increases by exactly 1 bit. This means there are two classes of updates, and both classes are equally likely. Suppose we perform 200 rounds of updates. Then we can expect about 100 of these updates to be of the second class. If the updates were split evently (50/50) between these two classes, the adversary would have 100 bits of uncertainty about the second pool. In general, we expect somewhere near 100 bits of uncertainty -- sometimes a bit more, sometimes a bit less, but the chances that it is a lot less than 100 bits of uncertainty are exponentially small. Therefore, except for an event that occurs with exponentially small probability, the adversary will be left with many bits of uncertainty about the second pool. So this kind of source should not pose a serious problem for Fortuna, or for any two-pool solution. If you want a better example of where the two-pool scheme completely falls apart, consider this: our source picks a random bit, uses this same bit the next two times it is queried, and then picks a new bit. Its sequence of outputs will look like (b0,b0,b1,b1,b2,b2,..,). If we alternate pools, then the first pool sees the sequence b0,b1,b2,.. and the second pool sees exactly the same sequence. Consequently, an adversary who can observe the entire evolution of the first pool can deduce everything there is to know about the second pool. This just illustrates that these multiple-pool solutions make some assumptions about the time-independence of their sources, or at least that the bits going into one pool don't have too much correlation with the bits going into the other pool. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why system call need to copy the date from the userspace before using it
Hacksaw wrote: >What I would expect the kernel to do is this: > >system_call_data_prep (userdata, size){ [...] > for each page from userdata to userdata+size > { > if the page is swapped out, swap it in > if the page is not owned by the user process, return -ENOWAYMAN > otherwise, lock the page > } [...] One challenge that might make this issue a little tricky is that you have to handle double-indirection, where the kernel copies in a buffer that includes a pointer to some other buffer that you then have to copy in. I think this comes up in some of the ioctl() calls. Because only the guts of the ioctl() implementation knows the format of the data structure, only it knows what system_call_data_prep() calls would be needed. So, everywhere that currently does copy_from_user() would have to do system_call_data_prep(). (It wouldn't be sufficient to call system_call_data_prep() once in some standardized way at the start of each system call, and leave it at that.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fortuna
linux wrote: >David Wagner wrote: >>linux wrote: >>> First, a reminder that the design goal of /dev/random proper is >>> information-theoretic security. That is, it should be secure against >>> an attacker with infinite computational power. > >> I am skeptical. >> I have never seen any convincing evidence for this claim, [..] > >I'm not sure which claim you're skeptical of. The claim that it's >a design goal, or the claim that it achieves it? Oops! Gosh, I was unclear, wasn't it? Sorry about that. I meant the latter claim. I certainly agree that information-theoretic security is a stated goal of /dev/random. I'm just not certain that it achieves this goal. (Caveat: I don't think that failing to achieve this goal is problematic.) >Whether the goal is *achieved* is a different issue. random.c tries >pretty hard, but makes some concessions to practicality, relying on >computational security as a backup. (But suggestions as to how to get >closer to the goal are still very much appreciated!) Ok. >In particular, it is theoretically possible for an attacker to exploit >knowledge of the state of the pool and the input mixing transform to >feed in data that permutes the pool state to cluster in SHA1 collisions >(thereby reducing output entropy), or to use the SHA1 feedback to induce >state collisions (therby reducing pool entropy). But that seems to bring >whole new meaning to the word "computationally infeasible", requiring >first preimage solutions over probability distributions. Well, wait a second. You have to make up your mind about whether you are claiming information-theoretic security, or claiming computational security. If the former, then this is absolutely an admissible attack. There is nothing whatsoever wrong with this attack, from an information-theoretic point of view. On the other hand, if we are talking about computational security, then I totally agree that this is a (computationally) infeasible attack. >Also, the entropy estimation may be flawed, and is pretty crude, just >heavily derated for safety. And given recent developments in keyboard >skiffing, and wireless keyboard deployment, I'm starting to think that >the idea (taken from PGP) of using the keyboard and mouse as an entropy >source is one whose time is past. > >Given current processor clock rates and the widespread availability of >high-resolution timers, interrupt synchronization jitter seems like >a much more fruitful source. I think there are many bits of entropy >in the lsbits of the RDTSC time of interrupts, even from the periodic >timer interrupt! Even derating that to 0.1 bit per sample, that's still >a veritable flood of seed material. Makes sense. As for your question about what one could do to achieve information-theoretic security, there is a bunch of theoretical work in the CS theory world on this subject (look up, e.g., "extractors"). Here is my summary about what is possible: 1) If you don't know anything about your source, and you don't start with any entropy, then information-theoretically secure randomness extraction is impossible -- at least in principle. You pick any deterministic algorithm for randomness extraction, and I will show you a source for which that algorithm fails. 2) If you start with a short seed of uniformly distributed perfect randomness, and you have a lower bound on the amount of entropy provided by your source, then you can extract random bits in a way that is provably information-theoretically secure. Note that you don't have to know anything about the distribution of the source, other than that its (min-)entropy is not too small. The simplest construction uses a 2-universal hash function keyed by the seed (its security is established by the Leftover Hashing Lemma), but there are other constructions, including a class of schemes known as "extractors". This approach does require a short seed of perfect true randomness for every chunk of output you want to generate, though. 3) If you make certain assumptions about the source, you can extract entropy in a way that is provably information-theoretically secure, without needing the short seed. However, the assumptions required are typically fairly strong: e.g., that your source is completely memoryless; that you have multiple sources that are totally independent (i.e., uncorrelated in any way); or that your source has a certain structure (e.g., k of the n bits are uniformly random and independent, and the other n-k bits are fixed in advance). People are actively working to push the boundaries in this category. I'm not sure whether any of the above will be practically relevant. They may be too theoretical for real-world use. But if you're interested, I could try to give you more information about any
Re: Fortuna
linux wrote: >/dev/urandom depends on the strength of the crypto primitives. >/dev/random does not. All it needs is a good uniform hash. That's not at all clear. I'll go farther: I think it is unlikely to be true. If you want to think about cryptographic primitives being arbitrarily broken, I think there will be scenarios where /dev/random is insecure. As for what you mean by "good uniform hash", I think you'll need to be a bit more precise. >Do a bit of reading on the subject of "unicity distance". Yes, I've read Shannon's original paper on the subject, as well as many other treatments. I stand by my comments above. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fortuna
Theodore Ts'o wrote: >With a properly set up set of init scripts, /dev/random is initialized >with seed material for all but the initial boot [...] I'm not so sure. Someone posted on this mailing list several months ago examples of code in the kernel that looks like it could run before those init scripts are run, and that looks like it might well be using /dev/*random before it has been seeded. I never saw any response. >It fundamentally assumes that crypto >primitives are secure (when the recent break of MD4, MD5, and now SHA1 >should have been a warning that this is a Bad Idea (tm)), It looks to me like the recent attacks on MD4, MD5, and SHA1 do not endanger /dev/random. Those attacks affect collision-resistance, but it looks to me like the security of /dev/random relies on other properties of the hash function (e.g., pseudorandomness, onewayness) which do not seem to be threatened by these attacks. But of course this is a complicated business, and maybe I overlooked something about the way /dev/random uses those hash functions. Did I miss something? As for which threat models are realistic, I consider it more likely that my box will be hacked in a way that affects /dev/random than that SHA1 will be broken in a way that affects /dev/random. >In addition, Fortuna is profligate with entropy, [...] Yup. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fortuna
Jean-Luc Cooke wrote: >Info-theoretic randomness is a strong desire of some/many users, [..] I don't know. Most of the time that I've seen users say they want information-theoretic randomness, I've gotten the impression that those users didn't really understand what information-theoretic randomness means, and their applications usually didn't need information-theoretic randomness in the first place. As for those who reject computational security because of its unproven nature, they should perhaps be warned that any conjectured information-theoretic security of /dev/random is also unproven. Personally, I feel the issue of information-theoretic security is a distraction. Given the widespread confusion about what information-theoretic security means, I certainly sympathize with why Jean-Luc Cooke left in the existing entropy estimation technique as a way of side-stepping the whole argument. Anyway, the bottom line is I don't consider "information-theoretic arguments" as a very convincing reason to reject Cooke's proposal. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fortuna
>First, a reminder that the design goal of /dev/random proper is >information-theoretic security. That is, it should be secure against >an attacker with infinite computational power. I am skeptical. I have never seen any convincing evidence for this claim, and I suspect that there are cases in which /dev/random fails to achieve this standard. And it seems I am not the only one. See, e.g., Section 5.3 of: http://eprint.iacr.org/2005/029 Fortunately, it doesn't matter whether /dev/random provides information-theoretic security. I have reasonable confidence that it provides computational security, and that is all that applications need. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fortuna
Matt Mackall wrote: >While it may have some good properties, it lacks >some that random.c has, particularly robustness in the face of failure >of crypto primitives. It's probably not a big deal, because I'm not worried about the failure of standard crypto primitives, but-- Do you know of any analysis to back up the claim that /dev/random will be robust in the failure of crypto primitives? I have never seen anyone try to do such an analysis, but maybe you know of something that I don't. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: seccomp for 2.6.11-rc1-bk8
Andrea Arcangeli wrote: >On Sun, Jan 23, 2005 at 07:34:24AM +0000, David Wagner wrote: >> [...Ostia...] The jailed process inherit an open file >> descriptor to its jailor, and is only allowed to call read(), write(), >> sendmsg(), and recvmsg(). [...] > >Why to call sendmsg/recvmsg when you can call read/write anyway? Because sendmsg() and recvmsg() allow passing of file descriptors, and read() and write() do not. For some uses of this kind of jail, the ability to pass file descriptors to/from your master is a big deal. It enables significant new uses of seccomp. Right now, the only way a master can get a fd to the jail is to inherit that fd across fork(), but this isn't as flexible and it restricts the ability to pass fds interactively. Andrea, I understand that you don't have any use for sendmsg()/recvmsg() in your Cpushare application. I'm thinking about this from the point of view of other potential users of seccomp. I believe there are several other applications which might benefit from seccomp, if only it were to allow fd-passing. If we're going to deploy this in the mainstream kernel, maybe it makes sense to enable other uses as well. And that's why I suggested allowing sendmsg() and recvmsg(). It might be worth considering. [Sorry for the very late reply; I've been occupied with other things since your last reply.] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] BSD Secure Levels: claim block dev in file struct rather than inode struct, 2.6.11-rc2-mm1 (3/8)
>The attack is to hardlink some tempfile name to some file you want >over-written. This usually involves just a little bit of work, such as >recognizing that a given root cronjob uses an unsafe predictable filename >in /tmp (look at the Bugtraq or Full-Disclosure archives, there's plenty). >Then you set a little program that sleep()s till a few seconds before >the cronjob runs, does a getpid(), and then sprays hardlinks into the >next 15 or 20 things that mktemp() will generate... Got it. Very good -- now I see. Thanks for the explanation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] BSD Secure Levels: claim block dev in file struct rather than inode struct, 2.6.11-rc2-mm1 (3/8)
>For those systems that have everything on one big partition, you can often >do stuff like: > >ln /etc/passwd /tmp/ > >and wait for /etc/passwd to get clobbered by a cron job run by root... How would /etc/passwd get clobbered? Are you thinking that a tmp cleaner run by cron might delete /tmp/whatever (i.e., delete the hardlink you created above)? But deleting /tmp/whatever is safe; it doesn't affect /etc/passwd. I'm guessing I'm probably missing something. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: seccomp for 2.6.11-rc1-bk8
Chris Wright wrote: >* David Wagner ([EMAIL PROTECTED]) wrote: >> There is a simple tweak to ptrace which fixes that: one could add an >> API to specify a set of syscalls that ptrace should not trap on. To get >> seccomp-like semantics, the user program could specify {read,write}, but >> if the user program ever wants to change its policy, it could change that >> set. Solaris /proc (which is what is used for tracing) has this feature. >> I coded up such an extension to ptrace semantics a long time ago, and >> it seemed to work fine for me, though of course I am not a ptrace expert. > >Hmm, yeah, that'd be nice. That only leaves the issue of tracer dying >(say from that crazy oom killer ;-). Yes, I also implemented was a ptrace option which causes the child to be slaughtered if the parent dies for any reason. I could dig up the code, but I don't recall it being very hard. This was ages ago (a 2.0.x kernel) and I have no idea what might have changed. Also, am definitely not a guru on kernel internals, so it is always possible I missed something. But, at least on the surface this doesn't seem hard to implement. A third thing I implemented was a option which would cause ptrace() to be inherited across forks. The way that strace does this (last I looked) is an unreliable abomination: when it sees a request to call fork(), it sets a breakpoint at the next instruction after the fork() by re-writing the code of the parent, then when that breakpoint triggers it attaches to the child, restores the parent's code, and lets them continue executing. This is icky, and I have little confidence in its security to prevent children from escaping a ptrace() jail, so I added a feature to ptrace() that remedies the situation. Anyway, back to the main topic: ptrace() vs seccomp. I think one plausible reason to prefer some mechanism that allows user level to specify the allowed syscall set is that it might provide more flexibility. What if 6 months from now we discover that we really should have enabled one more syscall in seccomp to accomodate other applications? At the same time, I truly empathize Andrea's position that something like seccomp ought to be a lot easier to verify correct than ptrace(). I think several people here are underestimating the importance of clean design. ptrace() is, frankly, a godawful mess, and I don't know about this thinking that you can take a godawful mess and then audit it carefully and call it secure -- well, that seems unlikely to ever lead to the same level of assurance that you can get with a much cleaner design. (This business of overloading as a means of sending ptrace events to user level was in retrospect probably a bad design decision, for instance. See, e.g., Section 12 of my MS thesis for more. http://www.cs.berkeley.edu/~daw/papers/janus-masters.ps) Given this, I can see real value in seccomp. Perhaps there is a compromise position. What if one started from seccomp, but then extended it so the set of allowed syscalls can be specified by user level? This would push policy to user level, while retaining the attractive simplicity and ease-of-audit properties of the seccomp design. Does something like this make sense? Let me give you some idea of new applications that might be enabled by this kind of functionality. One cool idea is a 'delegating architecture' for jails. The jailed process inherit an open file descriptor to its jailor, and is only allowed to call read(), write(), sendmsg(), and recvmsg(). If the jailed process wants to interact with the outside world, it can send a request to its jailor to this effect. For instance, suppose the jailed process wants to create a file called "/tmp/whatever", so it sends this request to the jailor. The jailor can decide whether it wants this to be allowed. If it is to be allowed, the jailor can create this file and transfer a file descriptor to the jailed process using sendmsg(). Note that this mechanism allows the jailor to completely virtualize the system call interface; for instance, the jailor could transparently instead create "/tmp/jail17/whatever" and return a fd to it to the jailed process, without the jailed process being any the wiser. (For more on this, see http://www.stanford.edu/~talg/papers/NDSS04/abstract.html and http://www.cs.jhu.edu/~seaborn/plash/plash.html) So this is one example of an application that is enabled by adding recvmsg() to the set of allowed syscalls. When it comes to the broader question of seccomp vs ptrace(), I don't know what strategy makes most sense for the Linux kernel, but I hope these ideas help give you some idea of what might be possible and how these mechanisms could be used. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: seccomp for 2.6.11-rc1-bk8
Chris Wright wrote: >Only difference is in number of context switches, and number of running >processes (and perhaps ease of determining policy for which syscalls >are allowed). Although it's not really seccomp, it's just restricted >syscalls... There is a simple tweak to ptrace which fixes that: one could add an API to specify a set of syscalls that ptrace should not trap on. To get seccomp-like semantics, the user program could specify {read,write}, but if the user program ever wants to change its policy, it could change that set. Solaris /proc (which is what is used for tracing) has this feature. I coded up such an extension to ptrace semantics a long time ago, and it seemed to work fine for me, though of course I am not a ptrace expert. I don't know whether ptrace + this tweak is a better idea than seccomp. It is just another option out there that achieves similar functionality. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] more SAK stuff
>More interestingly, it changes the operation of SAK in two ways: >(a) It does less, namely will not kill processes with uid 0. I think this is bad for security. (I assume you meant euid 0, not ruid 0. Using the real uid for access control decisions is a very odd thing to do.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] User chroot
Jesse Pollard wrote: >2. Any penetration is limited to what the user can access. Sure, but in practice, this is not a limit at all. Once a malicious party gains access to any account on your system (root or non-root), you might as well give up, on all but the most painstakingly careful configurations. That's why chroot is potentially valuable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] User chroot
Mohammad A. Haque wrote: >Why do this in the kernel when it's available in userspace? Because the userspace implementations aren't equivalent. In particular, it is not so easy for them to enforce the following restriction: (*) If a non-root user requested the chroot, then setuid/setgid bits won't have any effect under the new root. The proposed kernel patch respects (*), but I'm not aware of any user-level application that ensures (*) is followed. (Also, there is the small matter that the user-level implementations are only usable by root, or are setuid root. The latter is only a minor difference, though, IMHO.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] User chroot
It is not rocket science to populate a chroot environment with enough files to make many interesting applications work. Don't expect a general solution---chroot is not a silver bullet---but it is useful. (Note also that whether you can populate a chroot environment sufficiently is roughly independent of whether you called chroot(2) with root privileges or not.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] User chroot
Paul Menage wrote: >It could potentially be useful for a network daemon (e.g. a simplified >anonymous FTP server) that wanted to be absolutely sure that neither it >nor any of its libraries were being tricked into following a bogus >symlink, or a "/../" in a passed filename. After initialisation, the >daemon could chroot() into its data directory, and safely only serve >the set of files within that directory hierarchy. > >This could be regarded as the wrong way to solve such a problem, but >this kind of bug seems to be occurring often enough on BugTraq that it >might be useful if you don't have the resources to do a full security >audit on your program (or if the source to some of your libraries >isn't available). Or even where you have done a full security audit on your program, it is often still useful to have backup protection. Belt and suspenders[*], and all that. [*] For those who are not familiar with the reference: If you really, really want to avoid getting caught with your pants down, you might wear both a belt and a pair of suspenders. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] User chroot
H. Peter Anvin wrote: >By author:Jorgen Cederlof <[EMAIL PROTECTED]> >> If we only allow user chroots for processes that have never been >> chrooted before, and if the suid/sgid bits won't have any effect under >> the new root, it should be perfectly safe to allow any user to chroot. > >Safe, perhaps, but also completely useless: there is no way the user >can set up a functional environment inside the chroot. Why is it useless? It sounds useful to me, on first glance. If I want to run a user-level network daemon I don't trust (for instance, fingerd), isolating it in a chroot area sounds pretty nice: If there is a buffer overrun in the daemon, you can get some protection [*] against the rest of your system being trashed. Am I missing something obvious? [*] Yes, I know chroot is not sufficient on its own to completely protect against this, but it is a useful part of the puzzle, and there are other things we can do to deal with the remaining holes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: "Kernel Insider" (security optimization)
>Its a linux kernel modification, that allows to decide wich uid, pid or >file can open a tcp socket in listening state. - Putting access control on listen() [rather than socket()/bind()] seems like a really bad idea. In particular, in some cases one can bind to a port and receive messages on it without ever calling listen(), if I am not mistaken. - The use of sock_i_uid(sock) seems poorly chosen; if sock->socket==NULL, then your module will mistakenly think that the action was requested by uid 0. In general, the return value from sock_i_uid() cannot be trusted for permission checks for several reasons. Why don't you simply use current->euid for your permission checks? - Checking pid's doesn't seem like a good idea. If a process listed in allowed_pids dies, then some other malicious process can wrap the pid space and take over that trusted pid, thereby subverting your access control policy. - Are you aware of previous work on this subject? In particular, you might enjoy checking out the Janus project, which is a much more general implementation of this idea: http://www.cs.berkeley.edu/~daw/janus/ - You should really join the mailing list hosted by Crispin Cowan working to develop kernel hooks for this sort of kernel security modification. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question: permission checking for network filesystem
Mikulas Patocka wrote: >If you are checking permissions on server, read/execute have no security >meaning. This seems a bit too strong. If I try to exec a file that has read permission enabled but not execute permission, I'd like this to fail. You can just imagine sysadmins who turn off exec bits on old buggy apps to prevent users from executing them, who could get bit in the butt by the sort of unexpected behavior that would result from ignoring execute permission bits. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: light weight user level semaphores
Linus Torvalds wrote: >Ehh.. I will bet you $10 USD that if libc allocates the next file >descriptor on the first "malloc()" in user space (in order to use the >semaphores for mm protection), programs _will_ break. > >You want to take the bet? Good point. Speaking of which: ioctl(fd, UIOCATTACHSEMA, ...); seems to act like dup(fd) if fd was opened on "/dev/usemaclone" (see drivers/sgi/char/usema.c). According to usema(7), this is intended to help libraries implement semaphores. Is this a bad coding? Should the kernel really support an ioctl() that can silently allocate the next file descriptor? This seems like asking for trouble. Or, maybe I just misunderstood something. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sources of entropy - /dev/random problem for network servers
Alex Bligh - linux-kernel wrote: >In debugging why my (unloaded) IMAP server takes many seconds >to open folders, I discovered what looks like a problem >in 2.4's feeding of entropy into /dev/random. When there >is insufficient entropy in the random number generator, >reading from /dev/random blocks for several seconds. /dev/random >is used (correctly) for crytographic key verification. Use /dev/urandom, or buy a hardware RNG. >However, only 3 drivers in drivers/net actually set >SA_SAMPLE_RANDOM when calling request_irq(). I believe >all of them should. And indeed this fixed the problem for >me using an eepro100(). This is unsafe. The time that packets arrive is not secret: anyone who can run a sniffer on your network can potentially recover this information. Thus, such timings are unsuitable for introduction into the entropy pool. (More precisely, there's no harm in adding them to the entropy pool if they are added in a way so that the /dev/random pool doesn't increment its estimate of how much entropy it has collected. The real harm comes when you bump up the randomness counter based on them, and if I understand your proposed change, this is what it's doing.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hotmail not dealing with ECN
Helge Hafting wrote: >So, no reason for a firewall author to check these bits. You don't think like a firewall designer! :-) Practice being really, really paranoid. Think: You're designing a firewall; you've got some reserved bits, currently unused; any future code that uses them could behave in completely arbitrary and insecure ways, for all you know. Now recall that anything not known to be safe should be denied (in a good firewall) -- see Cheswick and Bellovin for why. When you take this point of view, it is completely understandable why firewalls designed before ECN was introduced might block it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Pthreads, linux, gdb, oh my! (and ptrace must die!)
Mike Coleman wrote: >My limited mental abilities notwithstanding, I think this is one more reason >to ditch ptrace for a better method of process tracing/control. It's served >up to this point, but ptrace has a fundamental flaw, which is that it tries to >do a lot of interprocess signalling and interlocking in an in-band way, doing >process reparenting to try to take advantage of existing code. In the end >this seems to be resulting in an inscrutable, flaky mess. Yes! Overloading signals and the process parent tree is a kludgy hack with many unanticipated, painful effects (like this bug mentioned here, or the way ptrace breaks the semantics of wait(), etc.). >What would a better process tracing facility be like? Like the Solaris /proc tracing facility. Take a look at it -- I think it would make an excellent starting point. It is truly well done, at least in every way that has ever affected my use of tracing (my experience is in the area of sandboxing for security). /proc is transparent. It doesn't overload some existing mechanism, so it doesn't have all the pain of changing the semantics of various corner cases. /proc uses fd's as the mechanism for communicating events from the kernel to user-land, which gives a cleaner architecture. /proc allows to trap on both syscalls and syscall-exits, and to specify which events the user-land process is interested in (greatly lowers the cost of tracing, if you only care about some subset of the events). ptrace() doesn't let you specify (more than one bit of) per-process tracing state, which makes this very difficult to do. /proc is extensible: whenever it allows one tracer, it allows many tracers. /proc allows any-to-any tracing. ptrace() only allows a traced app to have at most one tracer at any time. This limitation of ptrace() makes it hard to securely (atomically) hand off tracing of an app from one tracer to another. /proc fixes this. /proc handles fork() more cleanly. In /proc, the tracer receives a tracing event when the fork returns in the newly created child process, as well as when it returns in the parent; in ptrace(), you only see an event when the fork() returns in the parent, which makes it harder to follow the process tree while tracing apps that call fork(). Go read strace code to see how it works around this problem, and you'll see what a disgusting hack strace is forced to use (blech!). Much of the ptrace() code in the kernel isn't architecture-independent. I find this amazing. IMHO, it would be much cleaner to have all syscalls immediately call some arch-independent function with the appropriate arguments, and interpose on the set of arch-independent functions. I'm not saying you should duplicate the Solaris /proc facility, but it would be very useful to learn from what Solaris got right and ptrace() got wrong. An even better process tracing facility might allow interposition on other interfaces in the kernel: Rather than just receiving events on syscalls and signals, how about on the VFS filesystem interface or the network layer interface? Just a thought. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: use of add_interrupt_randomness in drivers missing in many drivers
Horst von Brand wrote: >Adding stuff that adds no entropy (or at least doesn't add to the estimated >entropy pool) is just a waste of effort, AFAIKS. Adding stuff that has no entropy is a waste of effort. Adding stuff that probably has entropy, but where you don't bump the entropy counter, *does* add value. The entropy counter is a conservative estimate of how much entropy you can safely rely on being present. It's still useful to add more entropy to the pool -- even if it's not reflected in the counter -- because it reduces the chances of a catastrophic randomness failure. (What if you over-estimated, or if one of your sources failed and became predictable, e.g., because the attacker started jamming your GPS from a van parked outside your building?) It pays to be (prudently) paranoid, in this business. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: use of add_interrupt_randomness in drivers missing in many drivers
Jeff Garzik wrote: >Then you make your local random pool vulnerable to external >manipulation, to a certain extent... Adding more bits to the pool should never hurt; the cryptographic mixing ensures this. What _can_ hurt is adding predictable bits but (erroneously) bumping up the entropy counter. So, if you're not sure whether those bits are unpredictable and random or not, the right thing to do is to mix 'em into the pool, but don't bump the entropy counter. The greater your diversity of sources, the less likely it is that you encounter a catastrophic randomness failure. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Marc Mutz wrote: >David Wagner wrote: >> (However, it does get one >> thing wrong: it claims that it's ok to use a serial number for your >> IV. This is not correct, and I can give a reference for this latter, >> subtler point, if you like.) >> >Yes, please. One reference is http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt as other people mentioned. >The IV would not contain any key material. If you have a cipher with a >128 bit key and you need 64 bits of IV, you simply request 192 bits of >"key", use the lower third for the IV and the upper third as the key. Ahh, yes, this does sound ok. Sorry: I misunderstood your proposal. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Ingo Rohloff wrote: >-snip--- > As an example, it is not true that CBC encryption > can use an arbitrary nonce initialization vector: it is essential > that the IV be unpredictable by the adversary. (To see this, suppose > the IV is a sequence number: 0, 1, 2, ... . Then a (first) encryp- > tion of 0x followed by an encryption of > 0x0001 is recognizably distinct from a (first) encryption > of 0x followed by an encryption of > 0x. Clearly this violates violates the notion of a > secure encryption sketched in Section 2.) >-snip--- > >So I think what is written in "Applied Cryptography" (by Bruce Schneier) >is correct. A sequence is ok, as long as you can't predict the start >of the sequence. No, a sequence is not ok, even if the beginning is unpredictable. Why? The encryption of 0 with IV v followed by encryption of 1 with IV v+1 is distinguishable from the reverse. (Because, with high probability, v and v+1 differ only in their low bit.) The problem is that the patterns in the IV sequence can interact with patterns in the plaintext. And, if the plaintext is patterned (e.g., ASCII-encoded English), there is a reasonable chance that you can get two plaintexts which start with blocks that differ only in their low bit; and this is the case that leads to the bad interaction, when you use a counter as your IV sequence. Using SHA1(sector #) should be ok, as long as you don't expect your plaintexts to have similar patterns. (If you do think your plaintexts might begin with the SHA1-hashes of sector numbers, you could use a "keyed hash", or more precisely, a pseudorandom function. For instance, you could encrypt the sector number using a secret IV-generation key.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Ingo Rohloff wrote: >> There is a paper about why it is a bad idea to use >> sequence numbers for CBC IV's. I just have to find the reference to it. > >Does this mean sequence as in 0,1,2,3,4 ... or does this mean >any pre-calculate-able sequence ? In the former case we might just use >a simple one way hash-function over the requested sector number. It just means that 0,1,2,3,... is bad. Using SHA1(sector #) should be ok. But do think carefully about what happens when you modify a sector!! In particular, will you be re-using the old IV when you write the new data? That could be problematic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Marc Mutz wrote: >> There are some who believe that "not unique" IVs (across multiple >> filesystems) facilitates some methods of cryptanalysis. > >Do you have a paper reference? There's no paper, because it's too trivial to appear in a paper. But you can find this weakness described in any good crypto textbook. See, e.g., Bruce Schneier's _Applied Cryptography_; the section on CBC mode says that IV's must not repeat. (However, it does get one thing wrong: it claims that it's ok to use a serial number for your IV. This is not correct, and I can give a reference for this latter, subtler point, if you like.) >As CTR mode _requires_ unique IVs (CBC does not), Sorry, that turns out not to be the case. Both CBC and CTR mode require unique IV's (for security). >the upper half of the >IV could be initialized from the key It's a bad idea to include key material in your IV. (Kerberos did it, and there were some attacks as a result.) I recommend against it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
kernel wrote: >There are some who believe that "not unique" IVs (across multiple >filesystems) facilitates some methods of cryptanalysis. It's a not a matter of "belief"; it's a matter of fact. The weakness is that the first block of ciphertext depends only on the IV and the first block of plaintext. Thus, if the IV is the same for two sectors, then you can tell from the two ciphertexts whether the two plaintexts start with the same 8-byte (or 16-byte) prefix. Since what we're encrypting is often patterned, and thus repeats in the beginning of the plaintext may be semi-common, this is not so good. The right thing is to use non-repeating, unpredictable IV's. One way to do this is to use E_k(sector number) as your IV, as I mentioned earlier; or, if you want relocatibility, you could use E_k(sector number + seed). Ask on sci.crypt if you need more specific advice. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
IV's should never be repeated (per key). If you are using CBC mode, they should not be just a counter, either (for different reasons). A simple implementation technique is simply to use the encryption of a block number / sector number / counter as your IV. This ensures that IV's don't repeat and that they all look cryptographically random. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ack number in a connection-refused RST
David S. Miller wrote: > From: [EMAIL PROTECTED] (David Wagner) > > How could it be for another connection, if it has source and > destination port numbers? > >Consider previously existing connections with the same src/dst/ports >and the effects of massive packet reordering and other transmission >delays. Good point. Ok, I see your point. I stand corrected. Thanks for catching that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ack number in a connection-refused RST
Andi Kleen wrote: >On Fri, Oct 06, 2000 at 09:06:31PM +0000, David Wagner wrote: >> David S. Miller wrote: >> >Linux should not honor the incorrect sequence number. If the sequence >> >number is incorrect, the RST could legitimately be for another >> >connection. >> >> How could it be for another connection, if it has source and destination >> port numbers? > >You're missing dynamic IPs, NAT and reboot of hosts. Ok, but with dynamic IP, NAT, and reboots, you can also get incorrect results with today's implementation, if you see a RST with the correct sequence number (not the off-by-one incorrect one). It's just a probabilistic argument that this is unlikely to happen in practice -- namely, it only happens with probability 1/2^32 (you hope). There's no fundamental reason why you couldn't accept off-by-one sequence numbers as well, if it was deemed important for interoperability; the probability would just increase to 1/2^31, which is still small (albeit not as small as 1/2^32). Right? Or am I still missing something? I'm not a TCP expert. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ack number in a connection-refused RST
David S. Miller wrote: >Linux should not honor the incorrect sequence number. If the sequence >number is incorrect, the RST could legitimately be for another >connection. How could it be for another connection, if it has source and destination port numbers? I thought the sequence number was there to prevent denial of service attacks, i.e., to prevent unauthorized third parties from tearing down established TCP connections; since third parties will not know (or be able to guess) the current 32-bit sequence number, they will be unable to forge a valid RST packet. Of course, this argument is still valid even if you accept off-by-one errors in the sequence number; the attacker still has to guess from a 31-bit space, which is slightly smaller than the original 32-bit space but still likely large enough for security. What am I missing? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: execve replacement.
Abel Muñoz Alcaraz wrote: > I have replaced the execve() kernel [syscall] > with my own implementation but it doesn't work well. In Linux, hooking into sys_call_table[] is a pretty painful way to interpose on system calls. Unfortunately, there's no other way to do it (in Linux) that I know of... Your problem at the moment is that sys_execve() is implemented with an ugly hack. Usual C call-by-value semantics would give you a private copy of the struct argument. However, sys_execve() is declared with the "asmlinkage" keyword, so in this case you get passed a struct _which is aliased to the argument the caller passed_, and the implementation of sys_execve() relies on this fact. This optimization makes it really painful to wrap sys_execve() in the natural way. The solution is to cut-and-paste code ... but don't expect it to be architecture-independent (argh!). I think the sigreturn() and rt_sigsuspend() system calls have similar issues. Probably the next few things you'll run into are: - If you want to install a hook (a function) that gets called when a process dies, it's very difficult. - If you want to keep extra per-process state reliably, it's difficult. - If you want to examine system call arguments, it's difficult. - If you want to interpose on sys_socketcall(), you may have to cut-and-paste code from the implementation of sys_socketcall(). Oh, how I wish Linux provided a cleaner, architecture-independent interface for system call interposition... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/