Re: Secure attention Key: Login and GkSudo
On Sun, Oct 30, 2011 at 9:21 AM, staticd staticd.growthecomm...@gmail.com wrote: The Secure Access key(SAK) is a key combination captured/capturable only by the OS. It can be used to initiate authentication interfaces where the user is sure that the keys are being captured only by the OS. This feature is present on windows(Ctrl+Alt+Del) to initiate logon. Enjoy the kool-ade. I think these two steps will help make ubuntu even more secure, and help prepare it for a large non technical userbase. What do you think? Windows NT is designed so that, unless system security is already compromised in some other way, only the Winlogon process, a trusted system process, can receive notification of this keystroke combination. This is because the kernel remembers the process ID of the Winlogon process, and allows only that process to receive the notification. So says Wikipedia. Interestingly, VMWare catches the sequence as well. While it is true that the SAK will trigger a kernel event, it is also true that the major method of bypass isn't going to be anything so simple as hacking the log-in dialog or gksudo prompt. No, that won't work. What you want to do is spoof the user with gksudo itself. Try this: - Open a terminal - gksudo /usr/bin/ls - Examine the dialog box - Cancel without inputting password. - gksudo ls - Examine the dialog box - Cancel out See a difference? Now try adding $HOME/.system/ to your $PATH as the first member. Put a shell script called 'synaptic' into it: #!/bin/sh synaptic cp ~/.system/cfg `which gksudo` chmod u=srwx,go=rx `which gksudo` Now create a launcher that says Synaptic in the menu, to replace the current Synaptic launcher. Viola! -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Secure attention Key: Login and GkSudo
On Sun, Oct 30, 2011 at 9:37 AM, John Moser john.r.mo...@gmail.com wrote: #!/bin/sh synaptic cp ~/.system/cfg `which gksudo` chmod u=srwx,go=rx `which gksudo` Sorry, that would be '/usr/bin/synaptic ' Of course. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Secure attention Key: Login and GkSudo
On Sun, Oct 30, 2011 at 7:08 PM, John Moser john.r.mo...@gmail.com wrote: On Sun, Oct 30, 2011 at 9:37 AM, John Moser john.r.mo...@gmail.com wrote: #!/bin/sh synaptic cp ~/.system/cfg `which gksudo` chmod u=srwx,go=rx `which gksudo` Sorry, that would be '/usr/bin/synaptic ' Of course. I dont think gksudo respects user set PATH variables(at least in terminals for my case). Running gksudo bad_prog even with my PATH set to ~/prog/c doesn't run it. However, to fight against that exploit shouldn't we change the behaviour to complain loudly you are running a potential malware, do you want to proceed? Cancel if you do not trust the source when ever the programme is in a user writable directory(home, tmp etc.). -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Secure attention Key: Login and GkSudo
Windows NT is designed so that, unless system security is already compromised in some other way, only the Winlogon process, a trusted system process, can receive notification of this keystroke combination. This is because the kernel remembers the process ID of the Winlogon process, and allows only that process to receive the notification. So says Wikipedia. Interestingly, VMWare catches the sequence as well. I was thinking of a Alt+Sysrq combination capturable only by the kernel. (Ctrl+Alt+Sysrq ?) While it is true that the SAK will trigger a kernel event, it is also true that the major method of bypass isn't going to be anything so simple as hacking the log-in dialog or gksudo prompt. No, that won't work. Why won't a well created spoof work? An interface that looks like the login interface / gksu interface but isn't. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Secure attention Key: Login and GkSudo
On So, Okt 30, 2011 at 15:11:04 (CET), staticd wrote: Windows NT is designed so that, unless system security is already compromised in some other way, only the Winlogon process, a trusted system process, can receive notification of this keystroke combination. This is because the kernel remembers the process ID of the Winlogon process, and allows only that process to receive the notification. So says Wikipedia. Interestingly, VMWare catches the sequence as well. I was thinking of a Alt+Sysrq combination capturable only by the kernel. (Ctrl+Alt+Sysrq ?) The SAK for Linux systems is Alt+Sysrq+k While this SAK can be disabled, Ubuntu ships with this functionality enabled. It safely and uncatchably terminates your running X11 session, returning back to your login manager. Cheers, Reinhard. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Ubuntu System Restore
You need to either have a local repository or download from the internet again. I've used 'apt-mirror' in the past to maintain a local cache but that was when I was building local systems with a minimal Debian installer. I don't even know if the standard Ubuntu installer can load off a local cache. (I guess the process is to do the install without updates, change your sources.list files, then upgrade from the cache.) It's also worth remembering that the specific versions of your packages may not be available when you need to restore your system. This is usually a good thing since more recent versions have a shot at preventing whatever caused you to lose your system in the first place (e.g., closing vulnerabilities) but some people may need to restore the system exactly. On checksums - I checked my system and almost none of the conffiles have checksums. (In fact that may be against packaging standards - I would have to check.) That's a bummer since it means that there's no easy way of seeing what's changed unless you peek into the .deb file. There are some deb tools that can do this but since I can do it programmatically I usually just did that. The 'monster diff' is just a comment on the number of files involved. What I actually did create two lists, one generated by walking the filesystem and the other generated by concatenating all of the *.files and *.md5sums metadata and then comparing them. I did this programmatically but you could also create actual files, sort them, and then run a diff on them. IIRC I typically had over 70k files. On Fri, Oct 28, 2011 at 3:33 AM, Gaurav Saxena grvsaxena...@gmail.comwrote: Hello all On Fri, Oct 7, 2011 at 4:45 AM, Bear Giles bgi...@coyotesong.com wrote: I've written a few prototypes and this comes down to four issues. Some of the details below are debian/ubuntu-specific but the same concepts will apply to redhat. 1. User data (/home) must be backed up explicitly. (ditto server data on servers). 2. Packages should NOT be backed up. All you need is the package name and version. Reinstall from .deb and .rpm if necessary since this way you're sure that you never restore compromised files. But it might be possible that the package files are not available on the system. That means for all the packages installed the .deb files need to be downloaded from the internet for restore purpose ? 3. Configuration data (/etc) must be backed up explicitly. This is tricky because backing up the entire directory will cause its own problems. Worse, some applications keep their configuration files elsewhere. The best solution I've found is to scan the package metadata to identify configuration files and to only save those with a different checksum than the standard file. Ok. Nice idea indeed , but is there checksum associated with the files in the package ? Or that can be calculated at the time of restore ? What you say ? 4. Local files. Ideally everyone would keep these files under /usr/local and /opt but that's rarely the case. The best solution I've found is to scan the debian package metadata and do a monster diff between what's on the filesystem under /bin, /sbin, /usr and (chunks of) /var with what's in the metadata. Could you suggest me some way of scanning the debian package metadata without actually downloading the packages? and how to this monster diff ? It's worth noting that the last item isn't that hard if you have a strict security policy that everything under those directories MUST be in a package. It's deleted without a second thought if it's not. You can still do everything you could before, you just need to create a local package for it. So what do you do with this? The best solution, which I haven't implemented yet, is to handle #2 and #3 with autogenerated packages. You set up one or more local packages that will install the right software and then overwrite the configuration files. You can fit everything, including original package archive, on a single DVD. Could you please tell some detail about autogenerated packages ? Like if we have a list of packages installed on the system, We need to reinstall those all softwares and remove those which are installed after the restore point? BTW Debian has a C++ interface to the package metadata. I've never used it - I find it easier to just scan the metadata directory myself. There's also hooks that will allow your application to be called at each step during a package installation or removal. You could, in theory, keep your snapshots current to the last minute that way. So whenever a package is installed or removed I will update my backup according to that ? By reading package metadata determine which files are changed by that package and update those files in the backup ? On Fri, Sep 30, 2011 at 12:01 AM, Gaurav Saxena grvsaxena...@gmail.comwrote: Hello Aaron Thanks a lot for your quick reply. On Fri, Sep 30, 2011 at 10:03 AM, Aaron C. de
Re: Ubuntu System Restore
The simple way to create a restore point system ... ... is to mount / as an overlay FS, which you periodically merge (to remove prior restore points), condense into a squashfs (to take a point backup), or wipe (to restore to backup). This of course means /home should be its own partition. On Sun, Oct 30, 2011 at 4:40 PM, Bear Giles bgi...@coyotesong.com wrote: You need to either have a local repository or download from the internet again. I've used 'apt-mirror' in the past to maintain a local cache but that was when I was building local systems with a minimal Debian installer. I don't even know if the standard Ubuntu installer can load off a local cache. (I guess the process is to do the install without updates, change your sources.list files, then upgrade from the cache.) It's also worth remembering that the specific versions of your packages may not be available when you need to restore your system. This is usually a good thing since more recent versions have a shot at preventing whatever caused you to lose your system in the first place (e.g., closing vulnerabilities) but some people may need to restore the system exactly. On checksums - I checked my system and almost none of the conffiles have checksums. (In fact that may be against packaging standards - I would have to check.) That's a bummer since it means that there's no easy way of seeing what's changed unless you peek into the .deb file. There are some deb tools that can do this but since I can do it programmatically I usually just did that. The 'monster diff' is just a comment on the number of files involved. What I actually did create two lists, one generated by walking the filesystem and the other generated by concatenating all of the *.files and *.md5sums metadata and then comparing them. I did this programmatically but you could also create actual files, sort them, and then run a diff on them. IIRC I typically had over 70k files. On Fri, Oct 28, 2011 at 3:33 AM, Gaurav Saxena grvsaxena...@gmail.com wrote: Hello all On Fri, Oct 7, 2011 at 4:45 AM, Bear Giles bgi...@coyotesong.com wrote: I've written a few prototypes and this comes down to four issues. Some of the details below are debian/ubuntu-specific but the same concepts will apply to redhat. 1. User data (/home) must be backed up explicitly. (ditto server data on servers). 2. Packages should NOT be backed up. All you need is the package name and version. Reinstall from .deb and .rpm if necessary since this way you're sure that you never restore compromised files. But it might be possible that the package files are not available on the system. That means for all the packages installed the .deb files need to be downloaded from the internet for restore purpose ? 3. Configuration data (/etc) must be backed up explicitly. This is tricky because backing up the entire directory will cause its own problems. Worse, some applications keep their configuration files elsewhere. The best solution I've found is to scan the package metadata to identify configuration files and to only save those with a different checksum than the standard file. Ok. Nice idea indeed , but is there checksum associated with the files in the package ? Or that can be calculated at the time of restore ? What you say ? 4. Local files. Ideally everyone would keep these files under /usr/local and /opt but that's rarely the case. The best solution I've found is to scan the debian package metadata and do a monster diff between what's on the filesystem under /bin, /sbin, /usr and (chunks of) /var with what's in the metadata. Could you suggest me some way of scanning the debian package metadata without actually downloading the packages? and how to this monster diff ? It's worth noting that the last item isn't that hard if you have a strict security policy that everything under those directories MUST be in a package. It's deleted without a second thought if it's not. You can still do everything you could before, you just need to create a local package for it. So what do you do with this? The best solution, which I haven't implemented yet, is to handle #2 and #3 with autogenerated packages. You set up one or more local packages that will install the right software and then overwrite the configuration files. You can fit everything, including original package archive, on a single DVD. Could you please tell some detail about autogenerated packages ? Like if we have a list of packages installed on the system, We need to reinstall those all softwares and remove those which are installed after the restore point? BTW Debian has a C++ interface to the package metadata. I've never used it - I find it easier to just scan the metadata directory myself. There's also hooks that will allow your application to be called at each step during a package installation or removal. You could, in theory, keep your snapshots current to the last minute that way. So
Re: Secure attention Key: Login and GkSudo
Actually SSL/SSH is a good example of how easy it is to screw up things. It's hard to believe that people have deployed systems and left the NULL cipher as an acceptable cipher but it's been done. Ditto weak random number generators that left you with AES encryption but only a relative handful of possible session keys. (This is what bit Debian a while back.) I seem to recall reading about another attack in just the last few weeks. BTW you can eavesdrop on a connection if you have one of the keys used in the DH negotiations and the parties aren't using Perfect Forward Secrecy. It's scary because it doesn't have to be realtime - it can be someone sniffing your network today and replaying the tapes when they get a copy of your key a few weeks later. I suspect few people using the various ssl libraries even know about this. On Sun, Oct 30, 2011 at 12:37 PM, Reinhard Tartler siret...@ubuntu.comwrote: On So, Okt 30, 2011 at 15:11:04 (CET), staticd wrote: Windows NT is designed so that, unless system security is already compromised in some other way, only the Winlogon process, a trusted system process, can receive notification of this keystroke combination. This is because the kernel remembers the process ID of the Winlogon process, and allows only that process to receive the notification. So says Wikipedia. Interestingly, VMWare catches the sequence as well. I was thinking of a Alt+Sysrq combination capturable only by the kernel. (Ctrl+Alt+Sysrq ?) The SAK for Linux systems is Alt+Sysrq+k While this SAK can be disabled, Ubuntu ships with this functionality enabled. It safely and uncatchably terminates your running X11 session, returning back to your login manager. Cheers, Reinhard. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Ubuntu System Restore
LVM lets you create a snapshot where the mounted filesystem looks normal but under the cover it's using a journal and the original logical volume, e.g., /dev/mapper/vg0/home, is untouched. You can then perform your backup and when you release the snapshot the journal is written to the original volume. Obviously this requires a backup app that runs against the raw device instead of the mounted filesystem. 'dump' does that, 'tar' does not. On Sun, Oct 30, 2011 at 2:57 PM, John Moser john.r.mo...@gmail.com wrote: The simple way to create a restore point system ... ... is to mount / as an overlay FS, which you periodically merge (to remove prior restore points), condense into a squashfs (to take a point backup), or wipe (to restore to backup). This of course means /home should be its own partition. On Sun, Oct 30, 2011 at 4:40 PM, Bear Giles bgi...@coyotesong.com wrote: You need to either have a local repository or download from the internet again. I've used 'apt-mirror' in the past to maintain a local cache but that was when I was building local systems with a minimal Debian installer. I don't even know if the standard Ubuntu installer can load off a local cache. (I guess the process is to do the install without updates, change your sources.list files, then upgrade from the cache.) It's also worth remembering that the specific versions of your packages may not be available when you need to restore your system. This is usually a good thing since more recent versions have a shot at preventing whatever caused you to lose your system in the first place (e.g., closing vulnerabilities) but some people may need to restore the system exactly. On checksums - I checked my system and almost none of the conffiles have checksums. (In fact that may be against packaging standards - I would have to check.) That's a bummer since it means that there's no easy way of seeing what's changed unless you peek into the .deb file. There are some deb tools that can do this but since I can do it programmatically I usually just did that. The 'monster diff' is just a comment on the number of files involved. What I actually did create two lists, one generated by walking the filesystem and the other generated by concatenating all of the *.files and *.md5sums metadata and then comparing them. I did this programmatically but you could also create actual files, sort them, and then run a diff on them. IIRC I typically had over 70k files. On Fri, Oct 28, 2011 at 3:33 AM, Gaurav Saxena grvsaxena...@gmail.com wrote: Hello all On Fri, Oct 7, 2011 at 4:45 AM, Bear Giles bgi...@coyotesong.com wrote: I've written a few prototypes and this comes down to four issues. Some of the details below are debian/ubuntu-specific but the same concepts will apply to redhat. 1. User data (/home) must be backed up explicitly. (ditto server data on servers). 2. Packages should NOT be backed up. All you need is the package name and version. Reinstall from .deb and .rpm if necessary since this way you're sure that you never restore compromised files. But it might be possible that the package files are not available on the system. That means for all the packages installed the .deb files need to be downloaded from the internet for restore purpose ? 3. Configuration data (/etc) must be backed up explicitly. This is tricky because backing up the entire directory will cause its own problems. Worse, some applications keep their configuration files elsewhere. The best solution I've found is to scan the package metadata to identify configuration files and to only save those with a different checksum than the standard file. Ok. Nice idea indeed , but is there checksum associated with the files in the package ? Or that can be calculated at the time of restore ? What you say ? 4. Local files. Ideally everyone would keep these files under /usr/local and /opt but that's rarely the case. The best solution I've found is to scan the debian package metadata and do a monster diff between what's on the filesystem under /bin, /sbin, /usr and (chunks of) /var with what's in the metadata. Could you suggest me some way of scanning the debian package metadata without actually downloading the packages? and how to this monster diff ? It's worth noting that the last item isn't that hard if you have a strict security policy that everything under those directories MUST be in a package. It's deleted without a second thought if it's not. You can still do everything you could before, you just need to create a local package for it. So what do you do with this? The best solution, which I haven't implemented yet, is to handle #2 and #3 with autogenerated packages. You set up one or more local packages that will install the right software and then overwrite the configuration files. You can fit everything, including
Re: Ubuntu System Restore
On 10/30/2011 05:17 PM, Bear Giles wrote: LVM lets you create a snapshot where the mounted filesystem looks normal but under the cover it's using a journal and the original logical volume, e.g., /dev/mapper/vg0/home, is untouched. You can then perform your backup and when you release the snapshot the journal is written to the original volume. Actually, the snapshot keeps copies of any blocks that have been modified in either the original or the snapshot volume, and when you delete the snapshot, they are all discarded. More recent versions of LVM now allow you to merge ( with lvconvert ) the snapshot into the original volume the next time it is remounted, effectively allowing you to revert the original volume to the snapshot state. Obviously this requires a backup app that runs against the raw device instead of the mounted filesystem. 'dump' does that, 'tar' does not. It does not require that since you can just mount the snapshot, then use tar, but in my experience, dump is much faster than tar. I've looked at trying to implement a system restore based on LVM for the last year or so and have concluded that it just isn't practical. There are a number of problems that make it so: 1) You must reserve space for the snapshot up front, and if that space runs out, the snapshot is lost. 2) Because it operates on a block level, it is rather inefficient. Specifically, you can write a new file to disk, and then delete it, but the blocks it was written to remain in the snapshot exception store, and may be somewhat larger than the actual file size, as the snapshot block size defaults to 64k iirc. These no longer used blocks also then have to be copied back to the original location during a merge, whether or not they actually contained any data in the snapshot. 3) Having a snapshot active has an appreciable write performance penalty on the original volume. This penalty grows linearly worse as you add more snapshots because each new write to the original volume results in data being copied out to each of the active snapshots first. It appears that btrfs is the way to go for system snapshots, and the apt-btrfs-snapshot package appears to be a good first step in this direction. It currently causes apt to make a btrfs snapshot before each upgrade/install and provides a command line interface to list, delete, and rollback to snapshots. It is written in python and I have been thinking of adding a little gtk gui to it. I spent this weekend patching dpkg to support a --force-no-syncs option so that apt can instruct it to avoid all of the syncs dpkg normally does as they are rendered completely pointless when you can just rollback to the snapshot if things go wrong, and have a large performance penalty, especially on btrfs. I've also been thinking of adding some support to grub to allow you to choose to roll back to a snapshot right from there, in case you can't even boot the system to ask apt-btrfs-snapshot to do it for you. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Secure attention Key: Login and GkSudo
On Mon, Oct 31, 2011 at 12:07 AM, Reinhard Tartler siret...@ubuntu.comwrote: On So, Okt 30, 2011 at 15:11:04 (CET), staticd wrote: Windows NT is designed so that, unless system security is already compromised in some other way, only the Winlogon process, a trusted system process, can receive notification of this keystroke combination. This is because the kernel remembers the process ID of the Winlogon process, and allows only that process to receive the notification. So says Wikipedia. Interestingly, VMWare catches the sequence as well. I was thinking of a Alt+Sysrq combination capturable only by the kernel. (Ctrl+Alt+Sysrq ?) The SAK for Linux systems is Alt+Sysrq+k While this SAK can be disabled, Ubuntu ships with this functionality enabled. It safely and uncatchably terminates your running X11 session, returning back to your login manager. Cheers, Reinhard. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss Reinhard, doesn't pressing Alt+Sysrq+k kill the current X session? Is there a secure way of getting the login manager without disrupting other users who are also working in the background? (a switch user functionality that cannot be spoofed) Do you know how i could go about implementing this? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
