network profile
| bio | website | |
|---|---|---|
| location | ||
| age | 29 | |
| visits | member for | 7 months |
| seen | yesterday | |
| stats | profile views | 18 |
Lucky those who have knowledge to help and assist others :)
|
Jan 8 |
answered | Why is it necessary to match the checksum of a download with another file provided by the same server? |
|
Jan 8 |
comment |
Why is it necessary to match the checksum of a download with another file provided by the same server? @Benoit The answer gives additional reasons (un-malicious data corruption). Also consider this: You can re-download the hash from a mirror or at another point of time (its very concentrated data) so you the effort to give you malicious data increases. It is not a total solution but surely an enhancement to the overall security. Also there are almost no costs involved. You are right, Hash my not be the ultimate solution/protection, but it can be helpful and is cheap. Maybe that's the "why" :) |
|
Jan 4 |
comment |
Shouldn't GPG key fetching use a secure connection? The alertness which is reflected in the question is great. The concern that is raised here is imho not to be neglected. After all spoofing+MITM keyserver-client communication can be a valueble way for attacks (and a possible one - given a lack signatures to make a trusted path). |
|
Jan 4 |
comment |
Shouldn't GPG key fetching use a secure connection? @nealmcb: If I do not have signatures which allow me to make a trusted path (to the public key received) then I dare there is benefit me<->keyserver com encryption. I am sad people (mostly those who are already well in the WoT) tend to neglect those use cases where there are too little signatures on hand and hence the secure keyserver connection can prevent a MITM (which in that case is possible). |
|
Jan 4 |
comment |
Shouldn't GPG key fetching use a secure connection? @PaŭloEbermann It is a comofortable position to be able to verify the keys by signatures. It requires that the signatures you have already will allow you enough pathways. In the special case of a person having no trusted path, I wonder if it would be fair to say that MITM attack is a risk that can be neglected? There is the HKP (un-) and HKPS(encrypted) protocol. I assume the later one is there for a reason. |
|
Dec 30 |
comment |
Passive and active attacks via X11. Is Wayland any better? @Shnatsel It would be great to have some reference to this "good news" regarding Wayland? Can you provide some? |
|
Dec 27 |
comment |
Security tradeoffs of pathname-based MAC (e.g., TOMOYO, grsecurity, AppArmor, …) thank you for the link to the TOMOYO's people responding to certain doubts about the pathname approach |
|
Dec 23 |
awarded | Supporter |
|
Dec 19 |
comment |
Mandatory Access Control Rulesets, how to deal with Python, Bash and other interpreters? 100% correct. No argument about this. It is rather the mechanics I wonder. Let's call a binary XYZ a program - maybe a static one or not - we write a rule in the MAC to limit it. Let's call a .py script also a program, we could proceed the same way, but and that might be a major doubt. The rule refernce point is the executable (which in this case would be the python interpreter) and not the program which would be pyhton+(the script). Maybe the question rephrased would be how the content can be part of a the MAC system rules? Happy for your input. Sorry I can so badly phrase stuff |
|
Dec 19 |
comment |
Mandatory Access Control Rulesets, how to deal with Python, Bash and other interpreters? I very much appreciate your insight. Your example is impressive and surely an example how to hide stuff in code. The often so quickly said "its open source, no backdoors" is questioned by obfuscation like this. I am glad to have received this answer, thank you. Just like in serverfault.com/questions/290828/ there is the question if there is a chance to generate categories for arbitrary code, so that there can be functionality and a certain degree of security obtained? |
|
Dec 19 |
comment |
Mandatory Access Control Rulesets, how to deal with Python, Bash and other interpreters? Even though not desired, I would have enjoyed some input, some discussion. I have not yet figured where and how to implement it. But I would wish to use a MAC to configure my PC in a more secured manner. But with things like "interpreting arbitrary data" and with "mapping executable shared object code" I kind of struggle to get this kind of working in MAC systems. Because they kind of "break the rules" becuase they "unlimit" the functionality of objects. By loading a so or by python a script I cannot tell ahead the resource needed:(. So a MAC should cater for that somehow. I hoped for a way! |
|
Dec 19 |
comment |
Mandatory Access Control Rulesets, how to deal with Python, Bash and other interpreters? To be more clear. I am not developing a protection mechanism. Rather I was looking for one that already implemented. serverfault.com/questions/290828/… shows that some sort of solution sounds like not being the most straightforward appraoch :( |
|
Dec 19 |
comment |
Mandatory Access Control Rulesets, how to deal with Python, Bash and other interpreters? @Polynomial: thank you for your comment and your time. I am trying to understand better how sensible or "good"(meaning working, effective) rules in the MACs could be setup. Restricting a JPEG-viewer programme seems easy (because its so simple what resources it will need). That brought me to the simple reasoning that "what about python?". Python by design it should be powerful (because it might be more than a JPEG-viewer). The MAC rules there should be according to the task aswell, only the things are less clear there. You are also right: I would like to prevent scripts from accessing stuff! |
|
Dec 19 |
asked | Mandatory Access Control Rulesets, how to deal with Python, Bash and other interpreters? |
|
Dec 18 |
awarded | Commentator |
|
Dec 18 |
comment |
Security tradeoffs of pathname-based MAC (e.g., TOMOYO, grsecurity, AppArmor, …) Ingenious the "convert pathname to inode" at rule-set-time solution. Sorry but this seems just such a smart idea to escape the troubles some LSM developers have said to have when seeing that LSM hooks would have not enough and not always the pathname info. |
|
Dec 18 |
comment |
Security tradeoffs of pathname-based MAC (e.g., TOMOYO, grsecurity, AppArmor, …) Wow. If indeed true, I am humbled to receive an answer from one of the authors of a MAC here. Thank you for the time. Secondly I would like to clarify that at no point I wanted to put grsecurity (neither any other) of the works into a "common bunch". Indeed I am quite certain I could hardly now enough at present to be able to group or order the solutions. 3) I enjoyed the informaiton regarding the change of SELinux that might have escaped me as I though most would be inode and indeed xattr based lableling. 4) all this of course makes me have a closer look to grsecurity :) THANK's Brad |
|
Dec 18 |
comment |
Security tradeoffs of pathname-based MAC (e.g., TOMOYO, grsecurity, AppArmor, …) I enjoyed reading of the problems you mentioned about inode-based MAC (which as I think is SELinux only...afterall not to much variety in security systems :(). The other parts have been quite enlightening also, thank you |
|
Dec 17 |
asked | Security tradeoffs of pathname-based MAC (e.g., TOMOYO, grsecurity, AppArmor, …) |
|
Oct 1 |
comment |
What is disk encryption worth? Threat of proprietary Bios, SMM, optionrom, TPM etc? "ever found out". Despite the picture that Polynomial depict of investigating on the hardware itself (opening chips etc etc). Something which is rather impossible for the "average tin foil hat affactionato" I can really not estimate the risk? And even if the manufacturer would commit some error and it would be discovered, it would merely drain on his reputation (if this at all is important). One of the few ways I would conveive possible for discovering "manufacturar deploid rootkit" is when it is used (i.e. by sniffing network traffic of such a PC for unusualities).A risk mitigatable |
