Re: A question about Knark and modules
At 10:34 Uhr +0200 19.6.2001, Ethan Benson wrote: On Tue, Jun 19, 2001 at 10:09:51AM +0200, Christian Jaeger wrote: > But if the passwd command doesn't itself have the rights to access > /etc/shadow but only the root login shell has (which only runs if > called through sshd), then the cracker would have to know your root > passwd before being able to change it. passwd not being able to update /etc/shadow would be a very bad thing since users would be unable to change thier own passwords. users need to be encouraged to change thier passwords, not discouraged. OK, didn't think about normal users. But then I would suggest writing a passwd wrapper (or modified passwd command) having access rights to the files but requiring root users (better even *any* user) to be logged in via sshd (or console or other trust path). i don't think you can really modify passwd to be that granular about ssh vs other methods of access. What I'm thinking of is using the ppid of the current process to track it back (like pstree) until sshd (maybe requiring sshd being only three levels back (sshd-->rootshellwrapper-->shell-->passwd)) and from there until init (to make sure sshd was called by init). I'm not that used to C and linux system programming, so I don't know whether you can reliably detect the file (path or inode/filesystem) a process was started from. How do you do that under linux, only by reading /proc? Since 'ps' seems to do that it seems to be the usual way (hm, /proc isn't that old I think so there had to be another (better?) way before?). I'm relying on root not being able to modify the pid/ppid and the path/inode/filesystem info of a running process (without patching the kernel, which would be made impossible by lids by denying module loading and /dev/mem access). I'll try to write such passwd and shell wrappers if I get enough time the next few days. (As I said I'm not that experienced and so would need your help auditing the result if I get that far.) Instead of only trusting init-->sshd you could also accept the path init-->/bin/login (for logins at the console). Or even /bin/login or /bin/su if *not* called from init, under the assumption they don't have bugs. In principle you could choose which of the binaries doing pam authentification you want to trust, and then trust each child process from these (of course you have to check first that they only start child processes if authentification has succeeded). Maybe modifying insmod to (have the module loading capability but) only accept lids-protected module files would solve the original issue of this thread. im still not convinced you could prevent root from sshing to himself. (I don't understand what you mean.) Christian.
Re: A question about Knark and modules
At 10:34 Uhr +0200 19.6.2001, Ethan Benson wrote: >On Tue, Jun 19, 2001 at 10:09:51AM +0200, Christian Jaeger wrote: > > But if the passwd command doesn't itself have the rights to access > > /etc/shadow but only the root login shell has (which only runs if > > called through sshd), then the cracker would have to know your root > > passwd before being able to change it. > >passwd not being able to update /etc/shadow would be a very bad thing >since users would be unable to change thier own passwords. users need >to be encouraged to change thier passwords, not discouraged. OK, didn't think about normal users. But then I would suggest writing a passwd wrapper (or modified passwd command) having access rights to the files but requiring root users (better even *any* user) to be logged in via sshd (or console or other trust path). >i don't think you can really modify passwd to be that granular about >ssh vs other methods of access. What I'm thinking of is using the ppid of the current process to track it back (like pstree) until sshd (maybe requiring sshd being only three levels back (sshd-->rootshellwrapper-->shell-->passwd)) and from there until init (to make sure sshd was called by init). I'm not that used to C and linux system programming, so I don't know whether you can reliably detect the file (path or inode/filesystem) a process was started from. How do you do that under linux, only by reading /proc? Since 'ps' seems to do that it seems to be the usual way (hm, /proc isn't that old I think so there had to be another (better?) way before?). I'm relying on root not being able to modify the pid/ppid and the path/inode/filesystem info of a running process (without patching the kernel, which would be made impossible by lids by denying module loading and /dev/mem access). I'll try to write such passwd and shell wrappers if I get enough time the next few days. (As I said I'm not that experienced and so would need your help auditing the result if I get that far.) Instead of only trusting init-->sshd you could also accept the path init-->/bin/login (for logins at the console). Or even /bin/login or /bin/su if *not* called from init, under the assumption they don't have bugs. In principle you could choose which of the binaries doing pam authentification you want to trust, and then trust each child process from these (of course you have to check first that they only start child processes if authentification has succeeded). Maybe modifying insmod to (have the module loading capability but) only accept lids-protected module files would solve the original issue of this thread. >im still not convinced you could prevent root from sshing to himself. (I don't understand what you mean.) Christian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Tue, Jun 19, 2001 at 12:28:46AM -0800, Ethan Benson wrote: > On Tue, Jun 19, 2001 at 12:17:07PM +0800, Ben Harvey wrote: > > > cracker==root sysadmin==root+LIDS_password > > if someone can sniff me typing in my lids password (encrypted in the kernel) > > then I am stuffed. > > they can always read the password hash out of the kernel and run a > brute force attack on it too. More likely is that they might read the plain text password from a buffer somewhere, or capture it while you type it. If they can make arbitrary changes to the running kernel code, you lose. (That's another reason why the module signing + user-space memory access stuff would be good.) Of course, unless the password is very long and strong, the brute for attack will be much cheaper than breaking MD5 usually is. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Re: A question about Knark and modules
On Tue, Jun 19, 2001 at 12:28:46AM -0800, Ethan Benson wrote: > On Tue, Jun 19, 2001 at 12:17:07PM +0800, Ben Harvey wrote: > > > cracker==root sysadmin==root+LIDS_password > > if someone can sniff me typing in my lids password (encrypted in the kernel) > > then I am stuffed. > > they can always read the password hash out of the kernel and run a > brute force attack on it too. More likely is that they might read the plain text password from a buffer somewhere, or capture it while you type it. If they can make arbitrary changes to the running kernel code, you lose. (That's another reason why the module signing + user-space memory access stuff would be good.) Of course, unless the password is very long and strong, the brute for attack will be much cheaper than breaking MD5 usually is. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Wed, Jun 20, 2001 at 12:02:47AM -0600, Hubert Chan wrote: > be SUID, you're safer without it being SUID). Is there any (sane) way > of making it so that programs such as passwd, chsh, etc. don't need to > be SUID? Not really. Not if you want to ensure that any of the data they can alter passes sanity checks despite a malicious user, which is a case you certainly have to allow for. Putting the password into a file that the user owns also allows a careless user to make it world-readable (or even writeable, eh?). Nope. SUID programs are a security risk because they offer interesting power to those who can subvert them, but they are also the way Unix systems extend restricted access to protected resources to non-root users. Rather than trying to eliminate them, which is almost certainly impossible without adding something comparable to ACLs and a raft of systemic changes (to segregate what are now fields in one record to be in separate, hence separately access-controlled files, for example), we might want to consider whether they could instead be implemented in a way that made them much less likely to be exploitable. The C language is a wonderful thing, but it offers many subtle ways to err. -- Truth in advertising is like leaven, which a woman hid in three measures of meal. It provides a suitable quantity of gas, with which to blow out a mass of crude misrepresentations into a form that the public can swallow. - Dorothy Sayers, _Murder Must Advertise_
Re: A question about Knark and modules
On Wed, Jun 20, 2001 at 12:02:47AM -0600, Hubert Chan wrote: > be SUID, you're safer without it being SUID). Is there any (sane) way > of making it so that programs such as passwd, chsh, etc. don't need to > be SUID? Not really. Not if you want to ensure that any of the data they can alter passes sanity checks despite a malicious user, which is a case you certainly have to allow for. Putting the password into a file that the user owns also allows a careless user to make it world-readable (or even writeable, eh?). Nope. SUID programs are a security risk because they offer interesting power to those who can subvert them, but they are also the way Unix systems extend restricted access to protected resources to non-root users. Rather than trying to eliminate them, which is almost certainly impossible without adding something comparable to ACLs and a raft of systemic changes (to segregate what are now fields in one record to be in separate, hence separately access-controlled files, for example), we might want to consider whether they could instead be implemented in a way that made them much less likely to be exploitable. The C language is a wonderful thing, but it offers many subtle ways to err. -- Truth in advertising is like leaven, which a woman hid in three measures of meal. It provides a suitable quantity of gas, with which to blow out a mass of crude misrepresentations into a form that the public can swallow. - Dorothy Sayers, _Murder Must Advertise_ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Wed, Jun 20, 2001 at 12:02:47AM -0600, Hubert Chan wrote: > > "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes: > > Ethan> echo 'eb::0:0:Ethan Benson:/home/eb:/bin/bash' > /etc/passwd.d/eb > > Ethan> login whe r00t! > > Hmm. Forgot about that. I guess that would be a bit of a security > hole. :-( > > Ethan> it would be a nightmare to administer. > > I don't think so. Does the administrator need to really do much with > the password database, once a user gets set up? If you want to audit > the database, you can always just do "cat /etc/passwd.d/* | less". > And the administrative programs (usermod, chsh, etc.) shouldn't be too > hard to modify. Is there anything else that you would want to do? *.d kludges have gotten WAY out of control. they are useful in very small and limited circumstances, but all the crap redhat and friends have kludged together with them is rediculous. there are hundreds of ways to adminisister the /etc/passwd file as it is now, all of them would break (or become more complicated) with this silly passwd.d nonsense. > Well, obviously my proposed scheme wouldn't work (because of the > previously mentioned exploit), but the motivation behind the scheme was > to reduce the number of SUID programs (because if you don't need it to > be SUID, you're safer without it being SUID). Is there any (sane) way > of making it so that programs such as passwd, chsh, etc. don't need to > be SUID? no, they have to be privileged to write the passwd files, and the passwd files must only be writable by root otherwise you can trivially get root. chown passwd /etc/passwd and making all these binaries setuid passwd instead of root would also do you no good since once you can write /etc/passwd you can change roots passwd, or add a new uid=0 account. the proper solution is thoroughly auditing the setuid code, and doing your best to keep it as small and simple as possible. the current shadow utils have accomplished this pretty well. there haven't been any exploits in passwd and such in a long time. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpMB6GtWcLtQ.pgp Description: PGP signature
Re: A question about Knark and modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes: Ethan> echo 'eb::0:0:Ethan Benson:/home/eb:/bin/bash' > /etc/passwd.d/eb Ethan> login whe r00t! Hmm. Forgot about that. I guess that would be a bit of a security hole. :-( Ethan> it would be a nightmare to administer. I don't think so. Does the administrator need to really do much with the password database, once a user gets set up? If you want to audit the database, you can always just do "cat /etc/passwd.d/* | less". And the administrative programs (usermod, chsh, etc.) shouldn't be too hard to modify. Is there anything else that you would want to do? Well, obviously my proposed scheme wouldn't work (because of the previously mentioned exploit), but the motivation behind the scheme was to reduce the number of SUID programs (because if you don't need it to be SUID, you're safer without it being SUID). Is there any (sane) way of making it so that programs such as passwd, chsh, etc. don't need to be SUID? - -- Hubert Chan <[EMAIL PROTECTED]> - http://www.geocities.com/hubertchan/ PGP/GnuPG key: 1024D/71FDA37F Fingerprint: 6CC5 822D 2E55 494C 81DD 6F2C 6518 54DF 71FD A37F Key available at wwwkeys.pgp.net. Please encrypt *all* e-mail to me. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7MDxWZRhU33H9o38RAvgXAJ0YwGVu0hCotTAcr6Z76EDtFKVu9ACeIXPa PXhPZaZ2h89luwbg4cnxDig= =cpsv -END PGP SIGNATURE-
Re: A question about Knark and modules
On Wed, Jun 20, 2001 at 12:02:47AM -0600, Hubert Chan wrote: > > "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes: > > Ethan> echo 'eb::0:0:Ethan Benson:/home/eb:/bin/bash' > /etc/passwd.d/eb > > Ethan> login whe r00t! > > Hmm. Forgot about that. I guess that would be a bit of a security > hole. :-( > > Ethan> it would be a nightmare to administer. > > I don't think so. Does the administrator need to really do much with > the password database, once a user gets set up? If you want to audit > the database, you can always just do "cat /etc/passwd.d/* | less". > And the administrative programs (usermod, chsh, etc.) shouldn't be too > hard to modify. Is there anything else that you would want to do? *.d kludges have gotten WAY out of control. they are useful in very small and limited circumstances, but all the crap redhat and friends have kludged together with them is rediculous. there are hundreds of ways to adminisister the /etc/passwd file as it is now, all of them would break (or become more complicated) with this silly passwd.d nonsense. > Well, obviously my proposed scheme wouldn't work (because of the > previously mentioned exploit), but the motivation behind the scheme was > to reduce the number of SUID programs (because if you don't need it to > be SUID, you're safer without it being SUID). Is there any (sane) way > of making it so that programs such as passwd, chsh, etc. don't need to > be SUID? no, they have to be privileged to write the passwd files, and the passwd files must only be writable by root otherwise you can trivially get root. chown passwd /etc/passwd and making all these binaries setuid passwd instead of root would also do you no good since once you can write /etc/passwd you can change roots passwd, or add a new uid=0 account. the proper solution is thoroughly auditing the setuid code, and doing your best to keep it as small and simple as possible. the current shadow utils have accomplished this pretty well. there haven't been any exploits in passwd and such in a long time. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes: Ethan> echo 'eb::0:0:Ethan Benson:/home/eb:/bin/bash' > /etc/passwd.d/eb Ethan> login whe r00t! Hmm. Forgot about that. I guess that would be a bit of a security hole. :-( Ethan> it would be a nightmare to administer. I don't think so. Does the administrator need to really do much with the password database, once a user gets set up? If you want to audit the database, you can always just do "cat /etc/passwd.d/* | less". And the administrative programs (usermod, chsh, etc.) shouldn't be too hard to modify. Is there anything else that you would want to do? Well, obviously my proposed scheme wouldn't work (because of the previously mentioned exploit), but the motivation behind the scheme was to reduce the number of SUID programs (because if you don't need it to be SUID, you're safer without it being SUID). Is there any (sane) way of making it so that programs such as passwd, chsh, etc. don't need to be SUID? - -- Hubert Chan <[EMAIL PROTECTED]> - http://www.geocities.com/hubertchan/ PGP/GnuPG key: 1024D/71FDA37F Fingerprint: 6CC5 822D 2E55 494C 81DD 6F2C 6518 54DF 71FD A37F Key available at wwwkeys.pgp.net. Please encrypt *all* e-mail to me. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7MDxWZRhU33H9o38RAvgXAJ0YwGVu0hCotTAcr6Z76EDtFKVu9ACeIXPa PXhPZaZ2h89luwbg4cnxDig= =cpsv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Tue, Jun 19, 2001 at 12:35:51PM -0600, Hubert Chan wrote: > > "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes: > > Ethan> passwd not being able to update /etc/shadow would be a very bad > Ethan> thing since users would be unable to change thier own passwords. > Ethan> users need to be encouraged to change thier passwords, not > Ethan> discouraged. > > Off topic, but I'm just wondering if there has ever been any though to > putting each user's information in a separate file. So if I had users > "foo" and "bar", then I would have files /etc/passwd.d/foo and > /etc/passwd.d/bar (or something like that), with /etc/passwd.d/foo only > read/writable by user foo (and root), and /etc/passwd.d/bar only > read/writable by user bar (and root). um GROSS!!! sorry. > This way, the login programs would still need to be SUID root (but I > don't think there's any way around that, since they need to launch a > shell under different UID's), but programs such as passwd would not, > since user foo (and root) already have permissions to his password file. echo 'eb::0:0:Ethan Benson:/home/eb:/bin/bash' > /etc/passwd.d/eb login whe r00t! > The only problems I could think of is that it would eat up a chunk of > inodes (but I don't know of anyone who's running short on inodes), and > we'd have a lot of internal fragmentation in the filesystem (which > shouldn't be too much of a problem, with disk space so cheap). If all > the login programs use PAM, then creating such a scheme won't break any > programs (hopefully). it would be a nightmare to administer. > Ethan> i don't think you can really modify passwd to be that granular > Ethan> about ssh vs other methods of access. > > OK, back on topic... could you modify PAM? Do all login programs in > Debian use PAM now? i don't think its a matter of modifying things, its a matter of detecting ssh vs other forms of access is really impossible. unless you trust the utmp file maybe, even that doesn't really help. when you have uid=0 you have uid=0 nothing cares where it came from, it just is. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpZ6RcrGMnFR.pgp Description: PGP signature
Re: A question about Knark and modules
On Tue, Jun 19, 2001 at 12:35:51PM -0600, Hubert Chan wrote: > > "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes: > > Ethan> passwd not being able to update /etc/shadow would be a very bad > Ethan> thing since users would be unable to change thier own passwords. > Ethan> users need to be encouraged to change thier passwords, not > Ethan> discouraged. > > Off topic, but I'm just wondering if there has ever been any though to > putting each user's information in a separate file. So if I had users > "foo" and "bar", then I would have files /etc/passwd.d/foo and > /etc/passwd.d/bar (or something like that), with /etc/passwd.d/foo only > read/writable by user foo (and root), and /etc/passwd.d/bar only > read/writable by user bar (and root). um GROSS!!! sorry. > This way, the login programs would still need to be SUID root (but I > don't think there's any way around that, since they need to launch a > shell under different UID's), but programs such as passwd would not, > since user foo (and root) already have permissions to his password file. echo 'eb::0:0:Ethan Benson:/home/eb:/bin/bash' > /etc/passwd.d/eb login whe r00t! > The only problems I could think of is that it would eat up a chunk of > inodes (but I don't know of anyone who's running short on inodes), and > we'd have a lot of internal fragmentation in the filesystem (which > shouldn't be too much of a problem, with disk space so cheap). If all > the login programs use PAM, then creating such a scheme won't break any > programs (hopefully). it would be a nightmare to administer. > Ethan> i don't think you can really modify passwd to be that granular > Ethan> about ssh vs other methods of access. > > OK, back on topic... could you modify PAM? Do all login programs in > Debian use PAM now? i don't think its a matter of modifying things, its a matter of detecting ssh vs other forms of access is really impossible. unless you trust the utmp file maybe, even that doesn't really help. when you have uid=0 you have uid=0 nothing cares where it came from, it just is. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes: Ethan> passwd not being able to update /etc/shadow would be a very bad Ethan> thing since users would be unable to change thier own passwords. Ethan> users need to be encouraged to change thier passwords, not Ethan> discouraged. Off topic, but I'm just wondering if there has ever been any though to putting each user's information in a separate file. So if I had users "foo" and "bar", then I would have files /etc/passwd.d/foo and /etc/passwd.d/bar (or something like that), with /etc/passwd.d/foo only read/writable by user foo (and root), and /etc/passwd.d/bar only read/writable by user bar (and root). This way, the login programs would still need to be SUID root (but I don't think there's any way around that, since they need to launch a shell under different UID's), but programs such as passwd would not, since user foo (and root) already have permissions to his password file. The only problems I could think of is that it would eat up a chunk of inodes (but I don't know of anyone who's running short on inodes), and we'd have a lot of internal fragmentation in the filesystem (which shouldn't be too much of a problem, with disk space so cheap). If all the login programs use PAM, then creating such a scheme won't break any programs (hopefully). Ethan> i don't think you can really modify passwd to be that granular Ethan> about ssh vs other methods of access. OK, back on topic... could you modify PAM? Do all login programs in Debian use PAM now? - -- Hubert Chan <[EMAIL PROTECTED]> - http://www.geocities.com/hubertchan/ PGP/GnuPG key: 1024D/71FDA37F Fingerprint: 6CC5 822D 2E55 494C 81DD 6F2C 6518 54DF 71FD A37F Key available at wwwkeys.pgp.net. Please encrypt *all* e-mail to me. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7L5tUZRhU33H9o38RArQPAKDBFyBb+6fiIMPGTHTk0o3OnaUX3ACeJsf0 Uyrk7f931paQ+Nuf76efyo4= =6nTM -END PGP SIGNATURE-
Re: A question about Knark and modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes: Ethan> passwd not being able to update /etc/shadow would be a very bad Ethan> thing since users would be unable to change thier own passwords. Ethan> users need to be encouraged to change thier passwords, not Ethan> discouraged. Off topic, but I'm just wondering if there has ever been any though to putting each user's information in a separate file. So if I had users "foo" and "bar", then I would have files /etc/passwd.d/foo and /etc/passwd.d/bar (or something like that), with /etc/passwd.d/foo only read/writable by user foo (and root), and /etc/passwd.d/bar only read/writable by user bar (and root). This way, the login programs would still need to be SUID root (but I don't think there's any way around that, since they need to launch a shell under different UID's), but programs such as passwd would not, since user foo (and root) already have permissions to his password file. The only problems I could think of is that it would eat up a chunk of inodes (but I don't know of anyone who's running short on inodes), and we'd have a lot of internal fragmentation in the filesystem (which shouldn't be too much of a problem, with disk space so cheap). If all the login programs use PAM, then creating such a scheme won't break any programs (hopefully). Ethan> i don't think you can really modify passwd to be that granular Ethan> about ssh vs other methods of access. OK, back on topic... could you modify PAM? Do all login programs in Debian use PAM now? - -- Hubert Chan <[EMAIL PROTECTED]> - http://www.geocities.com/hubertchan/ PGP/GnuPG key: 1024D/71FDA37F Fingerprint: 6CC5 822D 2E55 494C 81DD 6F2C 6518 54DF 71FD A37F Key available at wwwkeys.pgp.net. Please encrypt *all* e-mail to me. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7L5tUZRhU33H9o38RArQPAKDBFyBb+6fiIMPGTHTk0o3OnaUX3ACeJsf0 Uyrk7f931paQ+Nuf76efyo4= =6nTM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Tue, Jun 19, 2001 at 10:09:51AM +0200, Christian Jaeger wrote: > At 2:17 Uhr +0200 19.6.2001, Ethan Benson wrote: > >what if the attacker can poisen your DNS, or routing tables? then he > >can trick apt into downloading his 37337 `security update' (more like > >unsecurity update heh) > > Yes, but that's a problem anyway, isn't it? In fact it's a question I yup, im just pointing out that a hole in lids is a hole for both attackers and the admin. no way around it. generally someone with root on your box will be able to mess around with routing tables and dns poisening easier then one without. (depends though). > have about debian (I'm relative newbie to debian): is there no way to > make .deb's with signatures? Do I have to parse the security-announce there is now, but nobody signs .debs yet. the Release file is now signed (it contains md5s of all Packages files which in turn contain md5s of all .debs). > list mail to get signed md5 hashes to check the downloaded deb's? If > so, is there no script doing this already? If yes, the I just wrap > this one, so the cracker could merely prevent updates from taking > place successfully. well if .debs end up getting gpg signatures apt-get install debsig-verify or something like that in woody (don't right now since it breaks dpkg since no debs are signed). all the details on this have not yet been worked out, i would hope it will get worked and implemented by woody release. > >get root, run passwd root, ssh in. > > But if the passwd command doesn't itself have the rights to access > /etc/shadow but only the root login shell has (which only runs if > called through sshd), then the cracker would have to know your root > passwd before being able to change it. passwd not being able to update /etc/shadow would be a very bad thing since users would be unable to change thier own passwords. users need to be encouraged to change thier passwords, not discouraged. i don't think you can really modify passwd to be that granular about ssh vs other methods of access. im still not convinced you could prevent root from sshing to himself. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpjAFwe7hser.pgp Description: PGP signature
Re: A question about Knark and modules
On Tue, Jun 19, 2001 at 12:17:07PM +0800, Ben Harvey wrote: > cracker==root sysadmin==root+LIDS_password > if someone can sniff me typing in my lids password (encrypted in the kernel) > then I am stuffed. they can always read the password hash out of the kernel and run a brute force attack on it too. > In short Lids can be a pain to set up, but would also be a pain to crack, > especially if the cracker doesn't know exactly which rules I have set up. > a good cracker could do it. and thats the point. my philosophy on things like lids is this: for a expert cracker (rare) they will probably be able to undo it and get around it, all it will do is make my life as an admin MISERABLE. ill just spend all my time fixing little breakage lids causes, thats how maintaining NT is i don't want that for *nix. for a moron attacker (99.999% of attackers) they will probably be stopped by my vigilent administration of the system, they won't get in unless they find a zero day exploit for some program im running. and for a high security borderline machine like my firewall i can disable module loading and access to /dev/mem which i know can be easily removed by deleting the initscript that runs lcap and rebooting, but a reboot i WILL notice and WILL audit. most attackers will become quickly annoyed by a well run system and just move on to the next vulnerable redhat box that has never seen a security update in its life. > btw I notice that they are still working on fork bomb protection. that would > be nice :) ulimit -u 20 thats all it takes. BTW your Mail-Followup-To header is broken. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpbS908ypmdf.pgp Description: PGP signature
Re: A question about Knark and modules
At 2:17 Uhr +0200 19.6.2001, Ethan Benson wrote: what if the attacker can poisen your DNS, or routing tables? then he can trick apt into downloading his 37337 `security update' (more like unsecurity update heh) Yes, but that's a problem anyway, isn't it? In fact it's a question I have about debian (I'm relative newbie to debian): is there no way to make .deb's with signatures? Do I have to parse the security-announce list mail to get signed md5 hashes to check the downloaded deb's? If so, is there no script doing this already? If yes, the I just wrap this one, so the cracker could merely prevent updates from taking place successfully. get root, run passwd root, ssh in. But if the passwd command doesn't itself have the rights to access /etc/shadow but only the root login shell has (which only runs if called through sshd), then the cracker would have to know your root passwd before being able to change it. Christian.
Re: A question about Knark and modules
On Tue, Jun 19, 2001 at 10:09:51AM +0200, Christian Jaeger wrote: > At 2:17 Uhr +0200 19.6.2001, Ethan Benson wrote: > >what if the attacker can poisen your DNS, or routing tables? then he > >can trick apt into downloading his 37337 `security update' (more like > >unsecurity update heh) > > Yes, but that's a problem anyway, isn't it? In fact it's a question I yup, im just pointing out that a hole in lids is a hole for both attackers and the admin. no way around it. generally someone with root on your box will be able to mess around with routing tables and dns poisening easier then one without. (depends though). > have about debian (I'm relative newbie to debian): is there no way to > make .deb's with signatures? Do I have to parse the security-announce there is now, but nobody signs .debs yet. the Release file is now signed (it contains md5s of all Packages files which in turn contain md5s of all .debs). > list mail to get signed md5 hashes to check the downloaded deb's? If > so, is there no script doing this already? If yes, the I just wrap > this one, so the cracker could merely prevent updates from taking > place successfully. well if .debs end up getting gpg signatures apt-get install debsig-verify or something like that in woody (don't right now since it breaks dpkg since no debs are signed). all the details on this have not yet been worked out, i would hope it will get worked and implemented by woody release. > >get root, run passwd root, ssh in. > > But if the passwd command doesn't itself have the rights to access > /etc/shadow but only the root login shell has (which only runs if > called through sshd), then the cracker would have to know your root > passwd before being able to change it. passwd not being able to update /etc/shadow would be a very bad thing since users would be unable to change thier own passwords. users need to be encouraged to change thier passwords, not discouraged. i don't think you can really modify passwd to be that granular about ssh vs other methods of access. im still not convinced you could prevent root from sshing to himself. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
On Tue, Jun 19, 2001 at 12:17:07PM +0800, Ben Harvey wrote: > cracker==root sysadmin==root+LIDS_password > if someone can sniff me typing in my lids password (encrypted in the kernel) > then I am stuffed. they can always read the password hash out of the kernel and run a brute force attack on it too. > In short Lids can be a pain to set up, but would also be a pain to crack, > especially if the cracker doesn't know exactly which rules I have set up. > a good cracker could do it. and thats the point. my philosophy on things like lids is this: for a expert cracker (rare) they will probably be able to undo it and get around it, all it will do is make my life as an admin MISERABLE. ill just spend all my time fixing little breakage lids causes, thats how maintaining NT is i don't want that for *nix. for a moron attacker (99.999% of attackers) they will probably be stopped by my vigilent administration of the system, they won't get in unless they find a zero day exploit for some program im running. and for a high security borderline machine like my firewall i can disable module loading and access to /dev/mem which i know can be easily removed by deleting the initscript that runs lcap and rebooting, but a reboot i WILL notice and WILL audit. most attackers will become quickly annoyed by a well run system and just move on to the next vulnerable redhat box that has never seen a security update in its life. > btw I notice that they are still working on fork bomb protection. that would > be nice :) ulimit -u 20 thats all it takes. BTW your Mail-Followup-To header is broken. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
At 2:17 Uhr +0200 19.6.2001, Ethan Benson wrote: >what if the attacker can poisen your DNS, or routing tables? then he >can trick apt into downloading his 37337 `security update' (more like >unsecurity update heh) Yes, but that's a problem anyway, isn't it? In fact it's a question I have about debian (I'm relative newbie to debian): is there no way to make .deb's with signatures? Do I have to parse the security-announce list mail to get signed md5 hashes to check the downloaded deb's? If so, is there no script doing this already? If yes, the I just wrap this one, so the cracker could merely prevent updates from taking place successfully. >get root, run passwd root, ssh in. But if the passwd command doesn't itself have the rights to access /etc/shadow but only the root login shell has (which only runs if called through sshd), then the cracker would have to know your root passwd before being able to change it. Christian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 07:55:40PM -0800, Ethan Benson wrote: > > a bit. lids makes system adminsitration utterly impossible. unless > you leave enough holes open which an attacker can use to bypass it > all. well nearly... at least you can prevent new or unknown process/files from acessing stuff. If there is an exploit for an existing piece of software you are back at square one. The advantage is extremely granular control: a program at a specific inode can be given capabilities while everything else has them refused. the disadvantage is that you end up with a million little holes (complexity) fortunately the files that have these added capabilities are also protected (from trojaning - buffer overruns etc still work) > > the thing is once you make exceptions for the system adminsistrator to > use to maintain the you open the holes the attacker needs to trojan > your system and to remove the additional obsticales you installed. yes it is possible with lids, but it is a _lot_ harder: processes can be hidden. binaries RO (trojaning is difficult) logs append /etc/somefile can only be read when you allow it. > > system adminsitrator == root > cracker == root > cracker==root sysadmin==root+LIDS_password if someone can sniff me typing in my lids password (encrypted in the kernel) then I am stuffed. In short Lids can be a pain to set up, but would also be a pain to crack, especially if the cracker doesn't know exactly which rules I have set up. a good cracker could do it. btw I notice that they are still working on fork bomb protection. that would be nice :) --
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 07:55:40PM -0800, Ethan Benson wrote: > > a bit. lids makes system adminsitration utterly impossible. unless > you leave enough holes open which an attacker can use to bypass it > all. well nearly... at least you can prevent new or unknown process/files from acessing stuff. If there is an exploit for an existing piece of software you are back at square one. The advantage is extremely granular control: a program at a specific inode can be given capabilities while everything else has them refused. the disadvantage is that you end up with a million little holes (complexity) fortunately the files that have these added capabilities are also protected (from trojaning - buffer overruns etc still work) > > the thing is once you make exceptions for the system adminsistrator to > use to maintain the you open the holes the attacker needs to trojan > your system and to remove the additional obsticales you installed. yes it is possible with lids, but it is a _lot_ harder: processes can be hidden. binaries RO (trojaning is difficult) logs append /etc/somefile can only be read when you allow it. > > system adminsitrator == root > cracker == root > cracker==root sysadmin==root+LIDS_password if someone can sniff me typing in my lids password (encrypted in the kernel) then I am stuffed. In short Lids can be a pain to set up, but would also be a pain to crack, especially if the cracker doesn't know exactly which rules I have set up. a good cracker could do it. btw I notice that they are still working on fork bomb protection. that would be nice :) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 06:41:59PM +0200, Christian Jaeger wrote: > > Well, if the 'apt-get update && apt-get upgrade' wrapper doesn't take > any input and resets the environment (is there anything else it > should take care of?) then even if called by the cracker it wouldn't > do anything else than upgrade the system the same way upgrades were > happening anyway before the breakin. (Ok, there may be an issue with > the changing inode numbers lids is depending upon and which would not > get updated immediately after upgrading software.) what if the attacker can poisen your DNS, or routing tables? then he can trick apt into downloading his 37337 `security update' (more like unsecurity update heh) > And/or if I install a special shell binary that has capabilities to > access the whole filesystem, but exits immediately unless called by > sshd, then system administrators still can just login as root and do > what they are used to do, without risking a hacker using the same > tool because he (probably) didn't use sshd to gain access to the > machine. (Of course, this requires 1. sshd not having a problem, and > 2. making sure depending files like /etc/shadow, pam etc are > protected, but that's what lids people propagate anyway). > > Am I wrong? get root, run passwd root, ssh in. > Of course if lids in fact can't deny access to disk devices then > probably all is lost... lids can, it adds new capabilities or else modifies one of the existing ones. (at least last i read the FAQ that seemed to be implyed). -- Ethan Benson http://www.alaska.net/~erbenson/ pgp8Gm6ZuB6OS.pgp Description: PGP signature
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 06:41:59PM +0200, Christian Jaeger wrote: > > Well, if the 'apt-get update && apt-get upgrade' wrapper doesn't take > any input and resets the environment (is there anything else it > should take care of?) then even if called by the cracker it wouldn't > do anything else than upgrade the system the same way upgrades were > happening anyway before the breakin. (Ok, there may be an issue with > the changing inode numbers lids is depending upon and which would not > get updated immediately after upgrading software.) what if the attacker can poisen your DNS, or routing tables? then he can trick apt into downloading his 37337 `security update' (more like unsecurity update heh) > And/or if I install a special shell binary that has capabilities to > access the whole filesystem, but exits immediately unless called by > sshd, then system administrators still can just login as root and do > what they are used to do, without risking a hacker using the same > tool because he (probably) didn't use sshd to gain access to the > machine. (Of course, this requires 1. sshd not having a problem, and > 2. making sure depending files like /etc/shadow, pam etc are > protected, but that's what lids people propagate anyway). > > Am I wrong? get root, run passwd root, ssh in. > Of course if lids in fact can't deny access to disk devices then > probably all is lost... lids can, it adds new capabilities or else modifies one of the existing ones. (at least last i read the FAQ that seemed to be implyed). -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
At 5:55 Uhr +0200 18.6.2001, Ethan Benson wrote: On Mon, Jun 18, 2001 at 03:03:06AM +0200, Christian Jaeger wrote: > ... install some special binaries to which you > grant many permissions. the thing is once you make exceptions for the system adminsistrator to use to maintain the you open the holes the attacker needs to trojan your system and to remove the additional obsticales you installed. system adminsitrator == root cracker == root you can't trust one without trusting the other. Well, if the 'apt-get update && apt-get upgrade' wrapper doesn't take any input and resets the environment (is there anything else it should take care of?) then even if called by the cracker it wouldn't do anything else than upgrade the system the same way upgrades were happening anyway before the breakin. (Ok, there may be an issue with the changing inode numbers lids is depending upon and which would not get updated immediately after upgrading software.) And/or if I install a special shell binary that has capabilities to access the whole filesystem, but exits immediately unless called by sshd, then system administrators still can just login as root and do what they are used to do, without risking a hacker using the same tool because he (probably) didn't use sshd to gain access to the machine. (Of course, this requires 1. sshd not having a problem, and 2. making sure depending files like /etc/shadow, pam etc are protected, but that's what lids people propagate anyway). Am I wrong? Of course if lids in fact can't deny access to disk devices then probably all is lost... Christian.
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 03:52:46AM -0800, Ethan Benson wrote: > On Mon, Jun 18, 2001 at 12:43:41PM +0200, Philipp Schulte wrote: > > Ok, so just do make sure: http://www.lids.org/lids-howto/node53.html > > is claiming that CAP_SYS_RAWIO allows access to raw block devices. > > they are mistaken. Well, somebody should tell them ;) > > BTW: Are there any "proof of concept" for this vulnerability? > > which? the /dev/mem restoration of the capability bounding set, or > removing chattr +i even when CAP_LINUX_IMMUTABLE is removed? for the > latter i have a script that does it. Yes, I would be really interested in this script. Do you have an URL or could send it to me? Some of our servers use lcap and some files are +i or +a. So far I thought that CAP_SYS_RAWIO would prevent some of the mentioned problems but obviously I was wrong. Thanks for the information, Phil
Re: A question about Knark and modules
At 5:55 Uhr +0200 18.6.2001, Ethan Benson wrote: >On Mon, Jun 18, 2001 at 03:03:06AM +0200, Christian Jaeger wrote: > > ... install some special binaries to which you > > grant many permissions. > >the thing is once you make exceptions for the system adminsistrator to >use to maintain the you open the holes the attacker needs to trojan >your system and to remove the additional obsticales you installed. > >system adminsitrator == root >cracker == root > >you can't trust one without trusting the other. Well, if the 'apt-get update && apt-get upgrade' wrapper doesn't take any input and resets the environment (is there anything else it should take care of?) then even if called by the cracker it wouldn't do anything else than upgrade the system the same way upgrades were happening anyway before the breakin. (Ok, there may be an issue with the changing inode numbers lids is depending upon and which would not get updated immediately after upgrading software.) And/or if I install a special shell binary that has capabilities to access the whole filesystem, but exits immediately unless called by sshd, then system administrators still can just login as root and do what they are used to do, without risking a hacker using the same tool because he (probably) didn't use sshd to gain access to the machine. (Of course, this requires 1. sshd not having a problem, and 2. making sure depending files like /etc/shadow, pam etc are protected, but that's what lids people propagate anyway). Am I wrong? Of course if lids in fact can't deny access to disk devices then probably all is lost... Christian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 03:52:46AM -0800, Ethan Benson wrote: > On Mon, Jun 18, 2001 at 12:43:41PM +0200, Philipp Schulte wrote: > > Ok, so just do make sure: http://www.lids.org/lids-howto/node53.html > > is claiming that CAP_SYS_RAWIO allows access to raw block devices. > > they are mistaken. Well, somebody should tell them ;) > > BTW: Are there any "proof of concept" for this vulnerability? > > which? the /dev/mem restoration of the capability bounding set, or > removing chattr +i even when CAP_LINUX_IMMUTABLE is removed? for the > latter i have a script that does it. Yes, I would be really interested in this script. Do you have an URL or could send it to me? Some of our servers use lcap and some files are +i or +a. So far I thought that CAP_SYS_RAWIO would prevent some of the mentioned problems but obviously I was wrong. Thanks for the information, Phil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 12:43:41PM +0200, Philipp Schulte wrote: > On Mon, Jun 18, 2001 at 12:35:13AM -0800, Ethan Benson wrote: > > > chattr +i and +a cannot be set or removed if CAP_LINUX_IMMUTABLE is > > removed from the bounding set. however that does not prevent root > > from messing with /dev/hda* directly, niether does CAP_SYS_RAWIO. > > > > there is no capability that allows you to deny root access to the raw > > block devices, so removing the immutable bit is trivially easy. > > Ok, so just do make sure: http://www.lids.org/lids-howto/node53.html > is claiming that CAP_SYS_RAWIO allows access to raw block devices. they are mistaken. > Does LIDS change the behaviour of the cap or are they claiming > something wrong? they do make all sorts of change to the kernel since the current capability bounding set isn't complete enough to accomplish anything that can't be trivally undone by moving stuff around the filesystem and rebooting once. the trouble with lids, or more so the ideas they go with is you break your system so badly that it becomes impossible to administer, certianly impossible to admin remotely. the cost is too high IMO. > BTW: Are there any "proof of concept" for this vulnerability? which? the /dev/mem restoration of the capability bounding set, or removing chattr +i even when CAP_LINUX_IMMUTABLE is removed? for the latter i have a script that does it. for the former not that i know of, but if i were better at C i think i could put one together in an hour or less, here is the explanation: http://www.netcom.com/~spoon/lcap/bugtraq.txt -- Ethan Benson http://www.alaska.net/~erbenson/ pgpGI22VOG8ID.pgp Description: PGP signature
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 12:35:13AM -0800, Ethan Benson wrote: > chattr +i and +a cannot be set or removed if CAP_LINUX_IMMUTABLE is > removed from the bounding set. however that does not prevent root > from messing with /dev/hda* directly, niether does CAP_SYS_RAWIO. > > there is no capability that allows you to deny root access to the raw > block devices, so removing the immutable bit is trivially easy. Ok, so just do make sure: http://www.lids.org/lids-howto/node53.html is claiming that CAP_SYS_RAWIO allows access to raw block devices. Does LIDS change the behaviour of the cap or are they claiming something wrong? BTW: Are there any "proof of concept" for this vulnerability? Regards, Phil
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 12:43:41PM +0200, Philipp Schulte wrote: > On Mon, Jun 18, 2001 at 12:35:13AM -0800, Ethan Benson wrote: > > > chattr +i and +a cannot be set or removed if CAP_LINUX_IMMUTABLE is > > removed from the bounding set. however that does not prevent root > > from messing with /dev/hda* directly, niether does CAP_SYS_RAWIO. > > > > there is no capability that allows you to deny root access to the raw > > block devices, so removing the immutable bit is trivially easy. > > Ok, so just do make sure: http://www.lids.org/lids-howto/node53.html > is claiming that CAP_SYS_RAWIO allows access to raw block devices. they are mistaken. > Does LIDS change the behaviour of the cap or are they claiming > something wrong? they do make all sorts of change to the kernel since the current capability bounding set isn't complete enough to accomplish anything that can't be trivally undone by moving stuff around the filesystem and rebooting once. the trouble with lids, or more so the ideas they go with is you break your system so badly that it becomes impossible to administer, certianly impossible to admin remotely. the cost is too high IMO. > BTW: Are there any "proof of concept" for this vulnerability? which? the /dev/mem restoration of the capability bounding set, or removing chattr +i even when CAP_LINUX_IMMUTABLE is removed? for the latter i have a script that does it. for the former not that i know of, but if i were better at C i think i could put one together in an hour or less, here is the explanation: http://www.netcom.com/~spoon/lcap/bugtraq.txt -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 04:02:08AM -0300, Peter Cordes wrote: > > You need to keep it somewhere if you ever want to build more modules > that that kernel will load. I don't know why I assumed it would be > stored in the kernel image. it could be a separate file, encrpyted (like gpg private keys) and even kept on a floppy somewhere. > Hmm, if you compiled on a separate machine, or kept the key on a > floppy, you could do make change the last step to "get all traces of > the key off the 'secure' machine". yup > exactly. starting with the signing and IO protecting would be a very > good start. yup > As for secure block devs, you could have the kernel drop the ability > to write to certain partitions of certain disks, or something like > that. Blocking writes to mounted partitions wouldn't help for > partitions that can be unmounted and remounted easily. (writes to the > whole-drive block devices would have to go through the same checks, or > maybe even be blocked entirely if they fell within space allocated to > a partition.) If this got done, the signing idea would kick ass. > As it is, it's just pretty good... whats annoying is BSD already has this, and has for quite some time. at bootup of a standard Free,Net, or OpenBSD box the securelevel is raised to 1, which denies root the ability to remove system immutable flags, it also denies root the ability to write to raw block devices for the mounted filesystems, but not to the whole disk device, so he could still hack the filesystem, its just a tad harder. raising the securelevel to 2 denies access to all disk block devices, whole and partitions mounted or not. (among other things like sealing firewall rules and such). iirc the 2.0 linux kernel had a securelevel which was about equivilent to BSD securelevels. 2.2 removed it since `capabilities make securelevel obsolete' well not quite heh. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpHHDqyI50Su.pgp Description: PGP signature
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 08:56:03AM +0200, Philipp Schulte wrote: > On Sun, Jun 17, 2001 at 10:42:17PM -0800, Ethan Benson wrote: > > > you would need to fix filesystem immutability and block device access > > as well. currently lcap CAP_LINUX_IMMUTABLE is useless since there > > is no way to deny root the ability to write directly to /dev/hda* and > > remove the immutable bits (ive written a script to remove chattr +i > > and +a even when CAP_LINUX_IMMUTABLE is removed from the bounding set, > > no reboot required). > > I thought CAP_SYS_RAWIO would take care of that issue? > Is is still possible to chattr +i if CAP_SYS_RAWIO is removed? chattr +i and +a cannot be set or removed if CAP_LINUX_IMMUTABLE is removed from the bounding set. however that does not prevent root from messing with /dev/hda* directly, niether does CAP_SYS_RAWIO. there is no capability that allows you to deny root access to the raw block devices, so removing the immutable bit is trivially easy. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpIl5hUKla3K.pgp Description: PGP signature
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 12:35:13AM -0800, Ethan Benson wrote: > chattr +i and +a cannot be set or removed if CAP_LINUX_IMMUTABLE is > removed from the bounding set. however that does not prevent root > from messing with /dev/hda* directly, niether does CAP_SYS_RAWIO. > > there is no capability that allows you to deny root access to the raw > block devices, so removing the immutable bit is trivially easy. Ok, so just do make sure: http://www.lids.org/lids-howto/node53.html is claiming that CAP_SYS_RAWIO allows access to raw block devices. Does LIDS change the behaviour of the cap or are they claiming something wrong? BTW: Are there any "proof of concept" for this vulnerability? Regards, Phil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 10:42:17PM -0800, Ethan Benson wrote: > On Mon, Jun 18, 2001 at 01:38:16AM -0300, Peter Cordes wrote: > > I like the package signing idea. That would be cool. That way, you > > could still load and unload modules. I like being able to do that. > > One obvious problem with the scheme is that an attacker could > > potentially read the keys from /boot/vmlinuz-2.4.5, or whatever, and > > sign their own module. This can be overcome if we give up the ability > > how? the kernel does not need the private key to verify the > signature. You need to keep it somewhere if you ever want to build more modules that that kernel will load. I don't know why I assumed it would be stored in the kernel image. > > replacing the kernel image and rebooting would be another way to get > around this. as would injecting code into /dev/mem. > > > to compile more modules for that kernel after we finish compiling it: > > - Generate a key pair during kernel compilation (RSA would be a good > > alg. for this). > > - Sign the modules with one half of the key pair. > > - store the other half of the key pair in the kernel image. > > - _delete_ all traces of the key used to sign the modules. > > yup > Hmm, if you compiled on a separate machine, or kept the key on a floppy, you could do make change the last step to "get all traces of the key off the 'secure' machine". > > All that's needed to make this workable is to find a way to provide > > access to IO/device memory space for X11 without allowing read/write > > access to kernel memory. This can't really be all that hard. I think > > the kernel can tell when the memory address written to or mapped in > > /dev/mem is part of kernel memory by checking where the kernel is in > > memory. A very restrictive raw mem device that only allowed processes > > to map PCI memory space, or maybe just PCI memory space that PCI > > devices reported in their configuration info, would do the job for > > X11. (BTW, AGP acts like another PCI bus). Limiting things to only > > PCI-reported memory spaces would stop access from user space to ISA > > memory, but who would want to do that anyway... > > this would be a good idea anyway, it might reduce the possiblity of X > killing the entire box whenever it hiccups and scribbles random > memory. Yes, that's what I was thinking too. > > > I like this idea. It would kick ass, so we should do it. > > you would need to fix filesystem immutability and block device access > as well. currently lcap CAP_LINUX_IMMUTABLE is useless since there > is no way to deny root the ability to write directly to /dev/hda* and > remove the immutable bits (ive written a script to remove chattr +i > and +a even when CAP_LINUX_IMMUTABLE is removed from the bounding set, > no reboot required). > > otherwise the attacker can just replace your kernel image and reboot > (which is of course fairly noticable). exactly. starting with the signing and IO protecting would be a very good start. As for secure block devs, you could have the kernel drop the ability to write to certain partitions of certain disks, or something like that. Blocking writes to mounted partitions wouldn't help for partitions that can be unmounted and remounted easily. (writes to the whole-drive block devices would have to go through the same checks, or maybe even be blocked entirely if they fell within space allocated to a partition.) If this got done, the signing idea would kick ass. As it is, it's just pretty good... -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 10:42:17PM -0800, Ethan Benson wrote: > you would need to fix filesystem immutability and block device access > as well. currently lcap CAP_LINUX_IMMUTABLE is useless since there > is no way to deny root the ability to write directly to /dev/hda* and > remove the immutable bits (ive written a script to remove chattr +i > and +a even when CAP_LINUX_IMMUTABLE is removed from the bounding set, > no reboot required). I thought CAP_SYS_RAWIO would take care of that issue? Is is still possible to chattr +i if CAP_SYS_RAWIO is removed? Phil
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 01:38:16AM -0300, Peter Cordes wrote: > I like the package signing idea. That would be cool. That way, you > could still load and unload modules. I like being able to do that. > One obvious problem with the scheme is that an attacker could > potentially read the keys from /boot/vmlinuz-2.4.5, or whatever, and > sign their own module. This can be overcome if we give up the ability how? the kernel does not need the private key to verify the signature. replacing the kernel image and rebooting would be another way to get around this. as would injecting code into /dev/mem. > to compile more modules for that kernel after we finish compiling it: > - Generate a key pair during kernel compilation (RSA would be a good > alg. for this). > - Sign the modules with one half of the key pair. > - store the other half of the key pair in the kernel image. > - _delete_ all traces of the key used to sign the modules. yup > All that's needed to make this workable is to find a way to provide > access to IO/device memory space for X11 without allowing read/write > access to kernel memory. This can't really be all that hard. I think > the kernel can tell when the memory address written to or mapped in > /dev/mem is part of kernel memory by checking where the kernel is in > memory. A very restrictive raw mem device that only allowed processes > to map PCI memory space, or maybe just PCI memory space that PCI > devices reported in their configuration info, would do the job for > X11. (BTW, AGP acts like another PCI bus). Limiting things to only > PCI-reported memory spaces would stop access from user space to ISA > memory, but who would want to do that anyway... this would be a good idea anyway, it might reduce the possiblity of X killing the entire box whenever it hiccups and scribbles random memory. > I like this idea. It would kick ass, so we should do it. you would need to fix filesystem immutability and block device access as well. currently lcap CAP_LINUX_IMMUTABLE is useless since there is no way to deny root the ability to write directly to /dev/hda* and remove the immutable bits (ive written a script to remove chattr +i and +a even when CAP_LINUX_IMMUTABLE is removed from the bounding set, no reboot required). otherwise the attacker can just replace your kernel image and reboot (which is of course fairly noticable). -- Ethan Benson http://www.alaska.net/~erbenson/ pgpvJEbYjdjjQ.pgp Description: PGP signature
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 04:02:08AM -0300, Peter Cordes wrote: > > You need to keep it somewhere if you ever want to build more modules > that that kernel will load. I don't know why I assumed it would be > stored in the kernel image. it could be a separate file, encrpyted (like gpg private keys) and even kept on a floppy somewhere. > Hmm, if you compiled on a separate machine, or kept the key on a > floppy, you could do make change the last step to "get all traces of > the key off the 'secure' machine". yup > exactly. starting with the signing and IO protecting would be a very > good start. yup > As for secure block devs, you could have the kernel drop the ability > to write to certain partitions of certain disks, or something like > that. Blocking writes to mounted partitions wouldn't help for > partitions that can be unmounted and remounted easily. (writes to the > whole-drive block devices would have to go through the same checks, or > maybe even be blocked entirely if they fell within space allocated to > a partition.) If this got done, the signing idea would kick ass. > As it is, it's just pretty good... whats annoying is BSD already has this, and has for quite some time. at bootup of a standard Free,Net, or OpenBSD box the securelevel is raised to 1, which denies root the ability to remove system immutable flags, it also denies root the ability to write to raw block devices for the mounted filesystems, but not to the whole disk device, so he could still hack the filesystem, its just a tad harder. raising the securelevel to 2 denies access to all disk block devices, whole and partitions mounted or not. (among other things like sealing firewall rules and such). iirc the 2.0 linux kernel had a securelevel which was about equivilent to BSD securelevels. 2.2 removed it since `capabilities make securelevel obsolete' well not quite heh. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 08:56:03AM +0200, Philipp Schulte wrote: > On Sun, Jun 17, 2001 at 10:42:17PM -0800, Ethan Benson wrote: > > > you would need to fix filesystem immutability and block device access > > as well. currently lcap CAP_LINUX_IMMUTABLE is useless since there > > is no way to deny root the ability to write directly to /dev/hda* and > > remove the immutable bits (ive written a script to remove chattr +i > > and +a even when CAP_LINUX_IMMUTABLE is removed from the bounding set, > > no reboot required). > > I thought CAP_SYS_RAWIO would take care of that issue? > Is is still possible to chattr +i if CAP_SYS_RAWIO is removed? chattr +i and +a cannot be set or removed if CAP_LINUX_IMMUTABLE is removed from the bounding set. however that does not prevent root from messing with /dev/hda* directly, niether does CAP_SYS_RAWIO. there is no capability that allows you to deny root access to the raw block devices, so removing the immutable bit is trivially easy. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
I like the package signing idea. That would be cool. That way, you could still load and unload modules. I like being able to do that. One obvious problem with the scheme is that an attacker could potentially read the keys from /boot/vmlinuz-2.4.5, or whatever, and sign their own module. This can be overcome if we give up the ability to compile more modules for that kernel after we finish compiling it: - Generate a key pair during kernel compilation (RSA would be a good alg. for this). - Sign the modules with one half of the key pair. - store the other half of the key pair in the kernel image. - _delete_ all traces of the key used to sign the modules. All that's needed to make this workable is to find a way to provide access to IO/device memory space for X11 without allowing read/write access to kernel memory. This can't really be all that hard. I think the kernel can tell when the memory address written to or mapped in /dev/mem is part of kernel memory by checking where the kernel is in memory. A very restrictive raw mem device that only allowed processes to map PCI memory space, or maybe just PCI memory space that PCI devices reported in their configuration info, would do the job for X11. (BTW, AGP acts like another PCI bus). Limiting things to only PCI-reported memory spaces would stop access from user space to ISA memory, but who would want to do that anyway... I like this idea. It would kick ass, so we should do it. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 10:42:17PM -0800, Ethan Benson wrote: > On Mon, Jun 18, 2001 at 01:38:16AM -0300, Peter Cordes wrote: > > I like the package signing idea. That would be cool. That way, you > > could still load and unload modules. I like being able to do that. > > One obvious problem with the scheme is that an attacker could > > potentially read the keys from /boot/vmlinuz-2.4.5, or whatever, and > > sign their own module. This can be overcome if we give up the ability > > how? the kernel does not need the private key to verify the > signature. You need to keep it somewhere if you ever want to build more modules that that kernel will load. I don't know why I assumed it would be stored in the kernel image. > > replacing the kernel image and rebooting would be another way to get > around this. as would injecting code into /dev/mem. > > > to compile more modules for that kernel after we finish compiling it: > > - Generate a key pair during kernel compilation (RSA would be a good > > alg. for this). > > - Sign the modules with one half of the key pair. > > - store the other half of the key pair in the kernel image. > > - _delete_ all traces of the key used to sign the modules. > > yup > Hmm, if you compiled on a separate machine, or kept the key on a floppy, you could do make change the last step to "get all traces of the key off the 'secure' machine". > > All that's needed to make this workable is to find a way to provide > > access to IO/device memory space for X11 without allowing read/write > > access to kernel memory. This can't really be all that hard. I think > > the kernel can tell when the memory address written to or mapped in > > /dev/mem is part of kernel memory by checking where the kernel is in > > memory. A very restrictive raw mem device that only allowed processes > > to map PCI memory space, or maybe just PCI memory space that PCI > > devices reported in their configuration info, would do the job for > > X11. (BTW, AGP acts like another PCI bus). Limiting things to only > > PCI-reported memory spaces would stop access from user space to ISA > > memory, but who would want to do that anyway... > > this would be a good idea anyway, it might reduce the possiblity of X > killing the entire box whenever it hiccups and scribbles random > memory. Yes, that's what I was thinking too. > > > I like this idea. It would kick ass, so we should do it. > > you would need to fix filesystem immutability and block device access > as well. currently lcap CAP_LINUX_IMMUTABLE is useless since there > is no way to deny root the ability to write directly to /dev/hda* and > remove the immutable bits (ive written a script to remove chattr +i > and +a even when CAP_LINUX_IMMUTABLE is removed from the bounding set, > no reboot required). > > otherwise the attacker can just replace your kernel image and reboot > (which is of course fairly noticable). exactly. starting with the signing and IO protecting would be a very good start. As for secure block devs, you could have the kernel drop the ability to write to certain partitions of certain disks, or something like that. Blocking writes to mounted partitions wouldn't help for partitions that can be unmounted and remounted easily. (writes to the whole-drive block devices would have to go through the same checks, or maybe even be blocked entirely if they fell within space allocated to a partition.) If this got done, the signing idea would kick ass. As it is, it's just pretty good... -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 10:42:17PM -0800, Ethan Benson wrote: > you would need to fix filesystem immutability and block device access > as well. currently lcap CAP_LINUX_IMMUTABLE is useless since there > is no way to deny root the ability to write directly to /dev/hda* and > remove the immutable bits (ive written a script to remove chattr +i > and +a even when CAP_LINUX_IMMUTABLE is removed from the bounding set, > no reboot required). I thought CAP_SYS_RAWIO would take care of that issue? Is is still possible to chattr +i if CAP_SYS_RAWIO is removed? Phil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 01:38:16AM -0300, Peter Cordes wrote: > I like the package signing idea. That would be cool. That way, you > could still load and unload modules. I like being able to do that. > One obvious problem with the scheme is that an attacker could > potentially read the keys from /boot/vmlinuz-2.4.5, or whatever, and > sign their own module. This can be overcome if we give up the ability how? the kernel does not need the private key to verify the signature. replacing the kernel image and rebooting would be another way to get around this. as would injecting code into /dev/mem. > to compile more modules for that kernel after we finish compiling it: > - Generate a key pair during kernel compilation (RSA would be a good > alg. for this). > - Sign the modules with one half of the key pair. > - store the other half of the key pair in the kernel image. > - _delete_ all traces of the key used to sign the modules. yup > All that's needed to make this workable is to find a way to provide > access to IO/device memory space for X11 without allowing read/write > access to kernel memory. This can't really be all that hard. I think > the kernel can tell when the memory address written to or mapped in > /dev/mem is part of kernel memory by checking where the kernel is in > memory. A very restrictive raw mem device that only allowed processes > to map PCI memory space, or maybe just PCI memory space that PCI > devices reported in their configuration info, would do the job for > X11. (BTW, AGP acts like another PCI bus). Limiting things to only > PCI-reported memory spaces would stop access from user space to ISA > memory, but who would want to do that anyway... this would be a good idea anyway, it might reduce the possiblity of X killing the entire box whenever it hiccups and scribbles random memory. > I like this idea. It would kick ass, so we should do it. you would need to fix filesystem immutability and block device access as well. currently lcap CAP_LINUX_IMMUTABLE is useless since there is no way to deny root the ability to write directly to /dev/hda* and remove the immutable bits (ive written a script to remove chattr +i and +a even when CAP_LINUX_IMMUTABLE is removed from the bounding set, no reboot required). otherwise the attacker can just replace your kernel image and reboot (which is of course fairly noticable). -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 01:27:37AM +, Jim Breton wrote: > On Sun, Jun 17, 2001 at 02:44:48AM -0800, Ethan Benson wrote: > > > > compiling without module support would be mostly the same as just > > > > lcap CAP_SYS_MODULE > > > Fwiw, I have heard (though not tested myself) that even if you compile > your kernel _without_ loadable module support, you will still be able > to insert modules into the running kernel. well sort of. its not quite as simple as just loading the module. you have to manually insert the code into the running kernel and manually modify kernel memory through /dev/mem. > Again I have not tried this myself, but something to test for before > relying on a certain behavior. my lcap CAP_SYS_MODULE trick doesn't do you much good without disabling /dev/mem since its really quite trivial to go into /dev/mem and twiddle the bits of memory containing the capability bounding set. there is no example code to do this, but its explained on bugtraq quite some time ago. i think it could be done with only a couple lines of C. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpC0CtFtRic5.pgp Description: PGP signature
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 03:03:06AM +0200, Christian Jaeger wrote: > Hello > > Do you know about LIDS (www.lids.org)? It also gives the ability to > play with CAP's, but seems much more sophisticated. > > I've just subscribed to this list. Has LIDS been discussed here before? a bit. lids makes system adminsitration utterly impossible. unless you leave enough holes open which an attacker can use to bypass it all. > correct), rather than effectively inhibiting a breakin. But even for > this purpose it seems you have to secure almost every file in your > system with ACL's (which is not very comfortable). Maybe this idea > from mine is working well: install some special binaries to which you > grant many permissions. One is an 'apt-get update/upgrade' wrapper > (so automatic security updates work), another one might be a shell > wrapper allowing system administrators to work on /etc, and so on. I > think I'll ask this on the lids list later if that's the better place > for such discussions. the thing is once you make exceptions for the system adminsistrator to use to maintain the you open the holes the attacker needs to trojan your system and to remove the additional obsticales you installed. system adminsitrator == root cracker == root you can't trust one without trusting the other. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpdRJiJHkVy6.pgp Description: PGP signature
Re: A question about Knark and modules
I like the package signing idea. That would be cool. That way, you could still load and unload modules. I like being able to do that. One obvious problem with the scheme is that an attacker could potentially read the keys from /boot/vmlinuz-2.4.5, or whatever, and sign their own module. This can be overcome if we give up the ability to compile more modules for that kernel after we finish compiling it: - Generate a key pair during kernel compilation (RSA would be a good alg. for this). - Sign the modules with one half of the key pair. - store the other half of the key pair in the kernel image. - _delete_ all traces of the key used to sign the modules. All that's needed to make this workable is to find a way to provide access to IO/device memory space for X11 without allowing read/write access to kernel memory. This can't really be all that hard. I think the kernel can tell when the memory address written to or mapped in /dev/mem is part of kernel memory by checking where the kernel is in memory. A very restrictive raw mem device that only allowed processes to map PCI memory space, or maybe just PCI memory space that PCI devices reported in their configuration info, would do the job for X11. (BTW, AGP acts like another PCI bus). Limiting things to only PCI-reported memory spaces would stop access from user space to ISA memory, but who would want to do that anyway... I like this idea. It would kick ass, so we should do it. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 01:27:37AM +, Jim Breton wrote: > On Sun, Jun 17, 2001 at 02:44:48AM -0800, Ethan Benson wrote: > > > > compiling without module support would be mostly the same as just > > > > lcap CAP_SYS_MODULE > > > Fwiw, I have heard (though not tested myself) that even if you compile > your kernel _without_ loadable module support, you will still be able > to insert modules into the running kernel. well sort of. its not quite as simple as just loading the module. you have to manually insert the code into the running kernel and manually modify kernel memory through /dev/mem. > Again I have not tried this myself, but something to test for before > relying on a certain behavior. my lcap CAP_SYS_MODULE trick doesn't do you much good without disabling /dev/mem since its really quite trivial to go into /dev/mem and twiddle the bits of memory containing the capability bounding set. there is no example code to do this, but its explained on bugtraq quite some time ago. i think it could be done with only a couple lines of C. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 03:03:06AM +0200, Christian Jaeger wrote: > Hello > > Do you know about LIDS (www.lids.org)? It also gives the ability to > play with CAP's, but seems much more sophisticated. > > I've just subscribed to this list. Has LIDS been discussed here before? a bit. lids makes system adminsitration utterly impossible. unless you leave enough holes open which an attacker can use to bypass it all. > correct), rather than effectively inhibiting a breakin. But even for > this purpose it seems you have to secure almost every file in your > system with ACL's (which is not very comfortable). Maybe this idea > from mine is working well: install some special binaries to which you > grant many permissions. One is an 'apt-get update/upgrade' wrapper > (so automatic security updates work), another one might be a shell > wrapper allowing system administrators to work on /etc, and so on. I > think I'll ask this on the lids list later if that's the better place > for such discussions. the thing is once you make exceptions for the system adminsistrator to use to maintain the you open the holes the attacker needs to trojan your system and to remove the additional obsticales you installed. system adminsitrator == root cracker == root you can't trust one without trusting the other. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 02:44:48AM -0800, Ethan Benson wrote: > > compiling without module support would be mostly the same as just > > lcap CAP_SYS_MODULE Fwiw, I have heard (though not tested myself) that even if you compile your kernel _without_ loadable module support, you will still be able to insert modules into the running kernel. Again I have not tried this myself, but something to test for before relying on a certain behavior.
Re: A question about Knark and modules
Hello Do you know about LIDS (www.lids.org)? It also gives the ability to play with CAP's, but seems much more sophisticated. I've just subscribed to this list. Has LIDS been discussed here before? I'm interested in using it, but am not sure how to use it best. In fact I currently think it's best suited for just making sure tools like tripwire can operate safely (so it's helping intrusion detection, hence it's name (linux intrusion detection system) is very correct), rather than effectively inhibiting a breakin. But even for this purpose it seems you have to secure almost every file in your system with ACL's (which is not very comfortable). Maybe this idea from mine is working well: install some special binaries to which you grant many permissions. One is an 'apt-get update/upgrade' wrapper (so automatic security updates work), another one might be a shell wrapper allowing system administrators to work on /etc, and so on. I think I'll ask this on the lids list later if that's the better place for such discussions. Christian. At 3:00 Uhr +0200 17.6.2001, Ethan Benson wrote: lcap CAP_SYS_MODULE CAP_SYS_RAWIO
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 02:44:48AM -0800, Ethan Benson wrote: > > compiling without module support would be mostly the same as just > > lcap CAP_SYS_MODULE Fwiw, I have heard (though not tested myself) that even if you compile your kernel _without_ loadable module support, you will still be able to insert modules into the running kernel. Again I have not tried this myself, but something to test for before relying on a certain behavior. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
Hello Do you know about LIDS (www.lids.org)? It also gives the ability to play with CAP's, but seems much more sophisticated. I've just subscribed to this list. Has LIDS been discussed here before? I'm interested in using it, but am not sure how to use it best. In fact I currently think it's best suited for just making sure tools like tripwire can operate safely (so it's helping intrusion detection, hence it's name (linux intrusion detection system) is very correct), rather than effectively inhibiting a breakin. But even for this purpose it seems you have to secure almost every file in your system with ACL's (which is not very comfortable). Maybe this idea from mine is working well: install some special binaries to which you grant many permissions. One is an 'apt-get update/upgrade' wrapper (so automatic security updates work), another one might be a shell wrapper allowing system administrators to work on /etc, and so on. I think I'll ask this on the lids list later if that's the better place for such discussions. Christian. At 3:00 Uhr +0200 17.6.2001, Ethan Benson wrote: >lcap CAP_SYS_MODULE CAP_SYS_RAWIO -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 01:54:14PM +0200, Sjarn Valkhoff wrote: > > lcap CAP_SYS_MODULE CAP_SYS_RAWIO > > Thanks for the input. Two points: > > 1. I coming at this problem as a laptop user so pcmcia modules must remain > and be loadable and unloadable at will - as far as I know, there is no > direct > way to compile pcmcia modules directly into the kernel like the other > drivers. your stuck then live with the risk of knark, nothing you can do about it but install security updates and be a vigilant admin unlike all the morons with root passwords. > 2. What if /dev/mem access was determined at kernel compile time as an > option? no > I'm not familiar with lcap, but I assume it disables access to /dev/mem > without > breaking anything, so why not make this risky access optional at kernel > level? access to /dev/mem, /dev/kmem, /proc/kcore and such require a capability (privilege) known as CAP_SYS_RAWIO, its not just file permissions or having uid=0. lcap removes CAP_SYS_RAWIO from the capability bounding set, which means that NO process already running or run in the future can hold that capability, without the capability the kernel denies any read or writes to these devices, even to root. as for not breaking anything, that depends, nothing breaks on my firewall which is headless and runs only a handful of processes. the only thing out of the ordinary is a warning from klogd about not being able to read /dev/kmem for whatever reason it wants to poke there, it still works. if you use X though you will be disappointed, X mucks around /dev/mem. > Concurred, however, I prefer proactive rather than reactive. The danger of > undisclosed exploits always leaves this area of doubt. If the expoilt cannot > happen in the first place, a whole generation of exploits is eliminated at > once. in this case you must make very large sacrifices to accomplish this. including giving up kernel modules and X11. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpVxvBhtF5Jq.pgp Description: PGP signature
Re: A question about Knark and modules
> lcap CAP_SYS_MODULE CAP_SYS_RAWIO Thanks for the input. Two points: 1. I coming at this problem as a laptop user so pcmcia modules must remain and be loadable and unloadable at will - as far as I know, there is no direct way to compile pcmcia modules directly into the kernel like the other drivers. 2. What if /dev/mem access was determined at kernel compile time as an option? I'm not familiar with lcap, but I assume it disables access to /dev/mem without breaking anything, so why not make this risky access optional at kernel level? > i suggest installing all security updates immediatly when they arrive > and vigilent sysadmin. those will keep your box uncompromised better > then anything (except turning it off). Concurred, however, I prefer proactive rather than reactive. The danger of undisclosed exploits always leaves this area of doubt. If the expoilt cannot happen in the first place, a whole generation of exploits is eliminated at once. -- Sjarn Valkhoff
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 01:54:14PM +0200, Sjarn Valkhoff wrote: > > lcap CAP_SYS_MODULE CAP_SYS_RAWIO > > Thanks for the input. Two points: > > 1. I coming at this problem as a laptop user so pcmcia modules must remain > and be loadable and unloadable at will - as far as I know, there is no > direct > way to compile pcmcia modules directly into the kernel like the other > drivers. your stuck then live with the risk of knark, nothing you can do about it but install security updates and be a vigilant admin unlike all the morons with root passwords. > 2. What if /dev/mem access was determined at kernel compile time as an > option? no > I'm not familiar with lcap, but I assume it disables access to /dev/mem > without > breaking anything, so why not make this risky access optional at kernel > level? access to /dev/mem, /dev/kmem, /proc/kcore and such require a capability (privilege) known as CAP_SYS_RAWIO, its not just file permissions or having uid=0. lcap removes CAP_SYS_RAWIO from the capability bounding set, which means that NO process already running or run in the future can hold that capability, without the capability the kernel denies any read or writes to these devices, even to root. as for not breaking anything, that depends, nothing breaks on my firewall which is headless and runs only a handful of processes. the only thing out of the ordinary is a warning from klogd about not being able to read /dev/kmem for whatever reason it wants to poke there, it still works. if you use X though you will be disappointed, X mucks around /dev/mem. > Concurred, however, I prefer proactive rather than reactive. The danger of > undisclosed exploits always leaves this area of doubt. If the expoilt cannot > happen in the first place, a whole generation of exploits is eliminated at > once. in this case you must make very large sacrifices to accomplish this. including giving up kernel modules and X11. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 01:21:45PM +0300, Juha Jäykkä wrote: > > lcap CAP_SYS_MODULE CAP_SYS_RAWIO > > which will disable module loading entirely as well as access to > > /dev/mem (which can be just as dangerous as a kernel module and would > > bypass your signed module thing nicely). > > Which means: so long, X. I have a workstation and using X in, > naturally, necessary (in fact, it is paramount since 3D rendering > without Xfree4's opengl is horrible). Thus this option is out. How > about compiling the kernel without module support in the first place? > The problem of /dev/mem would remain, but if the kernel does not know > about modules, is it a problem? compiling without module support would be mostly the same as just lcap CAP_SYS_MODULE leaving /dev/mem open leaves you open regardless of how you stop module loading. i suggest installing all security updates immediatly when they arrive and vigilent sysadmin. those will keep your box uncompromised better then anything (except turning it off). -- Ethan Benson http://www.alaska.net/~erbenson/ pgpXdAtbKcUlQ.pgp Description: PGP signature
Re: A question about Knark and modules
> lcap CAP_SYS_MODULE CAP_SYS_RAWIO > which will disable module loading entirely as well as access to > /dev/mem (which can be just as dangerous as a kernel module and would > bypass your signed module thing nicely). Which means: so long, X. I have a workstation and using X in, naturally, necessary (in fact, it is paramount since 3D rendering without Xfree4's opengl is horrible). Thus this option is out. How about compiling the kernel without module support in the first place? The problem of /dev/mem would remain, but if the kernel does not know about modules, is it a problem? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: A question about Knark and modules
> lcap CAP_SYS_MODULE CAP_SYS_RAWIO Thanks for the input. Two points: 1. I coming at this problem as a laptop user so pcmcia modules must remain and be loadable and unloadable at will - as far as I know, there is no direct way to compile pcmcia modules directly into the kernel like the other drivers. 2. What if /dev/mem access was determined at kernel compile time as an option? I'm not familiar with lcap, but I assume it disables access to /dev/mem without breaking anything, so why not make this risky access optional at kernel level? > i suggest installing all security updates immediatly when they arrive > and vigilent sysadmin. those will keep your box uncompromised better > then anything (except turning it off). Concurred, however, I prefer proactive rather than reactive. The danger of undisclosed exploits always leaves this area of doubt. If the expoilt cannot happen in the first place, a whole generation of exploits is eliminated at once. -- Sjarn Valkhoff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 01:21:45PM +0300, Juha Jäykkä wrote: > > lcap CAP_SYS_MODULE CAP_SYS_RAWIO > > which will disable module loading entirely as well as access to > > /dev/mem (which can be just as dangerous as a kernel module and would > > bypass your signed module thing nicely). > > Which means: so long, X. I have a workstation and using X in, > naturally, necessary (in fact, it is paramount since 3D rendering > without Xfree4's opengl is horrible). Thus this option is out. How > about compiling the kernel without module support in the first place? > The problem of /dev/mem would remain, but if the kernel does not know > about modules, is it a problem? compiling without module support would be mostly the same as just lcap CAP_SYS_MODULE leaving /dev/mem open leaves you open regardless of how you stop module loading. i suggest installing all security updates immediatly when they arrive and vigilent sysadmin. those will keep your box uncompromised better then anything (except turning it off). -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
> lcap CAP_SYS_MODULE CAP_SYS_RAWIO > which will disable module loading entirely as well as access to > /dev/mem (which can be just as dangerous as a kernel module and would > bypass your signed module thing nicely). Which means: so long, X. I have a workstation and using X in, naturally, necessary (in fact, it is paramount since 3D rendering without Xfree4's opengl is horrible). Thus this option is out. How about compiling the kernel without module support in the first place? The problem of /dev/mem would remain, but if the kernel does not know about modules, is it a problem? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Sat, Jun 16, 2001 at 07:43:38PM +0200, Sjarn Valkhoff wrote: > How feasable would it be to digitally sign kernel modules? Using a trusted > local private key, a module could be signed at compile time. The kernel > could be patched to disallow any unsigned modules from loading. I have no > idea if this is technically possible, but Knark seems to be a persistent > weakness in security measures such as Tripwire. a solution you can use today is installing lcap and running at boot like so: lcap CAP_SYS_MODULE CAP_SYS_RAWIO which will disable module loading entirely as well as access to /dev/mem (which can be just as dangerous as a kernel module and would bypass your signed module thing nicely). this way they would have to reboot your machine to reenable module loading. i don't know about you, but a reboot not done by me gets VERY close scrutiny. otoh you could also add CAP_SYS_BOOT to that list, then if they reboot init will kill everything and the box will halt when the last initscript calls /sbin/reboot ;-) (annoying if you like remote administration, you have to hit the reset button after issuing shutdown -r now...) -- Ethan Benson http://www.alaska.net/~erbenson/ pgpvIHVWblwkK.pgp Description: PGP signature
Re: A question about Knark and modules
On Sat, Jun 16, 2001 at 07:43:38PM +0200, Sjarn Valkhoff wrote: > How feasable would it be to digitally sign kernel modules? Using a trusted > local private key, a module could be signed at compile time. The kernel > could be patched to disallow any unsigned modules from loading. I have no > idea if this is technically possible, but Knark seems to be a persistent > weakness in security measures such as Tripwire. a solution you can use today is installing lcap and running at boot like so: lcap CAP_SYS_MODULE CAP_SYS_RAWIO which will disable module loading entirely as well as access to /dev/mem (which can be just as dangerous as a kernel module and would bypass your signed module thing nicely). this way they would have to reboot your machine to reenable module loading. i don't know about you, but a reboot not done by me gets VERY close scrutiny. otoh you could also add CAP_SYS_BOOT to that list, then if they reboot init will kill everything and the box will halt when the last initscript calls /sbin/reboot ;-) (annoying if you like remote administration, you have to hit the reset button after issuing shutdown -r now...) -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
