Re: Security issue ... please could someone help !!!
Hi. On Sun, Apr 05, 2020 at 09:03:00PM +0100, Bhasker C V wrote: > I kept digging down and saw that anything below 32 bytes is not accepted > (by cryptsetup --key-file option) but anything above 32 bytes is > discarded. cryptsetup(8), "-s" option. > Does this mean that cryptsetup plain with --key-file uses > only 32 bytes ? Yes, assuming the defaults. > Am I doing anything wrong ? Probably no. By default cryptsetup uses AES encryption algorithm with the key size of 256 bits. You're suppling your own key to cryptsetup, hence it chooses just right amount of bits from it (32 bytes = 256 bits). > If only 32 bytes are used, it is (in my opinion) not so much secure > isnt it ? It's sufficiently secure, unless you try to do something really wrong (like storing a plain key somewhere), or generate your key predictably. Reco
Re: Security Issue with sssd / AD authentication?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kent West wrote: > Probably not the best place to put this information, but I figure here > is better than no where... > > I'm tinkering with authentication a Debian (10.1) box via Active > Directory, so that an AD user can log into the Debian box. > > [...] > > The result is that if I have a local account that belongs to a > completely different person than a person with a domain account of the > same name, the domain account person, upon login, becomes the local > account person, with full access as that person. > > Advice? Suggestions? Questions? > Last time I did central logins like that, I used openLDAP, so it may not be the same process. But as I recall, you had to change one of the PAM modules (possibly more than one) such that it prefers ldap (AD, whatever) over the local /etc/passwd file. Additionally, I seem to recall some caveat of the "same username" not gracefully allowing you to "select"; so I just ended up having a secondary 'me_local' account that wasn't part of the LDAP setup. It's been a few years (and a new job) since, so I might not have the notes anymore (The general info is usually something I hang onto, but the "basics of ldap" notes aren't immediately forthcoming). -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl3FrLUACgkQjhHd8xJ5 ooEOuggArD62bnF0vuIBfbvmvu8IbomBs0eUBN+YqA8iusNMA6KF+0YboWeNmK6z yzlcNb8PArKx4ca5olV3gV6zOa4lO73onW9BBq4tcajgW7mgllsLgDeWBlD4HeER xg1O5m9TCJlmgnWLWdW15tr6hQk8STASm7R8/LGBWOq3AGVE21dQBnkC7sdxu514 6b5EgMDBdgiCFuKXogkZL/EbdWMNYvGe1rQao1yCAeln9+NDasYp2A+KAZ76XEnT rPgjYol4JIO3O7Be+X0XsTy6ssSpNd2w5IuKfpGev5wfxtrj4tR+NkxxEwUHz38H +9nN6awXwtdywR6XmU+IucWRua7/Wg== =9it9 -END PGP SIGNATURE- -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
Re: Security Issue with sssd / AD authentication?
On 11/8/19 11:53 AM, Roberto C. Sánchez wrote: On Fri, Nov 08, 2019 at 11:36:34AM -0600, Kent West wrote: Probably not the best place to put this information, but I figure here is better than no where... I'm tinkering with authentication a Debian (10.1) box via Active Directory, so that an AD user can log into the Debian box. The relevant /etc/sssd/sssd.conf file has the following modification: use_fully_qualified_names = False If I have a local account (say, "westk") and a domain account of the same name, but with a different password, I can log into the Debian box with the domain "westk"/password, but the "id" command shows me then to be logged in as the local "westk". The result is that if I have a local account that belongs to a completely different person than a person with a domain account of the same name, the domain account person, upon login, becomes the local account person, with full access as that person. Advice? Suggestions? Questions? It seems like you have two options: 1. change the use_fully_qualified_names setting 2. eliminate the westk local account While the situation has security implications, those implications are a result of misconfiguration rather than any defect in the related utilities. You could experience the same issue by allowing logins from two different domains where the same user account exists in both. It is a risk of the use_fully_qualified_names configuration setting. Regards, -Roberto I can accept that answer, if that's indeed the answer, but it seems to me that the local Debian box knows it authenticated from the domain, not locally (based on where the password was successful). Having that knowledge, it seems an error to then assign the user as the local user rather than the domain user. -- Kent
Re: Security Issue with sssd / AD authentication?
On Fri, Nov 08, 2019 at 11:36:34AM -0600, Kent West wrote: > Probably not the best place to put this information, but I figure here is > better than no where... > > I'm tinkering with authentication a Debian (10.1) box via Active Directory, > so that an AD user can log into the Debian box. > > The relevant /etc/sssd/sssd.conf file has the following modification: > > use_fully_qualified_names = False > > If I have a local account (say, "westk") and a domain account of the same > name, but with a different password, I can log into the Debian box with the > domain "westk"/password, but the "id" command shows me then to be logged in > as the local "westk". > > The result is that if I have a local account that belongs to a completely > different person than a person with a domain account of the same name, the > domain account person, upon login, becomes the local account person, with > full access as that person. > > Advice? Suggestions? Questions? > It seems like you have two options: 1. change the use_fully_qualified_names setting 2. eliminate the westk local account While the situation has security implications, those implications are a result of misconfiguration rather than any defect in the related utilities. You could experience the same issue by allowing logins from two different domains where the same user account exists in both. It is a risk of the use_fully_qualified_names configuration setting. Regards, -Roberto -- Roberto C. Sánchez
Re: Security Issue
On Tue, Mar 06, 2001 at 10:55:40AM -0800, Ken Sandell wrote: > Hey guys, I want to have User Read Only directories, but I want to have users > in the same group and have them still not be able to read any other users > home directories. > > Also, the folder ~user/web is where their web shit is and should be viewable. chmod 701 /home/* you only need execute permissions on the home dir. only the 'web' dir needs to be world readable. -Rob
Re: security issue
> Hi, > > I have a question regarding security issue with Debian and Linux in > general. By now everyone has probably heard about the new Mellissa > virus. I know that this doesn't affect Linux because it is related to > M$ products only. However, I just wondered if anything of this sort > could happen to a Linux system? I know that Linux in general is > actually quite secure, but what makes it so? Just some information > about Linux security issue would be appreciated. Thank you for any kind > of info. > > Shawn It could very well happen in Linux. The security of a system is not only in code, but also in the hands of people who you that computer. And how they use it. I mean...probably half of MS users have this nifty little feature that saves them few mouse-clicks, which opens documents right away. Hell, even ICQ has that, and it's been exploited already (look in rootshell). We can have the same feature, but it't how people are going to use it. Probably noone is going to be trusty enough to let themselves just open a document which came from someone else. ALthough I'd fall for it, personally, if it was a document from someone I know, and which is how Mellissa does most of the damage. But there's been accidents of same kind in Linux community. I heard of one only, but I'm sure there's been more. Here is the general idea: take a popular program, like ftp client, and modify it. Insert a trojan horse into it. Then hack an ftp server and place that ftp client of yours there. Let people download it. At least problems like that get solved rather fast. Gotta give credit to CERT, though, they've done a good job isolating the cause and fast. I think I got the email from them Saturday morning. Andrew --- Andrei S. Ivanov [EMAIL PROTECTED] UIN 12402354 http://members.tripod.com/AnSIv <--Little things for Linux.
Re: security issue
In foo.debian-user, you wrote: > I have a question regarding security issue with Debian and Linux in > general. By now everyone has probably heard about the new Mellissa > virus. I know that this doesn't affect Linux because it is related to > M$ products only. However, I just wondered if anything of this sort > could happen to a Linux system? I know that Linux in general is > actually quite secure, but what makes it so? Just some information > about Linux security issue would be appreciated. Thank you for any kind > of info. This particular virus is spread because the computer is allowed to run scripts just from the act of viewing a document. This could happen to Linux if we ever had a document format that was both popular enough and able to execute unsafe macros. Depending on the configuration and settings, this could happen if we had a MSWord Viewer that ran macros, a Gnome/Baboon format, or even an HTML/Javascript renderer built into the mail client. Actually, this could happen with any buffer overflow exploit found in a very popular mail client. -Mitch This is why email should be limited to text, and everything else is evil (your turn George ;-) )
Re: Security Issue
> As root, what if I want to keep a file in someones directory without them > deleteing it ? Using conventional Unix permissions, that is indeed the case. Note that this so for all Unix-like systems, not just Linux. Root generally keeps important files in root's own directories. Using ACLs you might be able to keep a file from being removed. I've never tried them. Bruce
Re: Security Issue
On Tue, 18 Mar 1997, Matthew Tebbens wrote: > > I'm not sure if this is normal, but it seems that any file owned by > someone else and in one of my directories can be deleted by me even > if I don't have the proper permissions to do so. I also can rename the > file, but I can't alter the file. This holds true even if the file > is owned by root. > > Is this normal ? If this is true: "-rw--- 1 root root 61 Mar 22 15:14 test.dat" Then YES!!! a big problem. > If so, what things can I do to someone elses file thats in one of my > directories , just delete or rename the file ? If you own the directory. > As root, what if I want to keep a file in someones directory without them > deleteing it ? As I see it now, that can't be done ?!?!? It can be overridden by the dir owner from what I can see. There may be a way to prevent it though. I would think. --Rick [EMAIL PROTECTED]
Re: Security Issue
Matthew Tebbens typed: > > I'm not sure if this is normal, but it seems that any file owned by > someone else and in one of my directories can be deleted by me even > if I don't have the proper permissions to do so. I also can rename the > file, but I can't alter the file. This holds true even if the file > is owned by root. > > Is this normal ? Yes this is normal. The permissions for deleting the file are contained in the directory. If you can write to a directory, then you can delete files in that directory. > If so, what things can I do to someone elses file thats in one of my > directories , just delete or rename the file ? It depends on the permissions of the file. > As root, what if I want to keep a file in someones directory without them > deleteing it ? As I see it now, that can't be done ?!?!? Not really, unless you revoke write privledges in that directory. What are you trying to do here? It sounds like you are going the wrong way about it. - Craig -- // /\ | | | Craig Small VK2XLZ @home: [EMAIL PROTECTED] ||==||===|==|=| [44.136.13.17] @play: [EMAIL PROTECTED] \\ \/ | | | finger [EMAIL PROTECTED] for PGP key!
Re: Security Issue
Philippe Troin very kindly remarked > > Permissions for removal/addition of files in a directory are controlled by > the directory permissions, not the file permissions. Makes sense when > said like this. Except_ for directories with the sticky bit set where > only the owner of a file can remove it (eg. /tmp). ^^ Not "only" - nobody seems to have picked up on this ... In directories where the sticky bit is set, the user and the group owning the directory have the rights attibuted to them by the permissions on the directory, irrespective of the owners of the files. So far, nothing is different from non-sticky directories. If write permission is granted for others (which is the point of it all), others can create files (belonging to them, of course) and only delete files belonging to them. In essence, "drwxrwxrwt sysop wheel /tmp" permits sysop and wheel users to delete any and all files in /tmp. For further discussion, any Unix basic administration book... this isn't really the place. -- include Lorens KOCKUM ( [EMAIL PROTECTED] )
Re: Security Issue
If someone else owns the directory that the file is in, then they basically own the file allocation table and can rename the file to anything they want, or remove the filename alltogether. It's basically like they own the filecabinet, and the other person's file is in the cabinet. Even though they may have a lock on the file so that nobody can read it, the person who owns the cabinet can throw out the file. Isn't that how it should be? On Tue, 18 Mar 1997, Matthew Tebbens wrote: > > I'm not sure if this is normal, but it seems that any file owned by > someone else and in one of my directories can be deleted by me even > if I don't have the proper permissions to do so. I also can rename the > file, but I can't alter the file. This holds true even if the file > is owned by root. > > Is this normal ? > > If so, what things can I do to someone elses file thats in one of my > directories , just delete or rename the file ? > > As root, what if I want to keep a file in someones directory without them > deleteing it ? As I see it now, that can't be done ?!?!? > > Matthew > >
Re: Security Issue
FYI, your mailer is broken. The headers mention calyx.net as a return address, but there's no calyx.net domain around... Well, actually, there's a Calyx.net domain in WHOIS, suspended yesterday. Say thank you to Internic, NSF and NSI ! I'm posting on debian user, in case this message doesn't arrive... On Tue, 18 Mar 1997 20:48:54 EST "Brian S. Julin" ([EMAIL PROTECTED]) wrote: > On Tue, 18 Mar 1997, Philippe Troin wrote: > > Congratulations, you've found a big *nix security flaw ! > > Hardly. It's only a flaw to people who haven't RTFM. It's a valuable > feature actually. If you don't like it and you want your ext2fs > partitions to behave after the braindead OSF-1 implementation style, > read the manual page for 'mount'. Oh, sorry, I should have put a ton of smileys... Phil.
Re: Security Issue
"David B. Teague" <[EMAIL PROTECTED]> writes: > > Matthew > > You could use chattr to make the file immutable. It is documented as > chattr(1). Also see lsattr(1). > but keep in mind that it's an extension only valid for the ext2 filesystem.
Re: Security Issue
Matthew Tebbens <[EMAIL PROTECTED]> writes: > > > I'm not sure if this is normal, but it seems that any file owned by > someone else and in one of my directories can be deleted by me even > if I don't have the proper permissions to do so. I also can rename the > file, but I can't alter the file. This holds true even if the file > is owned by root. > > Is this normal ? > yes, for deleting/renaming a file entry in a directory you need write permission for that directory. To change the contents of the file (deleting is deleting and not changing the contents) you need write permission for the file.
Re: Security Issue
Matthew, > I'm not sure if this is normal, but it seems that any file owned by > someone else and in one of my directories can be deleted by me ... > I also can rename the file, but I can't alter the file. This holds true > even if the file is owned by root. > > Is this normal ? Yes. Permissions are a frequent stumbling block for new unix users. The concept is very simple and powerful. > If so, what things can I do to someone elses file thats in one of my > directories , just delete or rename the file ? Everything in unix is a file. I'll say that again. Everything in unix is a file. A directory is a file. If you will agree not to flame me for hyperbole, it may simplify matters to think of the directory as the card catalog in a library. You can see (read) and deface (rename) the card entry even if the rare volume that it references is under lock and key. If you remove the card, that volume is inaccessible (deleted) to anyone using the card catalog, but note that the book may still be accessible through another card catalog. Deleting the file in one directory does not actually delete the file if there are hard links to it from other directories. The mode (permissions) of a file are nominally handled as triples (r, w, x). r - permission to see the contents of the file contents of the directory (index file) input of the device w - permission to alter the contents of the file contents of the directory (index file) output of the device x - permission to execute the contents of the file the search of the directory (index file) Each file has an assigned user and group. The mode has three triples that apply respectively to the user, group, and others. For further information see "man chmod". If you have write permission on the directory, you have the ability to alter its contents (the file index) including deletion, and renaming. You even have this permission if you don't have read or search permission! > As root, what if I want to keep a file in someones directory without them > deleteing it ? As I see it now, that can't be done ?!?!? Root can delegate authority over a directory by granting write permission to its user. This is the customary permission for home directories. So long as that authority has been delegated, root cannot prevent a user from removing any file including those owned by root. If root needs to keep a file in a directory despite all other efforts, then root must own and deny anyone else write access to the directory and all its parents. It is customary that root own only critical files (/etc/passwd, /etc/ppp/pap-secrets, etc.) and directories (/etc, /bin). Most of the address space is delegated to officers (operator, uucp, mail, etc.) and groups (staff, adm, www, etc.) determined by convention and experience. This separation of authority makes unix much easier to manage for multi-user installations. It also provides a check system that limits the spread of either accidental or malicious interference (viruses). Most professional system administrators that I know usually cringe at the thought of unnecessary use of root and its ability to destroy everything with a few mistaken keystrokes. sudo, doas, and well-chosen group assignments provide a safety net. Hope this helps, -- Robert Meier FANUC Robotics North America, Inc. Internet: [EMAIL PROTECTED] Voice: 1-810-377-7469 Fax: 1-810-377-7363
Re: Security Issue
Matthew You could use chattr to make the file immutable. It is documented as chattr(1). Also see lsattr(1). -- David On Tue, 18 Mar 1997, Matthew Tebbens wrote: > > I'm not sure if this is normal, but it seems that any file owned by > someone else and in one of my directories can be deleted by me even > if I don't have the proper permissions to do so. I also can rename the > file, but I can't alter the file. This holds true even if the file > is owned by root. > > Is this normal ? > > If so, what things can I do to someone elses file thats in one of my > directories , just delete or rename the file ? > > As root, what if I want to keep a file in someones directory without them > deleteing it ? As I see it now, that can't be done ?!?!? > > Matthew > > - LINUX: the FREE 32 bit OS for [345]86 PC's available NOW! David B Teague | User interface copyrights & software patents make [EMAIL PROTECTED] | programing a dangerous business. Ask me or [EMAIL PROTECTED] spy counter-intelligence wild porno sex gold bullion Soviet Bosnia clipper National Security Council explosion Treasury terrorist Delta Force bomb Iran Mossad data encryption munitions Serbian hydrazine ammonium nitrate fuel oil
Re: Security Issue
On Tue, 18 Mar 1997 10:12:03 EST Matthew Tebbens ([EMAIL PROTECTED] ishkill.ibm.com) wrote: > I'm not sure if this is normal, but it seems that any file owned by > someone else and in one of my directories can be deleted by me even > if I don't have the proper permissions to do so. I also can rename the > file, but I can't alter the file. This holds true even if the file > is owned by root. Congratulations, you've found a big *nix security flaw ! > Is this normal ? Yes. > If so, what things can I do to someone elses file thats in one of my > directories , just delete or rename the file ? > As root, what if I want to keep a file in someones directory without them > deleteing it ? As I see it now, that can't be done ?!?!? Permissions for removal/addition of files in a directory are controlled by the directory permissions, not the file permissions. Makes sense when said like this. _Except_ for directories with the sticky bit set where only the owner of a file can remove it (eg. /tmp). Phil.
